Security groups, service accounts, and permissions in Azure DevOps
TFS 2018
This article provides a comprehensive reference for each built-in user, group, and permission.
For a quick reference to default assignments, see Default permissions and access. For an overview of how permissions and security are managed, see Get started with permissions, access, and security groups. In addition to security groups, there are also security roles, which provide permissions for select areas.
To learn how to add users to a group or set a specific permission that you can manage through the web portal, see the following resources:
Users and groups
- Add users to the Project Administrators group
- Add users to the Project Collection Administrators group
- Add a server-level administrator
- Add users to a project or team
- Add a team administrator
Wiki
DevOps
Work tracking
Reporting
Note
The images shown in your web portal may differ from the images in this article. These differences result from updates made to Azure DevOps. However, the basic functionality available to you remains the same unless explicitly mentioned.
Service accounts
There are a few service accounts that the system generates to support specific operations. The following table describes these user accounts, which get added at the organization or collection level.
| User name | Description |
|---|---|
| Agent Pool Service | Has permission to listen to the message queue for the specific pool to receive work. In most cases, you shouldn't have to manage members of this group. The agent registration process takes care of it for you. The service account you specify for the agent (commonly Network Service) is automatically added when you register the agent. Responsible for performing Azure Boards read/write operations and updating work items when GitHub objects are updated. |
| Azure Boards | Added when Azure Boards is connected to GitHub. You shouldn't have to manage members of this group. Responsible for managing the link creation between GitHub and Azure Boards. |
| PipelinesSDK | Added as needed to support the Pipelines policy service scope tokens. This user account is similar to the build service identities but supports locking down permissions separately. In practice, the tokens that involve this identity are granted read-only permissions to pipeline resources and the one-time ability to approve policy requests. This account should be treated in the same way that the build service identities are treated. |
| ProjectName Build Service | Has permissions to run build services for the project and is a legacy user used for XAML builds. It's added to the Security Service Group, which is used to store users who have been granted permissions, but not added to any other security group. |
| Project Collection Build Service | Has permissions to run build services for the collection. It's added to the Security Service Group, which is used to store users who have been granted permissions, but not added to any other security group. |
Groups
You can grant permissions directly to an individual, or to a group. Using groups makes things simpler and the system provides several built-in groups for that purpose. These groups and the default permissions they're assigned get defined at different levels: server (on-premises deployment only), project collection, project, and specific objects. You can also create your own groups and grant them the specific set of permissions that are appropriate for certain roles in your organization.
Server-level groups
When you install Azure DevOps Server, the system creates default groups that have deployment-wide, server-level permissions. You can't remove or delete the built-in server-level groups.
You can't remove or delete the default server level groups.
Note
The full name of each of these groups is [Team Foundation]\{group name}. So the full name of the server level administrators group is [Team Foundation]\Team Foundation Administrators.
Group name
Permissions
Membership
Team Foundation Administrators
Has permissions to perform all server-level operations.
Local Administrators group (BUILTIN\Administrators) for any server that hosts Azure DevOPs/Team Foundation application services.
Server \Team Foundation Service Accounts group and the members of the \Project Server Integration Service Accounts group.
This group should be restricted to the smallest possible number of users who need total administrative control over server-level operations.
Note
If your deployment uses Reporting, consider adding the members of this group to the Content Managers groups in Reporting Services.
Team Foundation Proxy Service Accounts
Has service level permissions for Team Foundation Server Proxy, and some service-level permissions.
Note
This account is created when you install the TFS proxy service.
This group should contain only service accounts and not user accounts or groups that contain user accounts.
Team Foundation Service Accounts
Has service-level permissions for the server instance.
Contains the service account that was supplied during installation
This group should contain only service accounts and not user accounts or groups that contain user accounts. By default, this group is a member of Team Foundation Administrators.
If you need to add an account to this group after you install Azure DevOps Server, you can do so using
the TFSSecurity.exe utility in the Tools subfolder of your TFS installation directory.
Use the following command: TFSSecurity /g+ "[TEAM FOUNDATION]\Team Foundation Service Accounts" n:domain\username /server:http(s)://tfsservername.
Team Foundation Valid Users
Has permission to view server instance-level information.
Note
If you set the View instance-level information permission to Deny or Not set for this group, no users will be able to access the deployment.
Contains all users known to exist in the server instance. You can't modify the membership of this group.
Collection-level groups
When you create an organization or project collection in Azure DevOps, the system creates collection-level groups that have permissions in that collection. You can't remove or delete the built-in collection-level groups.
The full name of each of these groups is [{collection name}]\{group name}. So the full name of the administrator group for the default collection is [Default Collection]\Project Collection Administrators.
Group name
Permissions
Membership
Project Collection Administrators
Has permissions to perform all operations for the collection.
Contains the Local Administrators group (BUILTIN\Administrators) for the server where the application-tier services have been installed. Contains the members of the CollectionName/Service Accounts group. This group should be restricted to the smallest possible number of users who need total administrative control over the collection.
Note
If your deployment uses Reporting Services, consider adding the members of this group to the Team Foundation Content Managers groups in Reporting Services.
Project Collection Build Administrators
Has permissions to administer build resources and permissions for the collection.
Limit this group to the smallest possible number of users who need total administrative control over build servers and services for this collection.
Project Collection Build Service Accounts
Has permissions to run build services for the collection.
Limit this group to service accounts and groups that contain only service accounts. This is a legacy group used for XAML builds. Use the Project Collection Build Service ({your organization}) user for managing permissions for current builds.
Project Collection Proxy Service Accounts
Has permissions to run the proxy service for the collection.
Limit this group to service accounts and groups that contain only service accounts.
Project Collection Service Accounts
Has service level permissions for the collection and for Azure DevOps Server.
Contains the service account that was supplied during installation. This group should contain only service accounts and groups that contain only service accounts. By default, this group is a member of the Administrators group.
Project Collection Test Service Accounts
Has test service permissions for the collection.
Limit this group to service accounts and groups that contain only service accounts.
Project Collection Valid Users
Has permissions to access team projects and view information in the collection.
Contains all users and groups that have been added anywhere within the collection. You can't modify the membership of this group.
Security Service Group
Used to store users who have been granted permissions, but not added to any other security group.
Don't assign users to this group. If you're removing users from all security groups, check if you need to remove them from this group.
Project-level groups
For each project that you create, the system creates the followings project-level groups. These groups are assigned project-level permissions.
Tip
The full name of each of these groups is [{project name}]\{group name}. For example, the contributors group for a project called "My Project" is [My Project]\Contributors.
Group name
Permissions
Membership
Build Administrators
Has permissions to administer build resources and build permissions for the project. Members can manage test environments, create test runs, and manage builds.
Assign to users who define and manage build pipelines.
Contributors
Has permissions to contribute fully to the project code base and work item tracking. The main permissions they don't have are permissions that manage or administer resources.
By default, the team group created when you create a project is added to this group, and any user you add to the team or project is a member of this group. In addition, any team you create for a project is added to this group.
Readers
Has permissions to view project information, the code base, work items, and other artifacts but not modify them.
Assign to members of your organization or collection who you want to provide view-only permissions to a project. These users can view backlogs, boards, dashboards, and more, but not add or edit anything.
Has permissions to administer all aspects of teams and project, although they can't create team projects.
Assign to users who manage user permissions, create or edit teams, modify team settings, define area or iteration paths, or customize work item tracking. Members of the Project Administrators group have permissions to perform the following tasks:
- Add and remove users from project membership
- Add and remove custom security groups from a project
- Add and administer all project teams and team-related features
- Edit project level permission ACLs
- Edit event subscriptions (email or SOAP) for teams or project-level events.
Project Valid Users
Has permissions to access and view project information.
Contains all users and groups that have been added anywhere to the project. You can't modify the membership of this group.
Note
We recommend that you don't change the default permissions for this group.
Release Administrators
Has permissions to manage all release operations.
Assign to users who define and manage release pipelines.
Note
The Release Administrator group is created at the same time the first release pipeline is defined. It isn't created by default when the project is created.
Has permissions to contribute fully to the project code base and work item tracking.
The default Team group is created when you create a project, and by default is added to the Contributors group for the project. Any new teams you create will also have a group created for them and added to the Contributors group.
Add members of the team to this group. To grant access to configure team settings, add a team member to the team administrator role.
Team administrator role
For each team that you add, you can assign one or more team members as administrators. The team admin role isn't a group with a set of defined permissions. Instead, the team admin role is tasked with managing team assets. For more information, see Manage teams and configure team tools. To add a user as a team administrator, see Add a team administrator.
Note
Project Administrators can manage all team administrative areas for all teams.
Permissions
The system manages permissions at different levels—server, collection, project, object and role-based permissions—and by default assigns them to one or more built-in groups. You can manage most permissions through the web portal. You can manage more permissions by using one or more security management tools, specifying a namespace permission.
In the following sections, the namespace permission is provided following the permission label that displays in the user interface. For example:
Create tag definition
Tagging, Create
For more information, see Security namespace and permission reference.
Server-level permissions
Manage server-level permissions through the Team Foundation Administration Console or TFSSecurity command-line tool. Team Foundation Administrators are granted all server-level permissions. Other server-level groups have select permission assignments.
Permission (UI)
Namespace permission
Description
Only valid for Azure DevOps Server 2020 and earlier versions that are configured to support SQL Server reports. Can process or change settings for the data warehouse or SQL Server Analysis cube by using the Warehouse Control Web Service.
More permissions may be required to fully process or rebuild the data warehouse and Analysis cube.
Can create and administer collections.
Can delete a collection from the deployment.
Note
Deleting a collection won't delete the collection database from SQL Server.
Can edit server-level permissions for users and groups, and add or remove server level groups from the collection.
Note
Edit instance-level information includes the ability to perform these tasks defined in all collections defined for the instance:
- Modify Extensions and Analytics settings
- Implicitly allows the user to modify version control permissions and repository settings
- Edit event subscriptions or alerts for global notifications, project-level, and team-level events
- Edit all project and team-level settings for projects defined in the collections
- Create and modify global lists
To grant all these permissions at a command prompt, you must use the tf.exe Permission command to grant the AdminConfiguration and AdminConnections permissions in addition to GENERIC_WRITE.
Can perform operations on behalf of other users or services. Only assign to service accounts.
Can trigger server-level alert events. Only assign to service accounts and members of the Azure DevOps or Team Foundation Administrators group.
Can use all on-premises Web portal features. This permission is deprecated with Azure DevOps Server 2019 and later versions.
Note
If the Use full Web Access features permission is set to Deny, the user will only see those features permitted for the Stakeholder group (see Change access levels). A Deny will override any implicit Allow, even for accounts that are members of administrative groups such as Team Foundation Administrators.
Can view server level group membership and the permissions of those users.
Note
The View instance-level information permission is also assigned to the Azure DevOps Valid Users group.
Collection-level permissions
Manage collection-level permissions through the web portal admin context or the TFSSecurity command-line tool. Project Collection Administrators are granted all collection-level permissions. Other collection-level groups have select permission assignments.
Important
The permission to add or remove organization or collection-level security groups, add and manage organization or collection-level group membership, and edit collection and project-level permission ACLs is assigned to all members of the Project Collection Administrators group. It isn't controlled by a permissions surfaced within the user interface.
You can't change the permissions for the Project Collection Administrators group. Also, while you can change the permission assignments for a member of this group, their effective permissions will still conform to those assigned to the administrator group for which they are a member.
Permission (UI)
Namespace permission
Description
Can modify permissions for build pipelines at the project collection-level. This includes the following artifacts:
Can delete shelvesets created by other users. Applies when TFVC is used as the source control.
Can create and delete workspaces for other users. Applies when TFVC is used as the source control.
Can change the trace settings for gathering more detailed diagnostic information about Azure DevOps Web services.
Can create a version control workspace. Applies when TFVC is used as the source control. This permission is granted to all users as part of their membership within the Project Collection Valid Users group.
Can add projects to a project collection. Additional permissions may be required depending on your on-premises deployment.
Can delete a project.
Note
Deleting a project deletes all data that is associated with the project. You cannot undo the deletion of a project except by restoring the collection to a point before the project was deleted.
Can set organization and project-level settings.
Note
Edit collection-level information includes the ability to perform these tasks for all projects defined in an organization or collection:
- Modify Extensions, and Analytics settings
- Modify version control permissions and repository settings
- Edit event subscriptions or alerts for global notifications, project-level, and team-level events
- Edit all project and team-level settings for projects defined in the collections.
Can perform operations on behalf of other users or services. Assign this permission only to on-premises service accounts.
Can manage build computers, build agents, and build controllers.
Can download, create, edit, and upload process templates. A process template defines the building blocks of the work item tracking system as well as other subsystems you access through Azure Boards. Requires the collection to be configured to support ON=premises XML process model.
Can register and de-register test controllers.
Can trigger project alert events within the collection. Assign only to service accounts. Users with this permission can't remove built-in collection level groups such as Project Collection Administrators.
Can reserve and allocate build agents. Assign only to service accounts for build services.
Can view, but not use, build controllers and build agents that are configured for an organization or project collection.
Can view collection-level permissions for a user or group.
Can call the synchronization application programming interfaces. Assign only to service accounts.
Project-level permissions
Manage project-level permissions through the web portal admin context or the TFSSecurity command-line tool. Project Administrators are granted all project-level permissions. Other project-level groups have select permission assignments.
Note
Several permissions granted to members of the Project Administrators group don't surface within the user interface.
Permission (UI)
Namespace permission
Description
Users with this permission can save a work item that ignores rules, such as copy, constraint, or conditional rules, defined for the work item type. Useful for migrations where you don't want to update the by or date fields on import, or when you want to skip the validation of a work item.
Rules can be bypassed in one of two ways. The first is through the Work Items - update REST API and setting the bypassRules parameter to true. The second is through the client object model, by initializing in bypass rules mode (initialize WorkItemStore with WorkItemStoreFlags.BypassRules).
Can add tags to a work item. By default, all members of the Contributors group have this permission. Also, you can set more tagging permissions through security management tools. See Security namespace and permission reference, Tagging.
Note
All users granted Stakeholder access can only add existing tags. Even if the Create tag definition permission is set to Allow, stakeholders can't add tags. This is part of the Stakeholder access settings. For more information, see Stakeholder access quick reference. Although the Create tag definition permission appears in the security settings at the project-level, tagging permissions are actually collection level permissions that are scoped at the project level when they appear in the user interface. To scope tagging permissions to a single project when using the TFSSecurity command, you must provide the GUID for the project as part of the command syntax. Otherwise, your change will apply to the entire collection. Keep this in mind when changing or setting these permissions.
Can add and remove test results and add or modify test runs. For more information, see Control how long to keep test results and Run manual tests.
Can mark work items in the project as deleted. The Contributors group has Delete and restore work items at the project-level set to Allow by default.
Can delete a project from an organization or project collection.
Can delete a test run.
Can perform the following tasks for the selected project defined in an organization or collection.
Note
The permission to add or remove project-level security groups and add and manage project-level group membership is assigned to all members of the Project Administrators group. It isn't controlled by a permissions surfaced within the user interface.
Can provide or edit metadata for a project. For example, a user can provide high-level information about the contents of a project. Changing metadata is supported through the Set project properties REST API.
Can create and delete test configurations.
Can create and delete test environments.
Can move a work item from one project to another project within the collection.
Can permanently delete work items from this project.
Users with this permission can update work items without generating notifications. Useful for performing migrations of bulk updates by tools and skipping generating notifications.
Consider granting this permission to service accounts or users who have been granted the Bypass rules on work item updates permission. You can set the suppressNotifications parameter to true when updating working via Work Items - update REST API.
Can change the project visibility from private to public or public to private. Applies to Azure DevOps Services only.
Can access data available from the Analytics service. For more information, see Permissions required to access the Analytics service.
Can view project level group membership and permissions.
Can view test plans under the project area path.
Dashboards (object-level)
Permissions for team dashboards can be set individually. The default permissions for a team can be set for a project. Manage the security of dashboards from the web portal.
Team dashboard default permissions
By default, team administrators are granted all permissions for their team dashboards, including managing default and individual dashboard permissions.
PermissionNamespace permission |
Description |
|---|---|
Create dashboardsDashboardsPrivileges, Create |
Can create a team dashboard. |
Delete dashboardsDashboardsPrivileges, Delete |
Can delete a team dashboard. |
Edit dashboardsDashboardsPrivileges, Edit |
Can add widgets to and change the layout of a team dashboard. |
Individual team dashboard permissions
Team administrators can change the permissions for individual team dashboards by changing the following two permissions.
PermissionNamespace permission |
Description |
|---|---|
Delete dashboardDashboardsPrivileges, Delete |
Can delete the specific team dashboard. |
Edit dashboardDashboardsPrivileges, Edit |
Can add widgets to and change the layout of the specific team dashboard. |
Pipeline or Build (object-level)
Manage pipeline permissions for each pipeline defined in the web portal or using the TFSSecurity command-line tool. Project Administrators are granted all pipeline permissions and Build Administrators are assigned most of these permissions. You can set pipeline permissions for all pipelines defined for a project or for each pipeline definition.
Permissions in Build follow a hierarchical model. Defaults for all the permissions can be set at the project level and can be overridden on an individual build definition.
To set the permissions at project level for all build definitions in a project, choose Security from the action bar on the main page of Builds hub.
To set or override the permissions for a specific build definition, choose Security from the context menu of the build definition.
You can define the following permissions in Build at both levels.
Permission (UI)
Namespace permission
Description
Can administer the build permissions for other users.
Can delete build definitions for this project.
Can delete a completed build. Builds that are deleted are retained in the Deleted tab for some time before they're destroyed.
Can permanently delete a completed build.
Edit build pipeline Can save any changes to a build pipeline, including configuration variables, triggers, repositories, and retention policy. Available with Azure DevOps Services, Azure DevOps Server 2019 1.1, and later versions. Replaces Edit build definition.
Edit build definition Can create and modify build definitions for this project.
Note
You turn Inheritance Off for a build definition when you want to control permissions for specific build definitions.
When inheritance is On, the build definition respects the build permissions defined at the project level or a group or user. For example, a custom Build Managers group has permissions set to manually queue a build for project Fabrikam. Any build definition with inheritance On for project Fabrikam would allow a member of the Build Managers group the ability to manually queue a build.
However, by turning Inheritance Off for project Fabrikam, you can set permissions that only allow Project Administrators to manually queue a build for a specific build definition. This would then allow me to set permissions for that build definition specifically.
Can add information about the quality of the build through Team Explorer or the web portal.
Can add or remove build qualities. Only applies to XAML builds.
Can cancel, re-prioritize, or postpone queued builds. Only applies to XAML builds.
Can commit a TFVC change set that affects a gated build definition without triggering the system to shelve and build their changes first.
Note
Assign the Override check-in validation by build permission only to service accounts for build services and to build administrators who are responsible for the quality of the code. Applies to TFVC gated check-in builds. This does not apply to PR builds. For more information, see Check in to a folder that is controlled by a gated check-in build process.
Can put a build in the queue through the interface for Team Foundation Build or at a command prompt. They can also stop the builds that they have queued.
Can toggle the retain indefinitely flag on a build. This feature marks a build so that the system won't automatically delete it based on any applicable retention policy.
Can stop any build that is in progress, including builds queued and started by another user.
Can add build information nodes to the system, and can also add information about the quality of a build. Assign only to service accounts.
Can view the build definitions that have been created for the project.
Can view the queued and completed builds for this project.
Git repository (object-level)
Manage the security of each Git repository or branch from the web portal, the TF command line tool, or using the TFSSecurity command-line tool. Project Administrators are granted most of these permissions (which appear only for a project that's been configured with a Git repository). You can manage these permissions for all Git repositories, or for a specific Git repo.
Note
Set permissions across all Git repositories by making changes to the top-level Git repositories entry. Individual repositories inherit permissions from the top-level Git repositories entry. Branches inherit permissions from assignments made at the repository level. By default, the project level Readers groups only have Read permissions.
To manage Git repo and branch permissions, see Set branch permissions.
Permission (UI)
Namespace permission
Description
Can opt in to override branch policies by checking Override branch policies and enable merge when completing a PR.
Note
Bypass policies when completing pull requests and Bypass policies when pushing replace Exempt From Policy Enforcement. Applies to Azure DevOps Server 2019 and later versions.
Can push to a branch that has branch policies enabled. When a user with this permission makes a push that would override branch policy, the push automatically bypasses branch policy with no opt-in step or warning.
Note
Bypass policies when completing pull requests and Bypass policies when pushing replace Exempt From Policy Enforcement. Applies to Azure DevOps Server 2019 and later versions.
At the repository level, can push their changes to existing branches in the repository and can complete pull requests. Users who lack this permission but who have the Create branch permission may push changes to new branches. Doesn't override restrictions in place from branch policies.
At the branch level, can push their changes to the branch and lock the branch. Locking a branch blocks any new commits from others and prevents other users from changing the existing commit history.
Can create, comment on, and vote on pull requests.
Can create and publish branches in the repository. Lack of this permission doesn't limit users from creating branches in their local repository; it merely prevents them from publishing local branches to the server.
Note
When a user creates a new branch on the server, they have Contribute, Edit Policies, Force Push, Manage Permissions, and Remove Others' Locks permissions for that branch by default. This means that users can add new commits to the repo via their branch.
Can create new repositories. This permission is only available from the Security dialog for the top-level Git repositories object.
Can push tags to the repository.
Can delete the repository. At the top-level Git repositories level, can delete any repository.
Can edit policies for the repository and its branches.
Applies to TFS 2018 Update 2. Can bypass branch policies and perform the following two actions:
- Override branch policies and complete PRs that don't satisfy branch policy
- Push directly to branches that have branch policies set
Note
In Azure DevOps it is replaced with the following two permissions: Bypass policies when completing pull requests and Bypass policies when pushing.
Can force an update to a branch, delete a branch, and modify the commit history of a branch. Can delete tags and notes.
Can push and edit Git notes.
Can set permissions for the repository.
Can clone, fetch, pull, and explore the contents of the repository.
Can remove branch locks set by other users. Locking a branch blocks any new commits from being added to the branch by others and prevents other users from changing the existing commit history.
Can change the name of the repository. When set at the top-level Git repositories entry, can change the name of any repository.
TFVC (object-level)
Manage the security of each TFVC branch from the web portal or using the TFSSecurity command-line tool. Project Administrators are granted most of these permissions, which appear only for a project that's been configured to use Team Foundation Version Control as a source control system. In version control permissions, explicit deny takes precedence over administrator group permissions.
These permissions appear only for a project setup to use Team Foundation Version Control as the source control system.
In version control permissions, explicit Deny takes precedence over administrator group permissions.
Permission (UI)
Namespace permission
Description
Administer labels
VersionControlItems, LabelOther
Can edit or delete labels created by another user.
Check in
VersionControlItems, Checkin
Can check in items and revise any committed change set comments. Pending changes are committed at check-in.
Note
Consider adding these permissions to any manually added users or groups that contributes to the development of the project; any users who should be able to check in and check out changes, make a pending change to items in a folder, or revise any committed change set comments.
Check in other users' changes
VersionControlItems, CheckinOther
Can check in changes that were made by other users. Pending changes are committed at check-in.
Pend a change in a server workspace
VersionControlItems, PendChange
Can check out and make a pending change to items in a folder. Examples of pending changes include adding, editing, renaming, deleting, undeleting, branching, and merging a file. Pending changes must be checked in, so users also need the Check-in permission to share their changes with the team.
Note
Consider adding these permissions to any manually added users or groups that contributes to the development of the project; any users who should be able to check in and check out changes, make a pending change to items in a folder, or revise any committed change set comments.
Label
VersionControlItems, Label
Can label items.
Can lock and unlock folders or files. A folder or file tracked can be locked or unlocked to deny or restore a user's privileges. Privileges include checking out an item for edit into a different workspace or checking in Pending Changes to an item from a different workspace. For more information, see Lock command.
Manage branch
VersionControlItems, ManageBranch
Can convert any folder under that path into a branch, and also take the following actions on a branch: edit its properties, reparent it, and convert it to a folder. Users who have this permission can branch this branch only if they also have the Merge permission for the target path. Users can't create branches from a branch for which they do not have the Manage Branch permission.
Manage permissions
VersionControlItems, AdminProjectRights
Can manage other users' permissions for folders and files in version control.
Note
Consider adding this permission to any manually added users or groups that contributes to the development of the project and that must be able to create private branches, unless the project is under more restrictive development practices.
Can merge changes into this path.
Note
Consider adding this permission to any manually added users or groups that contribute to the development of the project and that must be able to merge source files, unless the project is under more restrictive development practices.
Read
VersionControlItems, Read
Can read the contents of a file or folder. If a user has Read permissions for a folder, the user can see the contents of the folder and the properties of the files in it, even if the user does not have permission to open the files.
Revise other users' changes
VersionControlItems, ReviseOther
Can edit the comments on checked-in files, even if another user checked in the file.
Note
Consider adding this permission to any manually added users or groups that are responsible for supervising or monitoring the project and that might or must change the comments on checked-in files, even if another user checked in the file.
Undo other users' changes
VersionControlItems, UndoOther
Can undo a pending change made by another user.
Note
Consider adding this permission to any manually added users or groups that are responsible for supervising or monitoring the project and that might or must change the comments on checked-in files, even if another user checked in the file.
Unlock other users' changes
VersionControlItems, UnlockOther
Can unlock files locked by other users.
Note
Consider adding this permission to any manually added users or groups that are responsible for supervising or monitoring the project and that might or must change the comments on checked-in files, even if another user checked in the file.
Area path (object-level)
Area path permissions grant or restrict access to branches of the area hierarchy and to the work items in those areas. Manage the security of each area path from the web portal or using the TFSSecurity command-line tool. Area permissions grant or restrict access to create and manage area paths as well as create and modify work items defined under area paths.
Members of the Project Administrators group are automatically granted permissions to manage area paths for a project. Consider granting team administrators or team leads permissions to create, edit, or delete area nodes.
Note
Multiple teams may contribute to a project. When that's the case, you can set up teams that are associated with an area. Permissions for the team's work items are assigned by assigning permissions to the area. There are other team settings that configure the team's agile planning tools.
Permission (UI)
Namespace permission
Description
Can create area nodes. Users who have both this permission and the Edit this node permission can move or reorder any child area nodes. Consider adding this permission to any manually added users or groups that may need to delete, add, or rename area nodes.
Users who have both this permission and the Edit this node permission for another node can delete area nodes and reclassify existing work items from the deleted node. If the deleted node has child nodes, those nodes are also deleted.
Note
Consider adding this permission to any manually added users or groups that may need to delete, add, or rename area nodes.
Can set permissions for this node and rename area nodes.
Note
Consider adding this permission to any manually added users or groups that may need to delete, add, or rename area nodes.
Can edit work items in this area node.
Note
Consider adding this permission to any manually added users or groups that may need to edit work items under the area node.
Can modify test plan properties such as build and test settings.
Note
Consider adding this permission to any manually added users or groups that may need to manage test plans or test suites under this area node.
Can create and delete test suites, add, and remove test cases from test suites, change test configurations associated with test suites, and modify suite hierarchy (move a test suite).
Note
Consider adding this permission to any manually added users or groups that may need to manage test plans or test suites under this area node.
Can view the security settings for an area path node.
Can view, but not change, work items in this area node.
Note
If you set the View work items in this node to Deny, the user will not be able to see any work items in this area node. A Deny will override any implicit allow, even for users that are members of an administrative groups.
Iteration Path (object-level)
Iteration path permissions grant or restrict access to create and manage iteration paths, also referred to as sprints.
Manage the security of each iteration path from the web portal or using the TFSSecurity command-line tool.
Members of the Project Administrators group are automatically granted these permissions for each iteration defined for a project. Consider granting team administrators, scrum masters, or team leads permissions to create, edit, or delete iteration nodes.
Permission (UI)
Namespace permission
Description
Can create iteration nodes. Users who have both this permission and the Edit this node permission can move or reorder any child iteration nodes.
Note
Consider adding this permission to any manually added users or groups that might need to delete, add, or rename iteration nodes.
Users who have both this permission and the Edit this node permission for another node can delete iteration nodes and reclassify existing work items from the deleted node. If the deleted node has child nodes, those nodes are also deleted.
Note
Consider adding this permission to any manually added users or groups that might need to delete, add, or rename iteration nodes.
Can set permissions for this node and rename iteration nodes.
Note
Consider adding this permission to any manually added users or groups that might need to delete, add, or rename iteration nodes.
Can view the security settings for this node.
Note
Members of the Project Collection Valid Users, Project Valid Users, or any user or group that has View collection-level information or View project-level information can view permissions of any iteration node.
Work item query and query folder (object-level)
Manage query and query folder permissions through the web portal. Project Administrators are granted all of these permissions. Contributors are granted Read permissions only. Consider granting the Contribute permissions to users or groups that require the ability to create and share work item queries for the project.
Consider granting the Contribute permissions to users or groups that require the ability to create and share work item queries for the project. For more information, see Set permissions on queries.
Note
To create query charts you need Basic access.
Permission (UI)
Namespace permission
Description
Can view and modify the query folder or save queries within the folder.
Can delete a query or query folder and its contents.
Can manage the permissions for this query or query folder.
Can view and use the query or the queries in a folder, but can't modify the query or query folder contents.
Delivery Plans (object-level)
Manage plan permissions through the web portal. Manage permissions for each plan through its Security dialog. Project Administrators are granted all permissions to create, edit, and manage plans. Valid users are granted View (read-only) permissions.
Permission (UI)
Namespace permission
Description
Can delete the selected plan.
Can edit the configuration and settings defined for the selected plan.
Can manage the permissions for the selected plan.
Can view the lists of plans, open, and interact with a plan, but can't modify the plan configuration or settings.
Work item tags
You can manage tagging permissions using the TFSSecurity command-line tool. Contributors can add tags to work items and use them to quickly filter a backlog, board, or query results view.
Permission (UI)
Namespace permission
Description
Can create new tags and apply them to work items. Users without this permission can only select from the existing set of tags for the project.
Note
By default, Contributors are assigned the Create tag definition permission. Although the Create tag definition permission appears in the security settings at the project-level, tagging permissions are actually collection-level permissions that are scoped at the project level when they appear in the user interface. To scope tagging permissions to a single project when you're using a command-line tool, you must provide the GUID for the project as part of the command syntax. Otherwise, your change will apply to the entire collection. Keep this in mind when changing or setting these permissions.
Can remove a tag from the list of available tags for that project.
Note
This permission doesn't appear in the UI. It can only be set by using a command-line tool. There is also no UI to explicitly delete a tag. Instead, when a tag has not been in use for 3 days, the system automatically deletes it.
Can view a list of tags available for the work item within the project. Users without this permission will not have a list of available tags from which to choose in the work item form or in the query editor.
Note
This permission doesn't appear in the UI. It can only be set by using a command-line tool. The View project-level information implicitly allows users to view existing tags.
Can rename a tag by using the REST API.
Note
This permission doesn't appear in the UI. It can only be set by using a command-line tool.
Release (object-level)
Manage permissions for each release defined in the web portal. Project Administrators and Release Administrators are granted all release management permissions. These permissions work in a hierarchical model at the project level, for a specific release pipeline, or for a specific environment in a release pipeline. Within this hierarchy, permissions can be inherited from the parent or overridden.
Note
The project-level Release Administrator's group is created at the same time the first release pipeline is defined.
In addition, you can assign approvers to specific steps within a release pipeline to ensure that the applications being deployed meet quality standards.
The following permissions are defined in Release Management. The scope column explains whether the permission can be set at the project, release pipeline, or environment level.
Permission
Description
Scopes
Can change any of the other permissions listed here.
Project, Release pipeline, Environment
Can create new releases.
Project, Release pipeline
Can delete release pipeline(s).
Project, Release pipeline
Can delete environment(s) in release pipeline(s).
Project, Release pipeline, Environment
Can delete releases for a pipeline.
Project, Release pipeline
Can add and edit a release pipeline, including configuration variables, triggers, artifacts, and retention policy as well as configuration within an environment of the release pipeline. To make changes to a specific environment in a release pipeline, the user also needs Edit release environment permission.
Project, Release pipeline
Can edit environment(s) in release pipeline(s). To save the changes to the release pipeline, the user also needs Edit release pipeline permission. This permission also controls whether a user can edit the configuration inside the environment of a specific release instance. The user also needs Manage releases permission to save the modified release.
Project, Release pipeline, Environment
Can initiate a direct deployment of a release to an environment. This permission is only for direct deployments that are manually initiated by selecting the Deploy action in a release. If the condition on an environment is set to any type of automatic deployment, the system automatically initiates deployment without checking the permission of the user that created the release.
Project, Release pipeline, Environment
Can add or edit approvers for environment(s) in release pipeline(s). This permission also controls whether a user can edit the approvers inside the environment of a specific release instance.
Project, Release pipeline, Environment
Can edit a release configuration, such as stages, approvers, and variables. To edit the configuration of a specific environment in a release instance, the user also needs Edit release environment permission.
Project, Release pipeline
Can view release pipeline(s).
Project, Release pipeline
Can view releases belonging to release pipeline(s).
Project, Release pipeline
Default values for all of these permissions are set for team project collections and project groups. For example, Project Collection Administrators, Project Administrators, and Release Administrators are given all of the above permissions by default. Contributors are given all permissions except Administer release permissions. Readers, by default, are denied all permissions except View release pipeline and View releases.
Task group (Build and Release) permissions
Manage permissions for task groups from the Build and Release hub of the web portal. Project, Build, and Release Administrators are granted all permissions. Task group permissions follow a hierarchical model. Defaults for all the permissions can be set at the project level and can be overridden on an individual task group definition.
Use task groups to encapsulate a sequence of tasks already defined in a build or a release definition into a single reusable task. Define and manage task groups in the Task groups tab of the Build and Release hub.
| Permission | Description |
|---|---|
| Administer task group permissions | Can add and remove users or groups to task group security. |
| Delete task group | Can delete a task group. |
| Edit task group | Can create, modify, or delete a task group. |
Notifications or alerts
There are no UI permissions associated with managing email notifications or alerts. Instead, you can manage them using the TFSSecurity command-line tool.
- By default, members of the project level Contributors group can subscribe to alerts for themselves.
- Members of the Project Collection Administrators group, or users who have the Edit collection-level information can set alerts in that collection for others or for a team.
- Members of the Project Administrators group, or users who have the Edit project-level information can set alerts in that project for others or for a team.
You can manage alert permissions using TFSSecurity.
TFSSecurity Action
TFSSecurity Namespace
Description
Project Collection Administrators &
Project Collection Service Accounts
CREATE_SOAP_SUBSCRIPTION
EventSubscription
Can create a SOAP-based web service subscription.
✔️
GENERIC_READ
EventSubscription
Can view subscription events defined for a project.
✔️
GENERIC_WRITE
EventSubscription
Can create alerts for other users or for a team.
✔️
UNSUBSCRIBE
EventSubscription
Can unsubscribe from an event subscription.
✔️
Related articles
- Get started with permissions, access, and security groups
- Security and permission management tools
- Security namespace and permission reference for Azure DevOps
- Service accounts and dependencies
- Add users to an organization (Azure DevOps Services)
- Add users to a team or a project
- Add users to an administrator role
- Make a user a team administrator
- Troubleshoot permissions