Access to issues in Workfront is first defined by the system administrator through your Access Level.
For more information about what access each Access Level has and to what objects, see "Access Levels by License Type."
As a system administrator, you can specify what Access Level a user should have. The Access Level defines what access they receive for most objects in the system. For more information about license types and access levels, see "Creating or Modifying Access Levels."
Users also gain access by sharing individual objects with them, through the permissions they are given on these objects. For more information about permissions, see "Understanding Permissions in the Access Model."
Permissions to objects are inherited though the hierarchy of objects. For example, if a user has permissions to a specific project they will also have permissions to the issues in that project.
The table below shows what issue functions are available to users based on their access level. Administrators can restrict these to limit the actions a user can perform on issues in the access level of that user.
When permissions are set on an object and the object is shared with a user, actions can be further restricted, but they cannot be expanded beyond what the administrator sets on the access level.
For example, if users do not have access to Create issues in their Access Level, they will not be able to Copy an issue. If users do not have permissions to Add Issues on a project, they cannot add issues on that specific project, but they could create issues, if they had Create tasks from their Access Level on other projects on which they also have Add Issues permissions.
For more information about issue permissions, see "Issue Permissions."
The level of access around issues is defined at the system level by the license type the user is assigned to. For example, Reviewers cannot log time and Workers cannot share system-wide. Keep these things in mind when sharing issues with these users.
Theand the creator of an issue has default Manage permissions, within the limits of their access level. As the owner or the creator of an issue, you can share access with other users through permissions.
Issue access is also controlled through object hierarchy. If the user already has permission on the parent object, like a project or a task, those permissions will transfer to the issue. Users who have permissions to an issue coming from the parent objects of the issue are listed under Inherited Permissions.
The following table displays the actions that are allowed for users on issues based on their license type:
|Attach Custom Form||✓||✓||✓||✓|
|Edit Custom Fields||✓||✓||✓||✓|
|Add an Approval Process||✓||✓||✓||✓|
|Convert to Project*||✓||✓|
|Convert to Task*||✓||✓|
|Make Assignments||✓||✓||^only in in-line edit||^only in in-line edit|
*Controlled by access and permissions of the project or task.