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.

For more information, see Add groups.

Default permissions for Boards, backlogs, and sprints

Boards default permissions

Backlogs default permissions

Sprints default permissions

1. 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.

   

2. Select Work > Areas.

3. Select the ... context menu for the node you want to manage and choose Security.

   

Default permissions for work items

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.

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

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.

1. Select Work > Plans. For more information, see Review team delivery plans.

2. 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.

   

3. 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.

4. With the user or group selected, set the permission you want them to have to Allow.

   

5. Save when you're done.

Default permissions for Delivery Plans

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.

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.

Related articles

• Grant or restrict access
• Rules and rule evaluation
• Permissions and groups reference
• Delete test artifacts