Security groups, service accounts, and permissions in Azure DevOps

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

This article provides a comprehensive reference for each built-in user, group, and permission. It's a lot of information describing each built-in security user and group as well as each 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:


Note

The images you see from your web portal may differ from the images you see in this topic. 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 are generated by the system to support specific operations. These include those described in the following table. These user accounts are 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 should not 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 should not 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. This is a legacy user used for XAML builds. It is 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 is 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

Permissions can be granted directly to an individual, or to a group. Using groups makes things a lot simpler. The system provides several built-in groups for that purpose. These groups and the default permissions they're assigned are 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

All security groups are organization-level entities, even those groups that only have permissions to a specific project. From the web portal, visibility of some security groups may be limited based on user permissions. However, you can discover the names of all groups in an organization using the azure devops CLI tool or our REST APIs. To learn more, see Add and manage security groups.

Note

All security groups are collection-level entities, even those groups that only have permissions to a specific project. From the web portal, visibility of some security groups may be limited based on user permissions. However, you can discover the names of all groups in an organization using the azure devops CLI tool or our REST APIs. To learn more, see Add and manage security groups.

Note

All security groups are collection-level entities, even those groups that only have permissions to a specific project. From the web portal, visibility of some security groups may be limited based on user permissions. However, you can discover the names of all groups in an organization using the REST APIs. To learn more, 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 cannot remove or delete the built-in server-level groups.

Screenshot of Azure DevOps Security group dialog.

Screenshot of Azure DevOps Security group dialog, TFS-2018 version.

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

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.

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 on-premises installation directory. The command to do this is TFSSecurity /g+ "[TEAM FOUNDATION]\Team Foundation Service Accounts" n:domain\username /server:http(s)://tfsservername

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

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.

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.

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. The command to do this is 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 cannot 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 does not.

Screenshot of Project collection groups, new user interface.

Screenshot of Project collection groups, 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 have been installed. Also, 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 cannot modify the membership of this group.

Project-Scoped Users

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 that have been 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. Do not 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 restricted access when the organization-level preview feature, Limit user visibility and collaboration to specific projects is enabled. To learn more, see Manage your organization, Limit user visibility for projects and more.

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

Note

To enable the preview page for the Project Permissions Settings Page, see Enable preview features.

Project-level groups and permissions, Azure DevOps current.

Project-level groups and permissions, TFS-2018 and earlier 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 those 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.

Project Administrators

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 an iteration path, or customize work item tracking. Members of the Project Administrators group are granted 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 cannot 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.

TeamName

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. To learn more, 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 as well as role-based permissions—and by default assigns them to one or more built-in groups. You can manage most permissions through the web portal. Additional permissions can be managed using one or more security management tools by specifying a namespace permission.

The system manages permissions at different levels—server, collection, project, object as well as role-based permissions—and by default assigns them to one or more built-in groups. You manage most permissions through the web portal. Additional permissions can be managed using one or more security management tools by 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

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

Screenshot of Server-level permissions.

Permission (UI)
Namespace permission

Description


Administer warehouse
Warehouse, Administer

This permission is 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.

Additional permissions may be required to fully process or rebuild the data warehouse and Analysis cube.

Create project collection
CollectionManagement, CreateCollection

Can create and administer collections.

Delete project collection
CollectionManagement, DeleteCollection

Can delete a collection from the deployment.

Note

Deleting a collection won't delete the collection database from SQL Server.

Edit instance-level information
Server, GenericWrite

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.

Make requests on behalf of others
Server, Impersonate

Can perform operations on behalf of other users or services. Only assign to service accounts.

Trigger events
Server, TriggerEvent

Can trigger server-level alert events. Only assign to service accounts and members of the Azure DevOps or Team Foundation Administrators group.

Use full Web Access features

Can use all on-premises Web portal features. This permission has been 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.

View instance-level information
Server, GenericRead

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

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

Screenshot of Organization-level permissions and groups, Azure DevOps Services.

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

Alter trace settings
Collection, DIAGNOSTIC_TRACE

Can change the trace settings for gathering more detailed diagnostic information about Azure DevOps Web services.

Create new projects
(formerly Create new team projects)
Collection, CREATE_PROJECTS

Can add a project to an organization or project collection. Additional permissions may be required depending on your on-premises deployment.

Delete team project
Project, DELETE

Can delete a project. 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.

Edit instance-level information
Collection, GENERIC_WRITE

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, Extensions, and Azure Active Directory 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.

View instance-level information
Collection, GENERIC_READ

Can view organization-level permissions for a user or group.

Service Account

Make requests on behalf of others
Server, Impersonate

Can perform operations on behalf of other users or services. Assign this permission only to service accounts.

Trigger events
Collection, TRIGGER_EVENT Server, TRIGGER_EVENT

Can trigger project alert events within the collection. Assign only to service accounts.

View system synchronization information Collection, SYNCHRONIZE_READ

Can call the synchronization application programming interfaces. Assign only to service accounts.

Boards

Administer process permissions
Process, AdministerProcessPermissions

Can modify permissions for customizing work tracking by creating and customizing inherited processes.

Create process
Process, Create

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.

Delete field from organization
Collection, DELETE_FIELD

Delete process
Process, Delete

Can delete an inherited process used to customize work tracking and Azure Boards.

Edit process
Process, Edit

Repos

Applies only to Team Foundation version control (TFVC)

Administer shelved changes
VersionControlPrivileges, AdminWorkspaces

Administer workspaces
Workspaces, Administer

Create a workspace
VersionControlPrivileges, CreateWorkspace

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

Administer build resource permissions
BuildAdministration, AdministerBuildResourcePermissions

Can modify permissions for build resources at the organization or project collection-level. This includes:

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.

Manage build resources
BuildAdministration, ManageBuildResources

Can manage build computers, build agents, and build controllers.

Manage pipeline policies
BuildAdministration, ManagePipelinePolicies

Can manage pipeline settings set through Organization settings, Pipelines, Settings.

Use build resources
BuildAdministration, UseBuildResources

Can reserve and allocate build agents. Assign only to service accounts for build services.

View build resources
BuildAdministration, ViewBuildResources

Can view, but not use, build controllers and build agents that are configured for an organization or project collection.

Test Plans

Manage test controllers
Collection, MANAGE_TEST_CONTROLLERS

Can register and de-register test controllers.

Auditing

Delete audit streams
AuditLog, Delete_Streams

Can delete an audit stream. Audit streams are in preview. For details, see Create audit streaming.

Manage audit streams
AuditLog, Manage_Streams

Can add an audit stream. Audit streams are in preview. For details, see Create audit streaming.

View audit log
AuditLog, Read

Can view and export audit logs. Audit logs are in preview. For details, see Access, export, and filter audit logs.

Policies

Manage enterprise policies
Collection, MANAGE_ENTERPRISE_POLICIES

Can enable and disable application connection policies as described in Change application connection policies.

Collection-level permissions

You 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

Screenshot of Collection level permissions, on-premises, Inherited process model.

Screenshot of Collection level permissions, on-premises, On-premises XML process model.

Collection level permissions and groups

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


Administer build resource permissions
BuildAdministration, AdministerBuildResourcePermissions

Can modify permissions for build pipelines at the project collection-level. This includes the following artifacts:

Administer process permissions
Process, AdministerProcessPermissions

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:

Administer shelved changes
VersionControlPrivileges, AdminWorkspaces

Can delete shelvesets created by other users. Applies when TFVC is used as the source control.

Administer workspaces
Workspaces, Administer

Can create and delete workspaces for other users. Applies when TFVC is used as the source control.

Alter trace settings
Collection, DIAGNOSTIC_TRACE

Can change the trace settings for gathering more detailed diagnostic information about Azure DevOps Web services.

Create a workspace
VersionControlPrivileges, CreateWorkspace

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.

Create new projects
(formerly Create new team projects)
Collection, CREATE_PROJECTS

Can add projects to a project collection. Additional permissions may be required depending on your on-premises deployment.

Create process
Process, Create

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.

Delete field from organization
(formerly Delete field from account)
Collection, DELETE_FIELD

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.

Delete team project
Project, DELETE

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.

Edit process
Process, Edit

Can edit a custom inherited process. Requires the collection to be configured to support the Inherited process model.

Make requests on behalf of others
Server, Impersonate

Can perform operations on behalf of other users or services. Assign this permission only to on-premises service accounts.

Manage build resources
BuildAdministration, ManageBuildResources

Can manage build computers, build agents, and build controllers.

Manage enterprise policies
Collection, MANAGE_ENTERPRISE_POLICIES

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.

Manage process template
Collection, MANAGE_TEMPLATE

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.

Manage test controllers
Collection, MANAGE_TEST_CONTROLLERS

Can register and de-register test controllers.

Trigger events
Collection, TRIGGER_EVENT Server, TRIGGER_EVENT

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.

Use build resources
BuildAdministration, UseBuildResources

Can reserve and allocate build agents. Assign only to service accounts for build services.

View build resources
BuildAdministration, ViewBuildResources

Can view, but not use, build controllers and build agents that are configured for an organization or project collection.

View instance-level information
or View collection-level information
Collection, GENERIC_READ

Can view collection-level permissions for a user or group.

View system synchronization information
Collection, SYNCHRONIZE_READ

Can call the synchronization application programming interfaces. Assign only to service accounts.

Project-level permissions

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

Screenshot of Project-level permissions dialog, Azure DevOps Services preview page.

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

Delete team project
Project, DELETE

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 may be able to delete the project for which they have permission. To ensure that a user isn't able to delete a project, make sure you set the Delete team project at the project-level to Deny as well.

Edit project-level information
Project, MANAGE_PROPERTIES

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.


Manage project properties
Project, MANAGE_SYSTEM_PROPERTIES

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.

Rename project
Project, RENAME

Suppress notifications for work item updates
Project, SUPPRESS_NOTIFICATIONS

Users with this permission can update work items without generating notifications. This 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 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.

Update project visibility
Project, UPDATE_VISIBILITY

Can change the project visibility from private to public or public to private. Applies to Azure DevOps Services only.

View project-level information
Project, GENERIC_READ

Can view project-level information, including security information group membership and permissions. If you set this permission to Deny for a user, they aren't able to view the project or sign into the project.

Boards

Bypass rules on work item updates
Project, BYPASS_RULES

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. Scenarios where this is useful 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 bypassrules mode (initialize WorkItemStore with WorkItemStoreFlags.BypassRules).

Change process of project
Project, CHANGE_PROCESS

When combined with the 'Edit project-level information' permission, allows users to change the Inheritance process for a project. To learn more, see Create and manage inherited processes.

Create tag definition
Tagging, Create

Can add tags to a work item. By default, all members of the Contributors group have this permission. Also, you can set additional tagging permissions through security management tools. 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. To learn more, 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.

Delete and restore work items

or Delete work items in this project
Project, WORK_ITEM_DELETE

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.

Move work items out of this project
Project, WORK_ITEM_MOVE

Permanently delete work items in this project
Project, WORK_ITEM_PERMANENTLY_DELETE

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.

Delete shared Analytics view
AnalyticsViews, Delete

Can delete Analytics views that have been saved under the Shared area.

Edit shared Analytics view
AnalyticsViews, Edit

Can create and modify shared Analytics views.

View analytics
AnalyticsViews, Read

Can access data available from the Analytics service. For details, see Permissions required to access the Analytics service.

Test Plans

Create test runs
Project, PUBLISH_TEST_RESULTS

Can add and remove test results and add or modify test runs. To learn more, see Control how long to keep test results and Run manual tests.

Delete test runs
Project, DELETE_TEST_RESULTS

Manage test configurations
Project, MANAGE_TEST_CONFIGURATIONS

Can create and delete test configurations.

Manage test environments
Project, MANAGE_TEST_ENVIRONMENTS

Can create and delete test environments.

View test runs
Project, VIEW_TEST_RESULTS

Can view test plans under the project area path.

You 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 are granted to members of the Project Administrators group and aren't surfaced within the user interface.

Project-level permissions, on-premises, Inherited process model

Screenshot of Project-level permissions dialog, TFS-2018.

Permission (UI)

Namespace permission

Description


Bypass rules on work item updates
Project, BYPASS_RULES

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. Scenarios where this is useful are 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).


Change process of project
Project, CHANGE_PROCESS

When combined with the 'Edit project-level information' permission, allows users to change the Inheritance process for a project. To learn more, see Create and manage inherited processes.


Create tag definition
Tagging, Create

Can add tags to a work item. By default, all members of the Contributors group have this permission. Also, you can set additional 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. To learn more, 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.


Create test runs
Project, PUBLISH_TEST_RESULTS

Can add and remove test results and add or modify test runs. To learn more, see Control how long to keep test results and Run manual tests.

Delete and restore work items

or Delete work items in this project
Project, WORK_ITEM_DELETE

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.


Delete shared Analytics view
AnalyticsViews, Delete

Can delete Analytics views that have been saved under the Shared area.


Delete project
Project, DELETE

Can delete a project from an organization or project collection.


Delete test runs
Project, DELETE_TEST_RESULTS

Can delete a test run.


Edit project-level information Project, MANAGE_PROPERTIES

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.


Edit shared Analytics view
AnalyticsViews, Edit

Can create and modify shared Analytics views.


Manage project properties
Project, MANAGE_SYSTEM_PROPERTIES

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.


Manage test configurations
Project, MANAGE_TEST_CONFIGURATIONS

Can create and delete test configurations.


Manage test environments
Project, MANAGE_TEST_ENVIRONMENTS

Can create and delete test environments.


Move work items out of this project
Project, WORK_ITEM_MOVE


Permanently delete work items in this project Project, WORK_ITEM_PERMANENTLY_DELETE

Can permanently delete work items from this project.

Rename project `Project, RENAME`


Suppress notifications for work item updates Project, SUPPRESS_NOTIFICATIONS

Users with this permission can update work items without generating notifications. This 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 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.

Update project visibility `Project, UPDATE_VISIBILITY`

Can change the project visibility from private to public or public to private. Applies to Azure DevOps Services only.

View analytics `AnalyticsViews, Read`

Can access data available from the Analytics service. For details, see Permissions required to access the Analytics service.


View project-level information
Project, GENERIC_READ

Can view project level group membership and permissions.


View test runs
Project, VIEW_TEST_RESULTS

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. You manage the security of Analytics views from the web portal.

Shared Analytics view security dialog, change permissions for a user.

Manage Shared Analytics view security dialog, change permissions for a user, Azure DevOps Server.

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. See also, What are Analytics views? Additional namespace permissions are supported as defined in Security namespace and permission reference.

Permission (UI)

Namespace permission

Description

Delete shared Analytics views
AnalyticsViews, Delete

Can delete the shared Analytics view.

Edit shared Analytics views AnalyticsViews, Edit

Can change the parameters of the shared Analytics view.

View shared Analytics views AnalyticsViews, Read

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. You manage the security of dashboards from the web portal. Additional namespace permissions are supported as defined in Security namespace and permission reference.

Project dashboard permissions

Screenshot of Project dashboard permissions dialog

By default, the creator of the project dashboard is the dashboard owner and granted all permissions for that dashboard.

Permission
Namespace permission
Description
Delete dashboard
DashboardsPrivileges, Delete
Can delete the project dashboard.
Edit dashboard
DashboardsPrivileges, Edit
Can add widgets to and change the layout of the project dashboard.
Manage Permissions
DashboardsPrivileges, 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. You manage the security of dashboards from the web portal.

Team dashboard default permissions

Screenshot of Team dashboard permissions dialog.

By default, team administrators are granted all permissions for their team dashboards, including managing default and individual dashboard permissions.

Permission
Namespace permission
Description
Create dashboards
DashboardsPrivileges, MaterializeDashboards
Can create a team dashboard.
Delete dashboards
DashboardsPrivileges, Delete
Can delete a team dashboard.
Edit dashboards
DashboardsPrivileges, Edit
Can add widgets to and change the layout of a team dashboard.

Individual team dashboard permissions

Screenshot of individual team dashboard permissions dialog.

Team administrators can change the permissions for individual team dashboards by changing the following two permissions.

Permission
Namespace permission
Description
Delete dashboard
DashboardsPrivileges, Delete
Can delete the specific team dashboard.
Edit dashboard
DashboardsPrivileges, Edit
Can add widgets to and change the layout of the specific team dashboard.

Pipeline or Build (object-level)

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

Screenshot of pipeline object-level security dialog, cloud.

Screenshot of Pipeline object-level permissions dialog.

Screenshot of Build object-level permissions dialog, Azure DevOps Server 2019 and earlier on-premises versions.

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.

The following permissions are defined in Build. All of these can be set at both the levels.

Permission (UI)

Namespace permission

Description

Administer build permissions
Build, AdministerBuildPermissions

Can administer the build permissions for other users.

Delete build definition
Build, DeleteBuildDefinition

Can delete build definitions for this project.

Delete builds
Build, DeleteBuilds

Can delete a completed build. Builds that are deleted are retained in the Deleted tab for a period of time before they are destroyed.

Destroy builds
Build, DestroyBuilds

Can permanently delete a completed build.

Edit build pipeline
Edit build definition
Build, EditBuildDefinition

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.

Edit build quality
Build, EditBuildQuality

Can add information about the quality of the build through Team Explorer or the web portal.

Manage build qualities
Build, ManageBuildQualities

Can add or remove build qualities. Only applies to XAML builds.

Manage build queue
Build, ManageBuildQueue

Can cancel, re-prioritize, or postpone queued builds. Only applies to XAML builds.

Override check-in validation by build
Build, OverrideBuildCheckInValidation

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.

Queue builds
Build, QueueBuilds

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.

Retain indefinitely
Build, RetainIndefinitely

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.

Stop builds
Build, StopBuilds

Can stop any build that is in progress, including builds queued and started by another user.

Update build information
Build, UpdateBuildInformation

Can add build information nodes to the system, and can also add information about the quality of a build. Assign only to service accounts.

View build definition
Build, ViewBuildDefinition

Can view the build definitions that have been created for the project.

View builds
Build, ViewBuilds

Can view the queued and completed builds for this project.

Git repository (object-level)

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

Git repository permissions dialog

Git repository permissions dialog, TFS

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

Bypass policies when completing pull requests
GitRepositories, PullRequestBypassPolicy

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.

Bypass policies when pushing

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.

Contribute
GitRepositories, GenericContribute

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. Does not 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 being added to the branch by others and prevents other users from changing the existing commit history.

Contribute to pull requests
GitRepositories, PullRequestContribute

Can create, comment on, and vote on pull requests.

Create branch
GitRepositories, CreateBranch

Can create and publish branches in the repository. Lack of this permission does not 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.

Create repository
GitRepositories, CreateRepository

Can create new repositories. This permission is only available from the Security dialog for the top-level Git repositories object.

Create tag
GitRepositories, CreateTag

Can push tags to the repository.

Delete repository GitRepositories, DeleteRepository

Can delete the repository. At the top-level Git repositories level, can delete any repository.

Edit policies
GitRepositories, EditPolicies

Can edit policies for the repository and its branches.

Exempt From policy enforcement
GitRepositories, PolicyExempt

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.

Force push (rewrite history, delete branches and tags)
GitRepositories, ForcePush

Can force an update to a branch, delete a branch, and modify the commit history of a branch. Can delete tags and notes.

Manage notes
GitRepositories, ManageNote

Can push and edit Git notes.

Manage permissions
GitRepositories, ManagePermissions

Can set permissions for the repository.

Read GitRepositories, GenericRead

Can clone, fetch, pull, and explore the contents of the repository.

Remove others' locks
GitRepositories, RemoveOthersLocks

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.

Rename repository
GitRepositories, RenameRepository

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)

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

TFVC permissions dialog

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

Lock
VersionControlItems, Lock

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

Merge
VersionControlItems, AdminProjectRights

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

Area path permissions dialog

Permission (UI)

Namespace permission

Description

Create child nodes
CSS, CREATE_CHILDREN

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.

Delete this node
CSS, CREATE_CHILDREN

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.

Edit this node
CSS, CREATE_CHILDREN

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.

Edit work items in this node
CSS, WORK_ITEM_WRITE

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.

Manage test plans
CSS, MANAGE_TEST_PLANS

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.

Manage test suites
CSS, MANAGE_TEST_SUITES

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.

View permissions for this node

Can view the security settings for an area path node.

View work items in this node CSS, GENERIC_READ

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.

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

Iteration Path permissions dialog

Permission (UI)

Namespace permission

Description

Create child nodes
Iteration, CREATE_CHILDREN

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.

Delete this node
Iteration, DELETE

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.

Edit this node
Iteration, GENERIC_WRITE

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.

View permissions for this node
Iteration, GENERIC_READ

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)

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

Query folder permissions dialog

Consider granting the Contribute permissions to users or groups that require the ability to create and share work item queries for the project. To learn more, see Set permissions on queries.

Note

To create query charts you need Basic access.

Permission (UI)

Namespace permission

Description

Contribute
WorkItemQueryFolders, Contribute

Can view and modify the query folder or save queries within the folder.

Delete
WorkItemQueryFolders, Delete

Can delete a query or query folder and its contents.

Manage permissions
WorkItemQueryFolders, ManagePermissions

Can manage the permissions for this query or query folder.

Read
WorkItemQueryFolders, Read

Can view and use the query or the queries in a folder, but cannot modify the query or query folder contents.

Delivery Plans (object-level)

You manage plan permissions through the web portal. You 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

Delete
Plan, Delete

Can delete the selected plan.

Edit
Plan, Edit

Can edit the configuration and settings defined for the selected plan.

Manage
Plan, Manage

Can manage the permissions for the selected plan.

View
Plan, View

Can view the lists of plans, open, and interact with a plan, but cannot 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. You 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

Administer process permissions
Process, AdministerProcessPermissions

Can set or change the permissions for an inherited process.

Delete process
Process, Delete

Can delete the inherited process.

Edit process
Process, Edit

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


Create tag definition
Tagging, Create

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

Delete tag definition
Tagging, Delete

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.

Enumerate tag definition
Tagging, Enumerate

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.

Update tag definition
Tagging, Update

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)

You manage permissions for each release defined in the web portal. Project Administrators and Release Administrators are granted all release management permissions. These permissions can be granted or denied 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.

Releases object-level permissions.

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

Administer release permissions

Can change any of the other permissions listed here.

Project, Release pipeline, Environment

Create releases

Can create new releases.

Project, Release pipeline

Delete release pipeline

Can delete release pipeline(s).

Project, Release pipeline

Delete release environment

Can delete environment(s) in release pipeline(s).

Project, Release pipeline, Environment

Delete releases

Can delete releases for a pipeline.

Project, Release pipeline

Edit 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

Edit release environment

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

Manage deployments

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

Manage release approvers

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

Manage releases

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

View release pipeline

Can view release pipeline(s).

Project, Release pipeline

View releases

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

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

You use task groups to encapsulate a sequence of tasks already defined in a build or a release definition into a single reusable task. You 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 az devops security permission or TFSSecurity command-line tools.

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.

✔️