Set work tracking permissions
TFS 2018
To manage work tracking effectively, you can grant or restrict access to different features. Do so by assigning specific permissions to users or groups for a particular object, project, or collection. You also can define custom rules for processes or projects that apply to specific users or groups, thereby controlling their actions accordingly. For most features, we recommend that you add users to the project's Contributors group, which grants comprehensive access and ensures a seamless and efficient work tracking experience.
Prerequisites
- To set process permissions, you must be a member of the Project Collection Administrators group or have explicit permissions to edit a collection process.
Understand roles and permission levels for work tracking
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. Also, see Default permissions for Boards, Backlogs, Sprints, Delivery Plans, Test Management, and Queries, further in this article.
Role or permission level
Functional areas set
Team administrator role
Add a team administrator
Object-level permissions
Project-level permissions
Project collection-level permissions
Includes all permissions you can set at the collection-level.
For more information, see Add groups.
Default permissions for Boards, backlogs, and sprints
Boards default permissions
Task
Readers
Contributors
Team admins
Project admins
View boards and open work items
✔️
✔️
✔️
Add work items to a board; update status, reorder, or reparent child items through drag-and-drop; update a field on a card
✔️
✔️
Add child items to a checklist
✔️
✔️
Assign to a sprint (from card field)
✔️
✔️
Configure board settings
✔️
Backlogs default permissions
Task
Readers
Contributors
Team admins
Project admins
View backlogs and open work items
✔️
✔️
✔️
Add work items to a backlog
✔️
✔️
Use bulk edit features
✔️
✔️
Add child items to a backlog item; prioritize or reorder a backlog; parent items using the Mapping pane; Assign items to a sprint using drag-and-drop
✔️
✔️
Configure team settings, backlog levels, show bugs, work days off
✔️
Sprints default permissions
Task
Readers
Contributors
Team admins Project admins
Add work items to a sprint backlog or taskboard
✔️
✔️
Prioritize/reorder a sprint backlog or taskboard; add child items to a backlog item; reassign items to a sprint using the Planning pane
✔️
✔️
View team capacity and work details
✔️
✔️
Set team capacity
✔️
Use bulk edit features
✔️
✔️
Define team sprints
✔️
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 with permissions to create or edit Area Paths or Iteration Paths can't set 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.
From the web portal for the project, select
Settings.
If you're working from a team context, then hover over the
and select Project settings.
Select Work > Areas.
Select the ... context menu for the node you want to manage and choose Security.
Default permissions for work items
Task or permission
Readers
Contributors
Project admins
View work items in this node (Area Path permission)
✔️
✔️
✔️
Edit work items in this node (Area Path permission)
✔️
✔️
Create tag definition
✔️
✔️
Email work items
✔️
✔️
✔️
Apply a work item template
✔️
✔️
Delete and restore work items (Project-level permission) (able to restore from the Recycle bin)
✔️
✔️
Permanently delete work items (Project-level permission)
✔️
Provide feedback (through the Microsoft Feedback client)
✔️
✔️
✔️
✔️
Note
Work items are subject to rules applied to them. Conditional rules based on user or group membership are cached for your web browser. If you find yourself restricted to update a work item, you may have encountered one of these rules. If you believe you've encountered an issue that doesn't apply to you, see Work item form IndexDB caching issues. For more information, see Rules and rule evaluation.
Use custom rules
Custom rules don't control permissions, but they affect whether a user can 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.
| Customization | Examples |
|---|---|
| Apply rules upon work item creation, state change, and specified state. | - Make a field read-only - Make a field required |
| Apply rules when a field value is empty, set to a specific value, or change or not changed to a value. | - Clear the value of a field if it's empty or meets certain criteria - Set a predefined value for the field if it's empty or meets specific conditions - Copy the value of one field to another field - Hide a field based on certain conditions or values |
| Apply rules that dictate what state a work item can get moved to from a given state. | - Reassign a work item based on state changes - Specify that a work item can only transition from "State A" to "State B" - Manage the state transitions of parent work items based on the state changes of their child work items |
| Apply rules based on user or group membership of the user modifying a work item. | Specify rules that restrict a group from creating a work item, transitioning a work item to a closed or completed state, or changing the value of a field |
There are some restrictions for 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 they're system fields. For more information, see Rules and rule evaluation and Sample rule scenarios.
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 more information, see Create managed queries to list, update, or chart work items.
Default permissions for queries
Tip
By default, Contributors can't create and save shared queries. We recommend that Project Administrators create a query folder for each team and give the team administrators or the team group query permissions to manage their folder. You need Delete permissions to rename or move a shared query or folder, and Contribute permissions for the folder where you move the query to. To learn more, see Set permissions on queries and query folders.
Task
Readers
Contributors
Project admins
Create and save managed My queries, query charts
✔️
✔️
Create, delete, and save Shared queries, charts, folders
✔️
Adhoc searches are powered by a semantic search engine.
Set permissions for 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 can manage permissions for each plan like 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.
Users granted Stakeholder access for private projects have no access to delivery plans, while users granted Stakeholder access for public projects has the same access as regular Contributors granted Basic access. For a comparison chart of Stakeholder versus basic access, see the Feature Matrix.
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.
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.
Save when you're done.
Default permissions for Delivery Plans
Task
Readers
Contributors
Team admins
Project admins
Create, edit, or delete a delivery plan, Contributors can only edit or delete plans that they create
✔️
✔️
Manage permissions for a delivery plan, Contributors can only manage permissions for plans that they create
✔️
✔️
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.
Default permissions for test management
Test plans, test suites, test cases and other test artifacts are specific work item types that support manual and exploratory testing. For more information, see Set test permissions at the project level.
Permission
Level
Readers
Contributors
Project Admins
View test runs
Project-level
✔️
✔️
✔️
Create test runs
Delete test runs
Project-level
✔️
✔️
Manage test configurations
Manage test environments
Project-level
✔️
✔️
Create tag definition
Delete and restore work items
Project-level
✔️
✔️
Permanently delete work items
Project-level
✔️
View work items in this node
Area Path
✔️
✔️
✔️
Edit work items in this node
Manage test plans
Manage test suites
Area Path
✔️
✔️
Area permissions for web-based test case management and test execution control access to the following actions.
The Manage test suites permission enables users to do the following tasks:
- Create and modify test suites
- Add or remove test cases to/from test suites
- Change test configurations associated with test suites
- Modify the suite hierarchy by moving a test suite
The Manage test plans permission enables users to do the following tasks:
- Create and modify test plans
- Add or remove test suites to or from test plans
- Change test plan properties such as build and test settings
More access options for 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.
Grant team members additional permissions
For teams to work autonomously, you may want to provide them with permissions that they don't have by default. Suggested tasks include providing team administrators or team leads permissions to:
- Create and edit child nodes under their default area path
- Create and edit child nodes under an existing iteration node
- Create shared queries and folders under the Shared Queries folder.
By default, team members inherit the permissions afforded to members of the project Contributors group. Members of this group can add and modify source code, create and delete test runs, and create and modify work items. They can collaborate on a Git project or collaborate with other team members and check in work to the team's code base (TFVC).
If your on-premises deployment includes reporting, add users to those resources. See Grant permissions to view or create SQL Server reports.