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.

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.

Boards

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

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.

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.

Queries and semantic search

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.

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.

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.

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.

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:

• Azure DevOps Services: Add users and assign licenses in Azure DevOps
• Azure DevOps Server, TFS: Change access levels

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

Related notes

• Set permissions and access for work tracking
• Get started as a Stakeholder
• Add another team
• Manage teams and configure team tools
• Work item form IndexDB caching issues