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
✔️
✔️
✔️
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)
✔️
✔️
✔️
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 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.
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
✔️
Delivery plans
Delivery plans display work items as cards against a calendar view. This format can be an effective communication tool with managers, partners, and stakeholders for a team. 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.
You can manage permissions for individual plans. To learn more, see Edit or manage Delivery Plan permissions.
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
✔️
✔️
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:
- 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.