Set work tracking permissions
Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2013
You 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 which may restrict or require users to perform a select action. In general, you'll 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.
Support business workflows through custom rules
Custom rules don't set permissions, but do impact the effective 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.
- Apply select rules when a field value is empty,set to a specific value, or was changed or not changed to a value.
- Restrict the transition to a specific state when moving from a specified state.
- Apply select rules based on user or group membership of the user modifying a work item.
Common actions set by rules include:
- Make a field required or read-only
- Clear or set the value of a field, or copy a field value to another field
- Hide a field.
For example, you can specify rules that effectively restrict a group of users from performing the following tasks:
- Creating a work item
- Transitioning a work item to a closed or completed state
- Changing the value of a field.
Or, perform the following automations:
- Reassign a work item based on state change
- State transitions of parent work items based on state changes made to their child work items.
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
- Edit collection level permissions
Project collection-level permissions include all permissions you can set at the collection-level.
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
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.
From the web portal, choose the
gear icon to open project administration pages. Then choose Areas.
Choose the context menu for the node you want to manage.
Select the group or team member, and then change the permission settings. If you don't see the group you want, try adding it first.
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 additional states. To learn more, see Get started with permissions, access, and security groups.
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
For details, see Set permissions on a shared query or query folder. To learn more about queries, see Create managed queries to list, update, or chart work items.
Additional options for restricting access to work items
See Restrict access, Restrict modification of work items based on a user or group for additional options for customizing work item types to support restrictions.