Partager via


Permissions and access for work tracking

TFS 2017 | TFS 2015 | TFS 2013

As a member of an Azure DevOps project, you can use most of the features to track work. Limitations to select features are based on the access level and security group to which a user is assigned. The Basic access level and higher supports full access to all features under the Work hub. Stakeholder access level provides partial support to select features, allowing users to view and modify work items, but not use all features. The built-in security groups—Readers, Contributors, and Project Administrators— and team administrator role grant permissions to specific features.

In the tables provided in this article, a ✔️ indicates that the corresponding access level or security group has access to a feature by default.

Note

Team administrators can configure settings for their team's tools. Organization owners and members of the Project Administrators group can configure settings for all teams. To be added as an administrator, see Add team administrators or Change project-level permissions.

For a comparison chart of Stakeholder versus Basic access, see the Feature matrix. To assign or change an access level, see Add users and assign licenses. If you need to grant specific users select permissions, you can do so.

Work items

You can use work items to track anything you need to track. To learn more, see Understand how work items are used to track issues, tasks, and epics.

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

✔️

✔️

✔️

Delete and restore work items (Project-level permission) (able to restore from the Recycle bin)

✔️

✔️

Permanently delete work items (Project-level permission)

✔️

✔️

✔️

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. To learn more about conditional rules, see Rules and rule evaluation.

Boards

You use Boards to implement Kanban methods. Boards present work items as cards and support quick status updates through drag-and-drop.

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

Backlogs display work items as lists. A product backlog represents your project plan and a repository of all the information you need to track and share with your team. Portfolio backlogs allow you to group and organize your backlog into a hierarchy.

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

You use sprint tools to implement Scrum methods. The Sprints set of tools provide filtered views of work items that a team has assigned to specific iteration paths or sprints.

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

✔️

Queries are filtered lists of work items based on criteria that you define by using a query editor. Adhoc searches are powered by a semantic search engine.

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

✔️

Test management

Test plans, test suites, test cases and other test artifacts are specific work item types that support manual and exploratory testing. You set test permissions at the project level from the Project settings>Security page.

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:

  • 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:

  • 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

Project-level resources

You set project-level information permissions from Project settings > Permissions. You set permissions for area and iteration paths under Project settings> Project configuration. These resources are defined for a project which all valid users of the project can view.


Task

Stakeholder

Readers

Contributors

Team Admins

Project Admins


✔️

✔️

✔️

✔️

✔️


✔️

✔️

✔️


✔️

✔️

✔️

✔️

✔️


✔️


✔️

✔️

✔️

✔️

✔️


The Edit project-level information permission includes the ability to perform these tasks for the project:

  • Create and modify areas and iterations
  • Edit check-in policies
  • Edit shared work item queries
  • Edit project level permission ACLs
  • Create and modify global lists
  • Edit event subscriptions (email or SOAP) on project level events.

Team administrator role and permissions

The following table summarizes a subset of the default permissions assigned to the project Readers, Contributors and Project Administrators groups and the Team Administrator role. Team admin permissions extend only to the team for which they're an administrator. Project Administrator permissions extend across all teams defined for the project.

Permission

Readers

Contributors

Team Administrators

Project Administrators

  

  

✔️

✔️

  

  

✔️

✔️

✔️

✔️

✔️

✔️

Manage shared query and query folder permissions
(Contribute, Delete, Manage Permissions)

  

  

  

✔️

  

  

✔️

✔️

Stakeholder access

Stakeholder access supports business owners and analysts and other team members who don't contribute to code, build, and test activities. They contribute by adding ideas to the backlog, adding context and information to work items, and reviewing status and progress. All members of an organization who don't use Visual Studio but want to contribute to work item tracking and monitor progress can be assigned as a stakeholder. To learn more about Stakeholder access, see Work as a stakeholder.

For a comparison chart of Stakeholder versus basic access, see the Feature Matrix.

For information about each access levels, see About access levels. To assign access levels, see:

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:

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

Default permissions assigned to team contributors

If your on-premises TFS deployment includes reporting or SharePoint Products, add users to those resources. See Grant permissions to view or create SQL Server reports in TFS and Set SharePoint site permissions.