Security groups, service accounts, and permissions reference
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
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 About permissions, access, and security groups, About security roles, and About access levels.
For more information about adding users to a group or setting a specific permission that you can manage through the web portal, see the following resources:
Users and groups
Wiki
DevOps
Note
The images shown in your web portal might differ from the images in this article due to system updates, but the basic functionality remains the same unless explicitly mentioned.
Service accounts
The system generates a few service accounts 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 don't need to manage group members directly - the agent registration process handles it for you. When you register the agent, the service account you specify (typically Network Service) automatically gets added. Responsible for performing Azure Boards read/write operations and updating work items when GitHub objects change. |
| 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 automatically a member of the Security Service Group, which is used to store users who are granted permissions, but no other security group. |
| Project Collection Build Service | Has permissions to run build services for the collection. It's automatically a member of the Security Service Group, which is used to store users who are granted permissions, but no 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.
Note
Security groups are managed at the organization level, even if they are used for specific projects. Depending on user permissions, some groups might be hidden in the web portal. To view all group names within an organization, you can use the Azure DevOps CLI tool or our REST APIs. For more information, see Add and manage security groups.
Note
Security groups are managed at the collection level, even if they are used for specific projects. Depending on user permissions, some groups might be hidden in the web portal. To view all group names within a collection, you can use the Azure DevOps CLI tool or our REST APIs. For more information, see Add and manage security groups.
Note
Security groups are managed at the collection level, even if they are used for specific projects. Depending on user permissions, some groups might be hidden in the web portal. To view all group names in a collection, you can use the REST APIs. For more information, see Add and manage security groups.
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.
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
Azure DevOps 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.
To add an account to this group after you install Azure DevOps Server, use the TFSSecurity.exe utility in the Tools subfolder of your on-premises installation directory. Use the following command: TFSSecurity /g+ "[TEAM FOUNDATION]\Team Foundation Service Accounts" n:domain\username /server:http(s)://azuredevopsservername.
Azure DevOps Proxy Service Accounts
Has service level permissions for Azure DevOps Server Proxy, and some service-level permissions.
Note
This account gets created when you install the Azure DevOps proxy service.
This group should contain only service accounts and not user accounts or groups that contain user accounts.
Azure DevOps Valid Users
Has permission to view server instance-level information.
Contains all users known to exist in the server instance. You can't modify the membership of this group.
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.
Limit this group to the fewest users who require full 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.
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.
Note
To enable the Organizations Permissions Settings Page v2 preview page,see Enable preview features. The preview page provides a group settings page that the current page doesn't.
Preview page is not available for on-premises versions.
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 are installed. Contains the members of the CollectionName/Service Accounts group. Limit this group to the fewest users who require full 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 fewest users who require full 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 added anywhere within the collection. You can't modify the membership of this group.
Has limited access to view organization settings and projects other than those projects they are specifically added to. Also, people picker options are limited to those users and groups explicitly added to the project the user is connected to.
Add users to this group when you want to limit their visibility and access to those projects that you explicitly add them to. don't add users to this group if they are also added to the Project Collection Administrators group.
Note
The Project-Scoped Users group becomes available with limited access when the organization-level preview feature, Limit user visibility and collaboration to specific projects is enabled. For more information including important security-related call-outs, see Manage your organization, Limit user visibility for projects and more.
Security Service Group
Used to store users with 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 whether 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.
Note
To enable the preview page for the Project Permissions Settings Page, see Enable preview features.
Preview page is not available for on-premises versions.
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 require the following functions: 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 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 gets 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 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—organization, 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. Manage more permissions with the command line tool (CLI).
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. Manage more permissions with the command line tool (CLI).
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 the settings for the data warehouse or SQL Server Analysis cube by using the Warehouse Control Web Service.
More permissions might 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 doesn'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 only sees those features permitted for the Stakeholder group (see Change access levels). A Deny overrides 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.
Organization-level permissions
Manage organization-level permissions through the web portal admin context or with the az devops security group commands. Project Collection Administrators are granted all organization-level permissions. Other organization-level groups have select permission assignments.
Note
To enable the preview page for the Project Permissions Settings Page, see Enable preview features.
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
General
Can change the trace settings for gathering more detailed diagnostic information about Azure DevOps Web services.
Can add a project to an organization or project collection. More permissions may be required depending on your on-premises deployment.
Can delete a project. Deleting a project deletes all data that is associated with the project. You can't 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 instance-level information includes the ability to perform these tasks for all projects defined in an organization or collection:
- Modify organization Overview settings and Extensions
- 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 view organization-level permissions for a user or group.
Service Account
Can perform operations on behalf of other users or services. Assign this permission only to service accounts.
Can trigger project alert events within the collection. Assign only to service accounts.
Can call the synchronization application programming interfaces. Assign only to service accounts.
Boards
Can modify permissions for customizing work tracking by creating and customizing inherited processes.
Can create an inherited process used to customize work tracking and Azure Boards. Users granted Basic and Stakeholder access are granted this permission by default.
Can delete an inherited process used to customize work tracking and Azure Boards.
Can edit a custom inherited process.
Repos
Applies only to Team Foundation version control (TFVC)
Can delete shelvesets created by other users.
Can create a version control workspace. The Create a workspace permission is granted to all users as part of their membership within the Project Collection Valid Users group.
Pipelines
Can modify permissions for build resources at the organization or project collection-level, which includes:
- Set retention policies
- Set resource limits for pipelines
- Add and manage agent pools
- Add and manage deployment pools
Note
In addition to this permission, Azure DevOps provides role-based permissions governing the security of agent pools. Other, object-level settings will override those set at the organization or project-level.
Can manage build computers, build agents, and build controllers.
Can manage pipeline settings set through Organization settings, Pipelines, Settings.
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.
Test Plans
Can register and deregister test controllers.
Can delete an audit stream. Audit streams are in preview. For more information, see Create audit streaming.
Can add an audit stream. Audit streams are in preview. For more information, see Create audit streaming.
Can view and export audit logs. Audit logs are in preview. For more information, see Access, export, and filter audit logs.
Policies
Can enable and disable application connection policies as described in Change application connection policies.
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.
The permissions available for Azure DevOps Server 2019 and later versions vary depending on the process model configured for the collection. For an overview of process models, see Customize work tracking.
Inherited process model
On-premises XML process model
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 modify permissions for customizing work tracking by creating and customizing inherited processes. Requires the collection to be configured to support the Inherited process model. See also:
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 create an inherited process used to customize work tracking and Azure Boards. Requires the collection to be configured to support the Inherited process model.
Can delete a custom field that was added to a process. For on-premises deployments, requires the collection to be configured to support Inherited process model.
Can delete an inherited process used to customize work tracking and Azure Boards. Requires the collection to be configured to support Inherited process model.
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 edit a custom inherited process. Requires the collection to be configured to support the Inherited process model.
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 enable and disable application connection policies as described in Change application connection policies.
Note
This permission is only valid for Azure DevOps Services. While it may appear for Azure DevOps Server on-premises, it doesn't apply to on-premises servers.
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
Important
To access project-level resources, the View project-level information permission must be set to Allow. This permission gates all other project-level permissions.
Manage project-level permissions through the web portal admin context or with the az devops security group commands. Project Administrators are granted all project-level permissions. Other project-level groups have select permission assignments.
Note
To enable the Project Permissions Settings Page preview page, see Enable preview features.
Manage project-level permissions through the web portal admin context. Project Administrators are granted all project-level permissions. Other project-level groups have select permission assignments.
Preview page is not available for on-premises versions.
Important
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.
You can't change the permissions for the Project 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
General
Can delete a project from an organization or project collection.
Note
Even if you set this permission to Deny, users granted permission at the project level can likely delete the project for which they have permission. To ensure that a user can't delete a project, make sure you set the Delete team project at the project-level to Deny as well.
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.
Users with this permission can update work items without generating notifications. This feature is useful when performing migrations of bulk updates by tools and want to skip generating notifications.
Consider granting this permission to service accounts or users with 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 view project-level information, including security information group membership and permissions. If you set this permission to Deny for a user, they can't view the project or sign in to the project.
Boards
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 scenarios are migrations where you don't want to update the by/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).
When combined with the 'Edit project-level information' permission, allows users to change the Inheritance process for a project. For more information, see Create and manage inherited processes.
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. For more information, see Security namespace and permission reference, Tagging.
Note
All users granted Stakeholder access for a private project 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. Azure DevOps Services users granted Stakeholder access for a public project are granted this permission by default. 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 applies to the entire collection.
Keep this in mind when changing or setting these permissions.
Can mark work items in the project as deleted. Azure DevOps Services users granted Stakeholder access for a public project are granted this permission by default.
Can move a work item from one project to another project within the collection.
Can permanently delete work items from this project.
Analytics
In addition to the AnalyticsView namespace permissions listed in this section, you can set object-level permissions on each view.
Can delete Analytics views under the Shared area.
Can create and modify shared Analytics views.
Can access data available from the Analytics service. For more information, see Permissions required to access the Analytics service.
Test Plans
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 delete a test run.
Can create and delete test configurations.
Can create and delete test environments.
Can view test plans under the project area path.
Analytics views (object-level)
With shared Analytics views, you can grant specific permissions to view, edit, or delete a view that you create. Manage the security of Analytics views from the web portal.
The following permissions are defined for each shared Analytics view. All valid users are automatically granted all permissions to manage Analytics views. Consider granting select permissions to specific shared views to other team members or security group that you create. For more information, see What are Analytics views? and Security namespace and permission reference.
Permission (UI)
Namespace permission
Description
Can delete the shared Analytics view.
Can change the parameters of the shared Analytics view.
Can view and use the shared Analytics view from Power BI desktop.
Dashboards (object-level)
Permissions for team and project 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. More namespace permissions are supported as defined in Security namespace and permission reference.
Project dashboard permissions
By default, the creator of the project dashboard is the dashboard owner and granted all permissions for that dashboard.
PermissionNamespace permission |
Description |
|---|---|
Delete dashboardDashboardsPrivileges, Delete |
Can delete the project dashboard. |
Edit dashboardDashboardsPrivileges, Edit |
Can add widgets to and change the layout of the project dashboard. |
Manage PermissionsDashboardsPrivileges, ManagePermissions |
Can manage permissions for the project dashboard. |
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 create pipeline lines and edit those pipelines.
Can create pipelines.
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. Cannot create new pipelines. Edit build definition: Can create and modify build definitions for this project.
Note
To control permissions for specific build definitions, turn off inheritance.
When inheritance is turned 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 for project Fabrikam allows a member of the Build Managers group to manually queue a build.
When inheritance is turned off, you can set permissions so only Project Administrators can manually queue a build for a specific build definition.
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 changeset that affects a gated build definition without triggering the system to shelve and build their changes first.
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 specify values for free-text parameters (e.g., of type object or array) and pipeline variables when queueing new builds.
Can toggle the retain flag on a build to indefinitely. This feature marks a build so that the system doesn'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 created for the project.
Can view the queued and completed builds for this project.
Note
- 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.
- 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 doesn't apply to PR builds. For more information, see Check in to a folder that is controlled by a gated check-in build process.
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 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.
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.
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 might 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 you create a new branch on the server, you have Contribute, Edit Policies, Force Push, Manage Permissions, and Remove Others' Locks permissions for that branch by default. This means that you can add new commits to the repo via your 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 was 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 changeset comments. Pending changes are committed at check-in.*
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 must have the Check-in permission to share their changes with the team.*
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 don't have the Manage Branch permission.
Manage permissions
VersionControlItems, AdminProjectRights
Can manage other users' permissions for folders and files in version control.*
Can merge changes into this path.*
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 doesn't 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.*
Undo other users' changes
VersionControlItems, UndoOther
Can undo a pending change made by another user.*
Unlock other users' changes
VersionControlItems, UnlockOther
Can unlock files locked by other users.*
* 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 manage 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 manage 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 can 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 might 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.
Consider adding this permission to any manually added users or groups that might need to delete, add, or rename area nodes.
Can set permissions for this node and rename area nodes.
Consider adding this permission to any manually added users or groups that might need to delete, add, or rename area nodes.
Can edit work items in this area node.
Consider adding this permission to any manually added users or groups that might need to edit work items under the area node.
Can modify test plan properties such as build and test settings.
Consider adding this permission to any manually added users or groups that might 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).
Consider adding this permission to any manually added users or groups that might 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 can't see any work items in this area node. A Deny overrides any implicit allow, even for users that are members of an administrative groups.
Iteration path (object-level)
Iteration path permissions manage 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.
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.
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.
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. 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.
Process (object-level)
You can manage the permissions for each inherited process that you create through the web portal. Manage permissions for each process through its Security dialog. Project Collection Administrators are granted all permissions to create, edit, and manage processes. Valid users are granted View (read-only) permissions.
Permission (UI)
Namespace permission
Description
Can set or change the permissions for an inherited process.
Can delete the inherited process.
Can create an inherited process from a system process, or copy or modify an inherited process.
Work item tags
You can manage tagging permissions using az devops security permission or the TFSSecurity command-line tools. Contributors can add tags to work items and use them to quickly filter a backlog, board, or query results view.
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.
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 applies 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.
This permission doesn't appear in the UI. You can only set it by using a command-line tool. There's also no UI to explicitly delete a tag. Instead, when a tag has not been in use for three days, the system automatically deletes it.
Can view a list of tags available for the work item within the project. Users without this permission don't have a list of available tags from which to choose in the work item form or in the query editor.
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.
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 gets created when you define your first release pipeline.
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 pipelines.
Project, Release pipeline
Can delete environments in release pipelines.
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 environments in release pipelines. 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 environments in release pipelines. 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 pipelines.
Project, Release pipeline
Can view releases belonging to release pipelines.
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.
✔️