Set work tracking permissions
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018
You can grant or restrict access to various work tracking features by granting users or groups specific permissions for an object, project, or collection. Or, you can specify custom rules for a process or project that apply to users or groups that may restrict or require users to perform a select action. In general, you want to add users to a project's Contributors group to provide access to most features as listed in Permissions and access for work tracking.
Note
For public projects, Stakeholder access gives users greater access to work tracking features and full access to Azure Pipelines. To learn more, see Stakeholder access quick reference.
Prerequisites
- To set work tracking permissions, you must be a member of the Project Administrators group, or have explicit permissions to manage the work tracking area as described in this article.
- To set process permissions, you must be a member of the Project Collection Administrators group, or have explicit permissions to edit a collection process.
Support business workflows through custom rules
Custom rules don't control permissions, but they do affect the permissions of a user at run-time to modify a work item or set the value of a work item field. Azure Boards supports the following work tracking customizations that support business workflows.
- Apply select rules upon work item creation, state change, specified state. For example, make a field required or read-only.
- Apply select rules when a field value is empty, set to a specific value, or was changed or not changed to a value. For example, clear or set the value of a field, or copy a field value to another field or hide a field.
- Restrict the transition to a specific state when moving from a specified state. For example, reassign a work item based on state change, or state transitions of parent work items based on state changes made to their child work items.
- Apply select rules based on user or group membership of the user modifying a work item. For example, you can specify rules that effectively restrict a group of users from creating a work item, transitioning a work item to a closed or completed state, or changing the value of a field.
Some restrictions are placed on applying custom rules to system fields. For example, you can't specify rules that set or clear the value for Area Path or Iteration Path as these are system fields. To learn more about custom rules you can define and system field restrictions on custom rules, see Rules and rule evaluation. For sample scenarios that define custom rules, see Sample rule scenarios.
Work tracking roles and permission levels
The following table summarizes the different permissions you can set at the object, project, or collection level. The team administrator role provides access to add and modify team resources.
Role or permission level
Functional areas set
Team administrator role
To add a user to the team administrator role, see Add a team administrator.
Object-level permissions
Project-level permissions
Project collection-level permissions
- Create, delete, or edit a process (Inheritance process model)
- Delete field from account (Inheritance process model)
- Manage process permissions (Inheritance process model)
- Edit collection level permissions
Project collection-level permissions include all permissions you can set at the collection-level.
- Edit collection level permissions
Project collection-level permissions include all permissions you can set at the collection-level.
Note
If you haven't defined the group yet whose permissions you want to set, then first create the group, usually at the project level. To learn how, see Add or remove users or groups, manage security groups.
Create child nodes, modify work items under an area or iteration path
Area path permissions let you grant or restrict access to edit or modify work items, test cases, or test plans assigned to those areas. You can restrict access to users or groups. You can also set permissions for who can add or modify areas or iterations for the project.
Note
Project members granted permissions to create or edit Area Paths or Iteration Paths is separate from the permissions that control configuring team Area Paths and Iteration Paths. To configure team settings, you must be added to the team administrator role, or be a member of the Project Administrators group. *
Define both areas and iterations for a project from the Project Settings > Project configuration.
Choose (1) Project Settings, then choose (2) Project configuration under Boards, and then choose (3) Areas or Iterations to modify Area Paths or Iteration Paths.
Choose the ... context menu for the node you want to manage and select Security.
Select the group or project member, and then change the permission settings. To add a user or group, enter their name in the search box.
For example, here we added the Disallow Access Group, and disallowed members of this group the ability to view, modify, or edit work items in the Account Management area path.
You can specify two explicit authorization states for permissions: Deny and Allow. In addition, permissions can exist in one of three other states. To learn more, see Get started with permissions, access, and security groups.
(Optional) Choose the Inheritance slider to disable inheritance. Disabling Inheritance persists all inherited permissions as explicit Access Control Entries (ACEs).
When you're done, close the dialog. Your changes are automatically saved.
You define both areas and iterations for a project from the Project Settings>Project configuration.
Choose (1) Project Settings, then choose (2) Project configuration under Boards, and then choose (3) Areas.
Choose the ... context menu for the node you want to manage and select Security.
Select the group or team member, and then change the permission settings. To add a user or group, enter their name in the search box.
For example, here we've added the Disallow Access Group, and disallowed members of this group the ability to view, modify, or edit work items in the Customer Service area path.
You can specify two explicit authorization states for permissions: Deny and Allow. In addition, permissions can exist in one of three other states. To learn more, see Get started with permissions, access, and security groups.
(Optional) Toggle Inheritance to Off to disable inheritance. Disabling Inheritance persists all inherited permissions as explicit Access Control Entries (ACEs).
When you're done, close the dialog. Your changes are automatically saved.
From the web portal for the project, choose the
gear icon.
If you're currently working from a team context, then hover over the
and choose Project settings.
Choose Work and then Areas.
Choose the ... context menu for the node you want to manage and select Security.
Set permissions on queries or query folders
You can specify who can add or edit query folders or queries at the object-level. To manage permissions for a query or query folder, you must be the creator of the query or folder, a member of the Project Administrators or Project Collection Administrators group, or granted explicit access through the object's Security dialog.
Query folder Permissions dialog
To learn more about queries, see Create managed queries to list, update, or chart work items.
Set permissions on work item tags
By default, all users of the Contributors group can create and add tags to work items. To set permissions for a group or user to restrict this ability, you can set the Create tag definition to Deny at the project-level. To learn how, see Change the permission level for a project-level group.
Manage permissions for Delivery Plans
Delivery Plans are an object within a project. You manage plan permissions for each plan similar to the way you manage permissions for shared queries or query folders. The creator of a Delivery Plan and all members of the Project Collection Administrators and Project Administrators groups have permissions to edit, manage, and delete plans.
To edit the permissions for a Delivery Plan, you must be the creator of the plan, a member of the Project Administrators or Project Collection Administrators group, or granted explicit permission through the plan's Security dialog.
Open Boards > Delivery Plans.
To grant permissions to a group or user to manage or edit a specific plan, choose
More options to open the Security dialog for the plan.
Add a user, team group, or other security group who you want to grant permissions to or restrict access. For details, see Change project-level permissions. By default, nonadministrators can't delete or edit a plan.
With the user or group selected, set the permission you want them to have to Allow. Manage set to Allow enables the user to manage permissions for the plan.
For example, here we grant permission to Cristina to edit the plan.
When you're done, close the dialog. The changes are automatically saved.
Open Boards>Plans. For details, see Review team delivery plans.
To grant permissions to a group or user to manage or edit a specific plan, choose the
actions icon to open the Security dialog for the plan.
Add a user, team group, or other security group who you want to grant permissions to or restrict access. For details, see Change project-level permissions. By default, nonadministrators can't delete or edit a plan.
With the user or group selected, set the permission you want them to have to Allow. Manage set to Allow enables the user to manage permissions for the plan.
For example, here we grant permission to Raisa to edit the plan.
Choose Save changes when done.
Select Work > Plans. For more information, see Review team delivery plans.
To grant permissions to a group or user to manage or edit a specific plan, choose the
actions icon to open the Security dialog for the plan.
Add a user, team group, or other security group who you want to grant permissions to or restrict access. (For details, see Change project-level permissions). By default, nonadministrators can't delete or edit a plan.
With the user or group selected, set the permission you want them to have to Allow.
For example, here we grant permission to Raisa to edit the plan.
Choose Save changes when you're done.
Move or permanently delete work items
By default, Project Administrators and Contributors can change the work item type and delete work items by moving them to the Recycle Bin. Only Project Administrators can permanently delete work items and test artifacts. Project admins can grant permissions to other team members as needed.
For example, as a project admin you can grant a user, team group, or other group you've created to have these permissions. Open the Security page for the project and choose the user or group you want to grant permissions. To learn how to access project-level Security, see Change project-level permissions.
Note
The Move work items out of this project permission requires the project uses the Inherited process model.
In this example, we grant members assigned to the team administrator role, who belong to the Team Admin groups, permissions to move work items to another project and to permanently delete work items.
Manage test plans and test suites
In addition to the project-level permissions set in the previous section, team members need permissions to manage test artifacts that are set for an area path.
Open the Security page for area paths and choose the user or group you want to grant permissions.
Set the permissions for Manage test plans and Manage test suites to Allow.
To have full access to the Test feature set, your access level must be set to Basic + Test Plans. Users with Basic access and with permissions to permanently delete work items and manage test artifacts can only delete orphaned test cases.
Customize an inherited process
By default, only Project Collection Administrators can create and edit processes. However, these admins can grant permissions to other team members by explicitly setting the Create process, Delete process, or Edit process permissions at the collection level for a specific user.
To customize a process, you need to grant Edit process permissions to a user account for the specific process.
Note
Users added to the Project-Scoped Users group won't be able to access Process settings if the Limit user visibility and collaboration to specific projects preview feature is enabled for the organization. For more information including important security-related call-outs, see Manage your organization, Limit user visibility for projects and more.
Open the … context menu for the inherited process and choose Security. To open this page, see Customize a project using an inherited process.
Add the account name of the person you want to grant permissions to, set the permissions to Allow that you want them to have, and then you can exit the page and it automatically saves.
Here we add Christie Church and allow Christie to edit the process.
Note
Each process is a securable unit and has individual access control lists (ACLs) that govern creating, editing, and deleting inherited processes. At the collection level, project collection administrators can choose which processes can be inherited from and by whom. When you create a new inherited process, the process creator as well as project collection administrators have full control of the process and can also set individual ACLs for other users and groups to edit and delete the process.
More options for restricting access to work items
For more information about options for customizing work item types to support restrictions, see Restrict access, Restrict modification of work items based on a user or group.
Related articles
Feedback
Submit and view feedback for