Jaa


Security groups, service accounts, and permissions in Azure DevOps

TFS 2018

This article provides a comprehensive reference for each built-in user, group, and permission.

For a quick reference to default assignments, see Default permissions and access. For an overview of how permissions and security are managed, see Get started with permissions, access, and security groups. In addition to security groups, there are also security roles, which provide permissions for select areas.

To learn how to add users to a group or set a specific permission that you can manage through the web portal, see the following resources:


Note

The images shown in your web portal may differ from the images in this article. These differences result from updates made to Azure DevOps. However, the basic functionality available to you remains the same unless explicitly mentioned.

Service accounts

There are a few service accounts that the system generates to support specific operations. The following table describes these user accounts, which get added at the organization or collection level.

User name Description
Agent Pool Service Has permission to listen to the message queue for the specific pool to receive work. In most cases, you shouldn't have to manage members of this group. The agent registration process takes care of it for you. The service account you specify for the agent (commonly Network Service) is automatically added when you register the agent. Responsible for performing Azure Boards read/write operations and updating work items when GitHub objects are updated.
Azure Boards Added when Azure Boards is connected to GitHub. You shouldn't have to manage members of this group. Responsible for managing the link creation between GitHub and Azure Boards.
PipelinesSDK Added as needed to support the Pipelines policy service scope tokens. This user account is similar to the build service identities but supports locking down permissions separately. In practice, the tokens that involve this identity are granted read-only permissions to pipeline resources and the one-time ability to approve policy requests. This account should be treated in the same way that the build service identities are treated.
ProjectName Build Service Has permissions to run build services for the project and is a legacy user used for XAML builds. It's added to the Security Service Group, which is used to store users who have been granted permissions, but not added to any other security group.
Project Collection Build Service Has permissions to run build services for the collection. It's added to the Security Service Group, which is used to store users who have been granted permissions, but not added to any other security group.

Groups

You can grant permissions directly to an individual, or to a group. Using groups makes things simpler and the system provides several built-in groups for that purpose. These groups and the default permissions they're assigned get defined at different levels: server (on-premises deployment only), project collection, project, and specific objects. You can also create your own groups and grant them the specific set of permissions that are appropriate for certain roles in your organization.

Server-level groups

When you install Azure DevOps Server, the system creates default groups that have deployment-wide, server-level permissions. You can't remove or delete the built-in server-level groups.

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

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. Use the following command: TFSSecurity /g+ "[TEAM FOUNDATION]\Team Foundation Service Accounts" n:domain\username /server:http(s)://tfsservername.

Team Foundation Valid Users

Has permission to view server instance-level information.

Note

If you set the View instance-level information permission to Deny or Not set for this group, no users will be able to access the deployment.

Contains all users known to exist in the server instance. You can't modify the membership of this group.

Collection-level groups

When you create an organization or project collection in Azure DevOps, the system creates collection-level groups that have permissions in that collection. You can't remove or delete the built-in collection-level groups.

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. Contains the members of the CollectionName/Service Accounts group. This group should be restricted to the smallest possible number of users who need total administrative control over the collection.

Note

If your deployment uses Reporting Services, consider adding the members of this group to the Team Foundation Content Managers groups in Reporting Services.

Project Collection Build Administrators

Has permissions to administer build resources and permissions for the collection.

Limit this group to the smallest possible number of users who need total administrative control over build servers and services for this collection.

Project Collection Build Service Accounts

Has permissions to run build services for the collection.

Limit this group to service accounts and groups that contain only service accounts. This is a legacy group used for XAML builds. Use the Project Collection Build Service ({your organization}) user for managing permissions for current builds.

Project Collection Proxy Service Accounts

Has permissions to run the proxy service for the collection.

Limit this group to service accounts and groups that contain only service accounts.

Project Collection Service Accounts

Has service level permissions for the collection and for Azure DevOps Server.

Contains the service account that was supplied during installation. This group should contain only service accounts and groups that contain only service accounts. By default, this group is a member of the Administrators group.

Project Collection Test Service Accounts

Has test service permissions for the collection.

Limit this group to service accounts and groups that contain only service accounts.

Project Collection Valid Users

Has permissions to access team projects and view information in the collection.

Contains all users and groups that have been added anywhere within the collection. You can't modify the membership of this group.

Security Service Group

Used to store users who have been granted permissions, but not added to any other security group.

Don't assign users to this group. If you're removing users from all security groups, check if you need to remove them from this group.

Project-level groups

For each project that you create, the system creates the followings project-level groups. These groups are assigned project-level permissions.

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

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 or iteration paths, or customize work item tracking. Members of the Project Administrators group have permissions to perform the following tasks:

  • Add and remove users from project membership
  • Add and remove custom security groups from a project
  • Add and administer all project teams and team-related features
  • Edit project level permission ACLs
  • Edit event subscriptions (email or SOAP) for teams or project-level events.

Project Valid Users

Has permissions to access and view project information.

Contains all users and groups that have been added anywhere to the project. You can't modify the membership of this group.

Note

We recommend that you don't change the default permissions for this group.

Release Administrators

Has permissions to manage all release operations.

Assign to users who define and manage release pipelines.

Note

The Release Administrator group is created at the same time the first release pipeline is defined. It isn't created by default when the project is created.

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. For more information, see Manage teams and configure team tools. To add a user as a team administrator, see Add a team administrator.

Note

Project Administrators can manage all team administrative areas for all teams.

Permissions

The system manages permissions at different levels—server, collection, project, object and role-based permissions—and by default assigns them to one or more built-in groups. You can manage most permissions through the web portal. You can manage more permissions by using one or more security management tools, specifying a namespace permission.

In the following sections, the namespace permission is provided following the permission label that displays in the user interface. For example:
Create tag definition
Tagging, Create

For more information, see Security namespace and permission reference.

Server-level permissions

Manage server-level permissions through the Team Foundation Administration Console or TFSSecurity command-line tool. Team Foundation Administrators are granted all server-level permissions. Other server-level groups have select permission assignments.

Screenshot of Server-level permissions.

Permission (UI)
Namespace permission

Description


Administer warehouse
Warehouse, Administer

Only valid for Azure DevOps Server 2020 and earlier versions that are configured to support SQL Server reports. Can process or change settings for the data warehouse or SQL Server Analysis cube by using the Warehouse Control Web Service.

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

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 is deprecated with Azure DevOps Server 2019 and later versions.

Note

If the Use full Web Access features permission is set to Deny, the user will only see those features permitted for the Stakeholder group (see Change access levels). A Deny will override any implicit Allow, even for accounts that are members of administrative groups such as Team Foundation Administrators.

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.

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.

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

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.

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

Manage project-level permissions through the web portal admin context or the TFSSecurity command-line tool. Project Administrators are granted all project-level permissions. Other project-level groups have select permission assignments.

Note

Several permissions granted to members of the Project Administrators group don't surface within the user interface.

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. Useful for migrations where you don't want to update the by or date fields on import, or when you want to skip the validation of a work item.
Rules can be bypassed in one of two ways. The first is through the Work Items - update REST API and setting the bypassRules parameter to true. The second is through the client object model, by initializing in bypass rules mode (initialize WorkItemStore with WorkItemStoreFlags.BypassRules).


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 more tagging permissions through security management tools. See Security namespace and permission reference, Tagging.

Note

All users granted Stakeholder access can only add existing tags. Even if the Create tag definition permission is set to Allow, stakeholders can't add tags. This is part of the Stakeholder access settings. For more information, see Stakeholder access quick reference. Although the Create tag definition permission appears in the security settings at the project-level, tagging permissions are actually collection level permissions that are scoped at the project level when they appear in the user interface. To scope tagging permissions to a single project when using the TFSSecurity command, you must provide the GUID for the project as part of the command syntax. Otherwise, your change will apply to the entire collection. Keep this in mind when changing or setting these permissions.


Create test runs
Project, PUBLISH_TEST_RESULTS

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.

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


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. Useful for performing migrations of bulk updates by tools and skipping generating notifications.

Consider granting this permission to service accounts or users who have been granted the Bypass rules on work item updates permission. You can set the suppressNotifications parameter to true when updating working via Work Items - update REST API.


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 more information, 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.

Dashboards (object-level)

Permissions for team dashboards can be set individually. The default permissions for a team can be set for a project. Manage the security of dashboards from the web portal.

Team dashboard default permissions

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, Create
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)

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

You can define the following permissions in Build at both 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 some time before they're 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)

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.

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

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 doesn't limit users from creating branches in their local repository; it merely prevents them from publishing local branches to the server.

Note

When a user creates a new branch on the server, they have Contribute, Edit Policies, Force Push, Manage Permissions, and Remove Others' Locks permissions for that branch by default. This means that users can add new commits to the repo via their branch.

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)

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.

Screenshot of 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 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 can't create branches from a branch for which they do not have the Manage Branch permission.

Manage permissions
VersionControlItems, AdminProjectRights

Can manage other users' permissions for folders and files in version control.

Note

Consider adding this permission to any manually added users or groups that contributes to the development of the project and that must be able to create private branches, unless the project is under more restrictive development practices.

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

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

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.

Screenshot of 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)

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.

Screenshot of 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. For more information, 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 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

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 can't modify the plan configuration or settings.

Work item tags

You can manage tagging permissions using the TFSSecurity command-line tool. Contributors can add tags to work items and use them to quickly filter a backlog, board, or query results view.

Permission (UI)

Namespace permission

Description


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 you're using a command-line tool, you must provide the GUID for the project as part of the command syntax. Otherwise, your change will apply to the entire collection. Keep this in mind when changing or setting these permissions.

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)

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.

Screenshot showing 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

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.

✔️