Compartilhar via


Security groups, service accounts, and permissions in Azure DevOps

TFS 2017 | TFS 2015 | TFS 2013

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.

Server-level groups

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

ADMIN_GROUPS_PERMISSIONS

You can't remove or delete the default server level groups.

Group name

Permissions

Membership

Team Foundation Administrators

Has permissions to perform all server-level operations.

Local Administrators group (BUILTIN\Administrators) for any server that hosts Azure DevOPs/Team Foundation application services.

Server \Team Foundation Service Accounts group and the members of the \Project Server Integration Service Accounts group.

This group should be restricted to the smallest possible number of users who need total administrative control over server-level operations.

Note

If your deployment uses SharePoint or Reporting, consider adding the members of this group to the Farm Administrators and Site Collection Administrators groups in SharePoint and the Team Foundation Content Managers groups in Reporting Services.

Team Foundation Proxy Service Accounts

Has service level permissions for Team Foundation Server Proxy, and some service-level permissions.

Note

This account is created when you install the TFS proxy service.

This group should contain only service accounts and not user accounts or groups that contain user accounts.

Team Foundation Service Accounts

Has service-level permissions for the server instance.

Contains the service account that was supplied during installation

This group should contain only service accounts and not user accounts or groups that contain user accounts. By default, this group is a member of Team Foundation Administrators.

If you need to add an account to this group after you install Azure DevOps Server or TFS, 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.

Project Server Integration Service Accounts

Has service level permissions for the Project Server deployments that are configured for inter-operation with the server instance and some TFS service level permissions.

Note

Created when you install Project Service integration.

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.

SharePoint Web Application Services

Has service level permissions for the SharePoint Web applications that are configured for use with TFS and some service level permissions for TFS.

This group should contain only service accounts and not user accounts or groups that contain user accounts. Unlike the Service Accounts group, this group is not a member of Team Foundation Administrators.

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.

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 not 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. 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. For Azure DevOps, assign to administrators who customize work tracking.

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.

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.

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.

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—server, collection, project, or object—and by default assigns them to one or more built-in groups. You manage most permissions through the web portal.

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

Description

Administer warehouse

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

Can create and administer collections.

Delete project collection

Can delete a collection from the deployment.

Note

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

Edit instance-level information

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 for all team projects defined in all collections defined for the instance:

  • Create and modify areas and iterations
  • Edit check-in policies
  • Edit shared work item queries
  • Edit project level and collection level permission ACLs
  • Create and modify global lists
  • Edit event subscriptions (email or SOAP).

When set through the menus, the Edit instance-level information permission also implicitly allows the user to modify version control permissions. 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

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

Trigger events

Can trigger server-level alert events. Only assign to service accounts and members of the 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

Can view server level group membership and the permissions of those users.

Note

The View instance-level information permission is also assigned to the Team Foundation Valid Users group.

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.

Collection level permissions and groups

Permission

Description

Administer build resource permissions

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

Administer Project Server integration

Can configure the integration of TFS and Project Server to enable data synchronization between the two server products. Applies to TFS 2017 and earlier versions only.

Administer shelved changes

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

Administer workspaces

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

Alter trace settings

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

Create a workspace

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)

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

Create new projects (formerly Create new team projects)

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

Delete team project

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 add users and groups, and edit collection-level permissions for users and groups. Edit collection-level information includes the ability to perform these tasks for all projects defined in a collection:

Make requests on behalf of others

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

Manage build resources

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

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

Can register and de-register test controllers.

Trigger events

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

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

View build resources

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

Can view project collection-level group membership and permissions.

View system synchronization information

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

Screenshot of Project-level permissions dialog, TFS-2018 and earlier versions.

Permission

Description

Bypass rules on work item updates

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

Create tag definition

Can add tags to a work item By default, all members of the Contributors group have this permission.

Note

All users granted Stakeholder access can only add existing tags, not add new tags, even if the Create tag definition permission is set to Allow. This is part of the Stakeholder access settings.
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

Can mark work items in the project as deleted.

  • For TFS 2015.1 and later versions, the Contributors group has Delete and restore work items at the project-level set to Allow by default.
  • For TFS 2015 and earlier versions, the Contributors group has Delete work items in this project at the project-level set to Not set by default. This setting causes the Contributors group to inherit the value from the closest parent that has it explicitly set.

Alter trace settings

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

Delete project

Can delete the project from the project collection.

Delete test runs

Can delete a test run.

Edit project-level information

Can edit project level permissions for users and groups. This permission includes the ability to perform these tasks for the project:

  • Add and administer teams and all team-related features
  • Edit project-level permissions for users and groups in the project
  • Add or remove project-level security groups
  • Edit project level permission ACLs
  • Edit event subscriptions or alerts for teams or the project

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

Can create and delete test configurations.

Manage test environments

Can create and delete test environments.

Permanently delete work items in this project

Can permanently delete work items from this project.

Rename project

Suppress notifications for work item updates

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 the Work Items - update REST API.

View project-level information

Can view project level group membership and permissions.

Can view test plans under the project area path.

Build (object-level)

You manage build permissions for each build defined in the web portal or using the TFSSecurity command-line tool. Project Administrators are granted all build permissions and Build Administrators are assigned most of these permissions. You can set build permissions for all build definitions or for each build 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.

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

Permission

Description

Administer build permissions

Can administer the build permissions for other users.

Delete build definition

Can delete build definitions for this project.

Delete builds

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

Can permanently delete a completed build.

Edit build pipeline

Can save any changes to a build pipeline, including configuration variables, triggers, repositories, and retention policy. Available with Azure DevOps Services, Azure DevOps Server 2019 1.1, and later versions.

Edit build pipeline
Edit build definition

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.

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

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

Manage build qualities

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

Manage build queue

Can cancel, reprioritize, or postpone queued builds. Only applies to XAML builds.

Override check-in validation by build

Can commit a TFVC change set that affects a gated build definition without triggering the system to shelve and build their changes first.

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

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

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

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

Update build information

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

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

View builds

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.

Note

These permissions have changed in TFS 2017 Update 1 and Azure DevOps. If you are using an earlier version of TFS, see the previous list of permissions.

Git repository permissions dialog, TFS

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 have only Read permissions.

Permission

Description

Bypass policies when completing pull requests

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

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

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

Create branch

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

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

Create tag

Can push tags to the repository.

Delete repository

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

Edit policies

Can edit policies for the repository and its branches.

Exempt From policy enforcement

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

Applies to TFS 2015 through TFS 2018 Update 2. (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)

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

Can push and edit Git notes.

Manage permissions

Can set permissions for the repository.

Read

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

Remove others' locks

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

Can change the name of the repository. When set at the top-level Git repositories entry, can change the name of any repository.

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.

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

Description

Administer labels

Can edit or delete labels created by another user.

Check in

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

Can check in changes that were made by other users. Pending changes are committed at check-in.

Check out (up through TFS 2015)

Pend a change in a server workspace (TFS 2017 and higher)

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

Can label items.

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

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

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

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

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

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 Merge

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

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

Description

Create child nodes

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

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

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

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

Can modify test plan properties such as build and test settings.

Note

Consider adding Manage test suites permissions to any manually added users or groups that may need to manage test plans or test suites under this area node.

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

Consider adding Manage test suites permissions 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 this node.

View work items in this node

Can view, but not change, work items in this area node.

Note

If you set the View work items in this node to Deny, the user will not be able to see any work items in this area node. A Deny will override any implicit allow, even for users that are members of an administrative groups.

Iteration Path (object-level)

Iteration path permissions grant or restrict access to create and manage iteration paths, also referred to as sprints.

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

Description

Create child nodes

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

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

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

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

Description

Contribute

Can view and modify this query or query folder.

Delete

Can delete a query or query folder and its contents.

Manage permissions

Can manage the permissions for this query or query folder.

Read

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

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

Description


Create tag definition

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

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

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

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)

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.

Lab Management

Visual Studio Lab Management permissions are specific to virtual machines, environments, and other resources. In addition, the creator of an object in Lab Management is automatically granted all permissions on that object. You can set these permissions by using the TFSLabConfig permissions command-line tool.

By default, the project Readers groups have only View lab resources (Read) permissions.

Note

Lab Management is deprecated for TFS 2017. We recommend that you use Build and Release Management instead of Lab Management for automated testing.

Permission

Description

Delete Environment and Virtual Machines

Can delete environments and templates. The permission is checked for the object that is being deleted.

Delete Environment and Virtual Machines

Can delete environments and templates. The permission is checked for the object that is being deleted.

Delete Lab Locations

Can delete the locations for Lab Management resources, which include collection host groups, collection library shares, project host groups, and project library shares. To delete a location, you must have the Delete Lab Location permission for that location.

Edit Environment and Virtual Machines

Can edit environments and templates. The permission is checked for the object that is being edited.

Environment Operations

Can start, stop, pause, and manage snapshots, in addition to performing other operations on an environment.

Import Virtual Machine

Can import a virtual machine from a VMM library share. This permission differs from Write because it only creates an object in Lab Management and does not write anything to the Virtual Machine Manager host group or library share.

Manage Child Permissions

Can change the permissions of all the child Lab Management objects. For example, if a user has Manage Child Permission for a project host group, the user can change permissions for all the environments under that project host group.

Manage Lab Locations

Can edit the locations of Lab Management resources, which include collection host groups, collection library shares, project host groups, and project library shares. To edit a specific location, you must have the Manage Lab Location permission for that location. This permission for collection level locations (collection host groups and collection library shares) also allows you to create project level locations (project host group and project library share).

Manage Permissions

Can modify the permissions for a Lab Management object. This permission is checked for the object whose permissions are being modified.

Manage Snapshots

Can perform all snapshot management tasks for an environment, which include taking a snapshot, reverting to a snapshot, renaming a snapshot, deleting a snapshot, and reading a snapshot.

Pause Environment

Can pause an environment.

Start

Can start an environment.

Stop

Can stop an environment.

View Lab Resources

Can view information for the various Lab Management resources, which include collection host groups, project host groups, and environment. To view information about a specific lab resource, you must have the View Lab Resources permission for that resource.

Write Environment and Virtual Machines

Can create environments for a project host group. Users who have this permission for a project library share can store environments and templates.

Notifications or alerts

There are no UI permissions associated with managing email notifications or alerts. Instead, they 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.

✔️