Permission reference for Team Foundation Server

Permissions determine what tasks users can and can’t do. For users to have access to Team Foundation Server (TFS) resources and team projects, you need to add them to a team project or TFS group. For an overview of how TFS manages membership, permissions, and access, see Manage users and groups in TFS.

This topic describes TFS permissions and their default assignments to each of the built-in TFS groups. It also explains the tools you can use to set permissions. There are three categories of built-in groups, four permissions levels, and five permission states. Each user’s access to a functional task depends on the explicit or inherited permission state assigned to them or to a group to which they belong.

In this topic What’s new in permissions? Tools used to set permissions Built-in TFS groups Server-level groups Collection-level groups Project-level groups Allow, Deny, Not set, and other permission states Inheritance Do’s and Don’ts when setting permissions Server-level permissions Collection-level permissions Project, test, and object-level permissions Project and test-level permissions Build-level permissions Work item query Tagging Area-level for work item tracking Iteration-level for work item tracking Team Foundation Version Control Git repository Lab Management Release Management

To assign permissions for SharePoint Products or SQL Server Reporting Services, see Add users to team projects and Grant permissions to view or create reports in TFS.

What's new in permissions?

Additions and changes to the TFS permission model are noted in the following table. They are based on the version you have installed on your application-tier server.

TFS version	New or changed permissions
TFS 2013.3	Manage test suites permission added, and Manage test plans permission re-scoped to manage only test plans. These permissions are set for an area path. Previously, it covered permission management of both test plans and test suites.
TFS 2013.2	Tagging permissions added.
TFS 2013	Git repository permissions added.

Tools used to set permissions

You can use the tools listed in the following table to set permissions. Different tools are used depending on whether you are setting permissions at a server, collection, or project-level. You use Team Web Access (TWA) to set most permissions for users and groups to access a team project.

Permission level	TWA administrative page or object-level security	Team Explorer (Note 1)	Team Foundation Administration Console	TFSSecurity command-line tool	Tf command- line tool	TFSLabConfig command line tool
Server-level
Collection-level
Project and test-level
Build-level
Work item query
Tagging
Area-level for work item tracking
Iteration-level for work item tracking
Team Foundation Version Control
Git repository
Lab Management
Release Management (2)

Notes

1. Some permission options that you access from Team Explorer open a user interface in Team Web Access.

2. If you add Release Management to your deployment, you can manage permissions using groups that you define in Release Management, TFS, or Active Directory. You manage permissions through the Release Management client.

Another tool that you can use to manage user membership within groups is the TFSAdmin tool from CodePlex.

Command-line tools, namespaces, and permission names

When you exercise the TFSSecurity command-line tool to manage permissions, you specify a namespace as well as the name of the permission. In the sections below, the namespace and command name are indicated. There are two namespace groups: project collection and server. Use the TFSSecurity /a command to list the namespaces. To obtain the set of permissions you can set under a namespace, use TFSSecurity /a Namespace /collection:CollectionNameURL

Project collection namespaces

Server namespaces

TFSSecurity /a /collection:CollectionNameURL Build BuildAdministration Chat Collection CSS Discussion Threads EventSubscription Git Repositories Identity Iteration Job Project ProjectServerAdministration Registry Server ServiceHooks StrongBox Tagging TeamLabSecurity VersionControlItems VersionControlPrivileges WorkItemQueryFolders WorkItemTrackingAdministration WorkItemTrackingProvision Workspaces

TFSSecurity /a /server:ServerNameURL Catalog CollectionManagement Diagnostic EventSubscription Feature Availability HostingAccount Identity Job Lab Registry Server StrongBox Warehouse WebAccess

Built-in TFS groups

When you install TFS, four groups are defined at the server level. When you create a project collection, seven groups are created at the collection-level, and for each team project that you create, six groups are created that are scoped to the team project. Each of these groups is associated with a set of default permissions. You can’t remove or delete a default server-level groups, such as the Team Foundation Administrators group.

Server-level	Collection-level	Project-level
SharePoint Web Application Services Team Foundation Administrators Team Foundation Service Accounts Team Foundation Valid Users	Project Collection Administrators Project Collection Build Administrators Project Collection Build Service Accounts Project Collection Service Accounts Project Collection Proxy Service Accounts Project Collection Test Service Accounts Project Collection Valid Users (Note 1)	Build Administrators Contributors Project Administrators Project Valid Users (Note 1) Readers TeamProject group (Note 2)

Notes:

1. To learn more about valid user groups, jump to this What is a Valid User? How are Valid User groups populated? section.

2. A team group is created with the name of the team project. For example, if you create a team project named "Code Sample," a team group will also be created with the name "Code Sample Team." You can rename this team.

   In addition, when you create additional teams, a team group is created for each team.

Server-level groups are assigned server-level permissions. Collection-level groups are assigned permissions defined for the collection, project, and objects. And, permissions assigned to project-level groups include both project-level and object-level.

For example, the following picture shows the permissions assigned to the project-level Contributor group.

The Project administrator group permissions include those assigned to the Contributor group and a few more.

Server-level groups

By default, the following groups exist at the server level for the application-tier when you install TFS.

Group name (prefix: Team Foundation\	Permissions	Default user accounts
Team Foundation Administrators	Can perform all operations for TFS. This group should be restricted to the smallest possible number of users who need total administrative control over TFS.	Local Administrators group (BUILTIN\Administrators) for any server that hosts Team Foundation application services. Server\Team Foundation Service Accounts group and the members of the \Project Server Integration Service Accounts group.
Team Foundation Valid Users	Have read access to source code, work items, and build definitions. Access to TWA features is dependent on the license or access level group they’ve been assigned. Important 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 and groups that have been added anywhere within TFS. You can’t modify the membership of this group.
Team Foundation Service Accounts	Have service-level permissions for TFS.	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.
Project Server Integration Service Accounts	Have service-level permissions for the Project Server deployments that are configured for interoperation with TFS. In addition, members of this group have some TFS service-level permissions.	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	Have service-level permissions for the SharePoint Web applications that are configured for use with TFS, in addition to 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.
Team Foundation Proxy Service Accounts	Members of this group have service-level permissions for Team Foundation Server Proxy, and have some TFS service-level permissions.	This group should contain only service accounts and not user accounts or groups that contain user accounts.

Collection-level groups

By default, the following groups exist at the collection level when you configure a collection.

Group name (prefix: TeamProjectCollectionName\	Group-level permissions	Account assignments
Project Collection Administrators	Can perform all operations for the team project collection.	Contains the Local Administrators group (BUILTIN\Administrators) for the server where the application-tier services for TFS have been installed. Also, contains the members of the TeamProjectCollectionName\Service Accounts group. This group should be restricted to the smallest possible number of users who need total administrative control over the collection.
Project Collection Valid Users	Can access team projects defined for the collection. Important If you set the View collection-level information permission to Deny or Not set for this group, no users will be able to access the collection.	Contains all users and groups that have been added anywhere within the team project collection. You cannot modify the membership of this group.
Project Collection Service Accounts	Have service-level permissions for the collection and for TFS.	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 Team Foundation Administrators and Team Foundation Service Accounts.
Project Collection Build Administrators	Can 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	Have those permissions required to run build services for the collection.	Limit this group to service accounts and groups that contain only service accounts.
Project Collection Proxy Service Accounts	Have permissions required to run the proxy service for the collection.	Limit this group to service accounts and groups that contain only service accounts.
Project Collection Test Service Accounts	Have test service permissions for the collection.	Limit this group to service accounts and groups that contain only service accounts.

Project-level groups

By default, the following groups exist when you create a team project. Their permissions are scoped to the project level.

Group (prefix: ProjectName\)	Group-level permissions	Additional notes
Project Administrators	Can administer all aspects of the team project, although they can’t create projects.	Assign to users who will manage user permissions, create teams, define area an iteration paths, or customize work item tracking.
Build Administrators	Can administer build resources and build permissions for the project. Members can manage test environments, create test runs, and manage builds.
Contributors	Can contribute fully to the project code base and work item tacking.	By default, the team group created when you create a team project is added to this group, and any user you add to the team will be a member of this group. In addition, any team you create for a team project will be added to this group by default, unless you choose a different group from the list.
Readers	Can view the project but not modify it.	Assign to stakeholders who want to be able to view work in progress.
TeamName	Inherit the same permissions assigned to the Contributors group. Can contribute fully to the project code base and work item tacking.	The default Team group is created when you create a team project, and by default is added to the Contributors group for the team project. Any new teams you create will also have a group created for them and added to the Contributors group.

Besides these project-level groups, two collection-level groups also appear in every project in TFS:

• TeamProjectCollectionName**\Project Collection Administrators**

  You cannot change the permissions for this collection-level group.

• TeamProjectCollectionName**\Project Collection Build Service Accounts**

  Do not remove or set the View project-level information permission to Deny for this group.

Allow, Deny, Not set, and other permission states

TFS uses a least-permissive model for security permissions. What that means is that if a user belongs to two groups and the same permission is assigned Allow for one group and Deny for another group, Deny takes precedence over Allow. There are a few exceptions to this rule for those who belong to the Project Collection Administrator and Team Foundation Server Administrator groups.

You can specify two explicit authorization states for permissions: Deny and Allow. In addition, there are three other states: Inherited allow, Inherited deny, and Not set. Not set is an implicit Deny state.

Permission	Authorization
Allow	Explicitly grants users to perform the task associated with the specific permission. Allow is usually inherited from group membership. For users to access a task, the associated permission must be set to Allow or Inherited allow.
Deny	Explicitly prevents users from performing the task associated with the specific permission. Deny is usually inherited from group membership.
Inherited allow/Inherited deny	Allows or denies a user to perform the task associated with the permission based on the permission set for a group to which the user belongs.
Not set	Implicitly prevents users from performing the action associated with the permission. Because the permission is neither explicitly set to Deny nor explicitly set to Allow, authorization for that permission can be inherited from other groups of which the user or group is a member. By default, most permissions are not set to either Deny or Allow. The permissions are left Not set.

Permission states follow these precedence settings:

• The Deny permission takes precedence over all other permission settings, including Allow. For example, a user might belong to two groups in a project. For one group, Publish test results permission is set to Deny; the other group has that permission set to Allow. The Deny setting takes precedence and the user is not authorized to publish test results.

  Exceptions to this rule are:

  • The Deny permission does not take precedence if it is inherited from a hierarchical parent. These functions support hierarchical permission setting:

    • Source control folders for Team Foundation version control

    • Git repositories

    • Area and iteration nodes for work item tracking

    • Work item shared queries and query folders

    The explicit permissions that are set on a particular object─such as a source control folder, a repository, or an area child node─override those that are inherited from the parent objects. For example, the Deny set for a source control folder doesn’t override an Allow set for one of its sub-folders.

  • When a user belongs to an administrators group, such as the Project Collection Administrators or Team Foundation Administrators groups, unless otherwise stated in the description of the permission.

• Inherited allow takes precedence over Not set.

Inheritance

When permission is Not set for a user or group, the user or group can be affected by the explicit state for the permission for groups to which they belong because permissions in TFS are inherited. For example, when you review the permissions for a user or group, you might see both Allow and Inherited allow set for permissions. The latter permission is inherited from some other group the user or group belongs to. In this example, a user might belong to a group at the project level and a group at the collection level in a project. If one of those groups has a permission that is explicitly set to Allow and the other group has the same permission Not set, the user will have the Inherited allow permission to perform the actions that are controlled by that permission. The user inherits permissions from both groups, and the Allow permission takes precedence over the Not set permission.

To understand why a permission is inherited, you can pause over the permission setting, and then choose Why?. A new window will open. It displays the inheritance information for that permission.

Some object-level Security dialog boxes provide an Inheritance on/off option. Use this option to disable inheritance for folders, shared queries, and other objects.

Do’s and Don’ts when assigning permissions

Do’s:

• Use Windows groups when managing lots of users.

• Consider granting the Contribute permissions to users or groups that require the ability to create and share work item queries for the project.

• When adding many teams, consider creating a Team Administrators group to TFS where you allocate a subset of the permissions available to Project Administrators.

• When adding teams, consider what permissions you want to assign to team leads, scrum masters, and other team members who may need to create and modify area paths, iteration paths, and queries.

Dont’s:

• Don’t add accounts to the Readers group that you’ve added to the Project Administrators group. Doing so causes a Deny state to be assigned to several permissions.

• Don’t change the default assignments made to a valid users group. If you remove or set the View instance-level information permission to Deny for one of the Valid Users groups, no users in the group will be able to access the team project, collection, or deployment, depending on the group you set.

• Don’t assign permissions that are noted as ‘Assign only to service accounts’ to user accounts.

Server-level permissions

Server-level permissions grant permissions that can affect every project and collection in the deployment. You can set server-level permissions from the Team Foundation Administration Console or using the TFSSecurity command line tool.

You can set these permissions for server-level users and groups, such as Team Foundation Administrators, and for server-level custom groups that you add.

Permission name	TFSSecurity Action	TFSSecurity Namespace	Description	SharePoint Web Application Services	Team Foundation Administrators	Team Foundation Service Accounts
Administer warehouse (Note 1)	Administer	Warehouse	Can process or change settings for the data warehouse or SQL Server Analysis cube by using the Warehouse Control Web Service.
Create team project collection	CreateCollection	CollectionManagement	Can create and administer team project collections.
Delete team project collection (Note 2)	DeleteCollection	CollectionManagement	Can delete a team project collection from the deployment.
Edit instance-level information (Note 3)	GENERIC_WRITE tf: AdminConfiguration tf: AdminConnections	Server	Can edit server-level permissions for TFS users and groups, and add or remove server-level groups from the collection.
Make requests on behalf of others	Impersonate	Server	Can perform operations on behalf of other users or services. Only assign to service accounts.
Trigger events	TRIGGER_EVENT	Server	Can trigger TFS alert events. Only assign to service accounts and members of the Team Foundation Administrators group.
Use full Web Access features (Note 4)	FullAccess	Server	Can use all TWA features.
View instance-level information (Note 5)	GENERIC_READ	Server	Can view server-level group membership and the permissions of those users.

Notes:

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

2. Deleting a team project collection will not delete the collection database from SQL Server.

3. Edit instance-level information includes the ability to perform these tasks for all team projects defined in all project collections defined for the instance:

   • Add and administer teams and all team-related features

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

4. If the Use full Web Access features permission is set to Deny, the user will only see those features permitted for the Limited 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.

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

Collection-level permissions

Collection-level permissions grant authorization to collection-wide tasks, which you can set for these users and groups:

• Collection-level users and groups, such as Project Collection Administrators

• Project-level groups that you add to a collection

• Custom groups that you add to a collection

You can set collection-level permissions from the TWA administration page for the collection, from the Team Foundation Administration Console or using the TFSSecurity command-line tool or tf command-line tool. All permissions are scoped to the specific collection for which they are set.

Permission name	TFSSecurity Action	TFSSecurity Namespace	Description	Project Collection Service Accounts	Project Collection Build Service Accounts	Project Collection Build Administrators	Project Collection Administrators (Note 1)
Administer build resource permissions	AdministerBuildResourcePermissions	BuildAdministration	Can modify permissions for build resources.
Administer Project Server integration	AdministerProjectServer	ProjectServerAdministration	Can configure the integration of TFS and Project Server to enable data synchronization between the two server products.
Administer shelved changes	AdminShelvesets tf: AdminShelvesets	VersionControlPrivileges	Can delete shelvesets created by other users.
Administer workspaces	AdminWorkspaces tf: AdminWorkspaces	VersionControlPrivileges	Can create workspaces for other users and delete workspaces created by other users.
Alter trace settings	DIAGNOSTIC_TRACE	Collection	Can change the trace settings for gathering more detailed diagnostic information about TFS Web services.
Create a workspace (Note 2)	tf: CreateWorkspace	VersionControlPrivileges	Can create a version control workspace.
Create new projects (Note 3)	CREATE_PROJECTS	Collection	Can create projects in the team project collection.
Delete team project (Note 4)	Delete	Project	Can delete team projects.
Edit collection-level information (Note 5)	GENERIC_WRITE tf: AdminConfiguration tf: AdminConnections	Collection VersionControlPrivileges	Can add users and groups, and edit collection-level permissions for users and groups.
Make requests on behalf of others	Impersonate	Server	Can perform operations on behalf of other users or services. Assign only to service accounts.
Manage build resources	ManageBuildResources	BuildAdministration	Can manage build computers, build agents, and build controllers.
Manage process template	MANAGE_TEMPLATE	Collection	Can download, create, edit, and upload process templates..
Manage test controllers	MANAGE_TEST_CONTROLLERS	Collection	Can register and de-register test controllers.
Trigger events (Note 6)	TRIGGER_EVENT	Collection	Can trigger project alert events within the collection. Assign only to service accounts.
Use build resources	UseBuildResources	BuildAdministration	Can reserve and allocate build agents. Assign only to service accounts for build services.
View build resources	ViewBuildResources	BuildAdministration	Can view, but not use, build controllers and build agents that are configured for the collection.
View collection-level information	GENERIC_READ	Collection	Can view collection-level group membership and permissions.
View system synchronization information	SYNCHRONIZE_READ	Collection	Can call the synchronization application programming interfaces. Assign only to service accounts.

Notes:

1. In addition, the following default assignments are made to these TFS groups:

   • Project Collection Valid Users Group: Create a workspace, View build resources, and View collection-level information.

   • Project Collection Proxy Service Accounts: Create a workspace, View build resources, and View collection-level information.

   • Project Collection Test Service Accounts: Create a workspace, Manage test controllers, View build resources, and View collection-level information.

2. The Create a workspace permission is granted to all users as part of their membership within the Project Collection Valid Users group.

3. Additional permissions may be required depending on your deployment. Also, you must run Visual Studio or Team Explorer as an administrator to successfully complete the Create a New Team Project Wizard.

4. Deleting a team project will delete all data that is associated with the project. You cannot undo the deletion of a team project except by restoring the collection to a point before the project was deleted.

5. Edit collection-level information includes the ability to perform these tasks for all team projects defined in a collection:

   • Add and administer teams and all team-related features

   • 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) on project or collection-level events.

   When you set Edit collection-level information to Allow through TWA, users can add or remove collection-level TFS groups and implicitly allows these users 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.

6. Users with this permission can’t remove built-in collection-level groups such as Project Collection Administrators.

7. Adding this permission to other users has the potential to allow denial-of-service attacks.

Project, test, and object-level permissions

Project-level permissions are specific to a single project's users and groups. Within a project, you can set permissions on the objects created for that project, such as areas, iterations, source control folders, queries and query folders, and build definitions. You can set project and object-level permissions for users and groups that you add to a team project or collection.

Many default permissions are assigned to these built-in project-level and collection-level groups:

• Project-level groups: Builders, Contributors, Project Administrators, and Readers

• Collection-level groups: Project Collection Administrators, Project Collection Build Service Accounts, Project Collection Proxy Service Accounts, and Project Collection Test Service Accounts

Project and test-level permissions

You can set project-level permissions from the TWA administration page for the project or by using the TFSSecurity command line tool. All project-level permissions authorize users for the specific team project for which they are set.

Permission Name	TFSSecurity Action	TFSSecurity Namespace	Description	Build Administrators, Contributors, and Teams	Project Administrators (Note 1)
Create tag definition	Create	Tagging	Can add tags through a work item form.
Create test runs	PUBLISH_TEST_RESULTS	Project	Can add and remove test results and add or modify test runs.
Delete team project	DELETE	Project	Can delete the team project from TFS.
Delete test runs	DELETE_TEST_RESULTS	Project	Can delete a scheduled test.
Edit project-level information (Note 2)	GENERIC_WRITE	Project	Can edit project-level permissions for users and groups.
Manage test configurations	MANAGE_TEST_CONFIGURATIONS	Project	Can create and delete test configurations.
Manage test environments	MANAGE_TEST_ENVIRONMENTS	Project	Users who have this permission can create and delete test environments.
View project-level information	GENERIC_READ	Project	Can view project-level group membership and permissions.
View test runs	VIEW_TEST_RESULTS	Project	Can view test plans under the team project area path.

Notes:

1. In addition, the following default assignments are made to these TFS groups:

   • Readers: Create tag definition, View project-level information, and View test runs.

   • Project Collection Administrators: Same permissions as Project Administrators, except for Delete test runs.

   • Project Collection Build Administrators: Same permissions as Project Administrators, except for Delete test runs.

   • Project Collection Build Service Accounts: Create test runs, Manage test configurations, Manage test environments, View project-level information, View test runs.

   • Project Collection Test Service Accounts: Create test runs, Manage test configurations, Manage test environments, View project-level information.

2. Edit project-level information includes the ability to perform these tasks for the team project:

   • Add and administer teams and all team-related features

   • Create and modify areas and iterations

   • Edit check-in policies

   • Edit shared work item queries

   • Edit project-level permission ACLs

   • Create and modify global lists

   • Edit event subscriptions (email or SOAP) on project-level events.

Build-level permissions

You can set build-level permissions for all builds or for a build definition from the context menu for the build definition in TWA or Team Explorer, or by using the TFSSecurity command line tool.

Permission name (UI)	TFSSecurity Action	TFSSecurity Namespace	Description	Contributors	Build Definition Authors or Builders	Build Administrators	Project Administrators (Note 1)
Administer build permissions	AdministerBuildPermissions	Build	Can administer the build permissions for other users.
Delete build definition	DeleteBuildDefinition	Build	Can delete build definitions for this project.
Delete builds	DeleteBuilds	Build	Can delete a completed build.
Destroy builds	DestroyBuilds	Build	Can permanently delete a completed build.
Edit build definition (Note 2)	EditBuildDefinition	Build	Can create and modify build definitions for this project.
Edit build quality	EditBuildQuality	Build	Can add information about the quality of the build through Team Explorer or Team Web Access.
Manage build qualities	ManageBuildQualities	Build	Can add or remove build qualities.
Manage build queue	ManageBuildQueue	Build	Can cancel, re-prioritize, or postpone queued builds.
Override check-in validation by build (Note 3)	OverrideBuildCheckInValidation	Build	Can commit a changeset that affects a gated build definition without triggering the system to shelve and build their changes first.
Queue builds	QueueBuilds	Build	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	RetainIndefinitely	Build	Can mark a build so that it will not be automatically deleted by any applicable retention policy.
Stop builds	StopBuilds	Build	Can stop any build that is in progress, including builds queued and started by another user.
Update build information	UpdateBuildInformation	Build	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	ViewBuildDefinition	Build	Can view the build definitions that have been created for the team project.
View builds	ViewBuilds	Build	Can view the queued and completed builds for this team project.

Notes:

1. In addition, the following default assignments are made to these built-in groups:

   • Readers: View build definition and View builds.

   • Project Collection Administrators: All permissions except for Update build information.

   • Project Collection Build Administrators: All permissions except for Override check-in validation by build and Update build information..

   • Project Collection Build Service Accounts: Edit build quality, Manage build queue, Update build information, Override check-in validation by build, Queue builds, View build definitions, and View builds.

   • Project Collection Test Service Accounts: Update build information, View build definitions, and View builds.

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

3. 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. For more information, see Check in to a folder that is controlled by a gated check-in build process.

Work item query permissions

You can set work item query permissions from the shortcut menu of Shared Queries from TWA or Team Explorer or by using the TFSSecurity command line tool. All permissions are scoped to the specific query or query folder for which they are set.

Consider granting the Contribute permissions to users or groups that require the ability to create and share work item queries for the project. To create query charts you need Advanced access.

Permission name	TFSSecurity Action	TFSSecurity Namespace	Description	Readers, Contributors, Build Administrators	Creator Owners, Project Administrators, Project Collection Administrators
Contribute	CONTRIBUTE	WorkItemQueryFolders	Can view and modify this query or query folder.
Delete	DELETE	WorkItemQueryFolders	Can delete a query or query folder and its contents.
Manage Permissions	MANAGEPERMISSIONS		Can manage the permissions for this query or query folder.
Read	READ	WorkItemQueryFolders	Can view and use the query or the queries in a folder, but cannot modify the query or query folder contents.
	FullControl	WorkItemQueryFolders	Can view, edit, delete, and manage permissions for a query or query folder and its contents.

Tagging permissions

Tags provide a quick way of grouping or categorizing work items. Tagging permissions are available with on-premises TFS deployments with TFS 2013.2 or later versions installed. You can set the Create tag definition from the TWA administration Security page. To set all remaining permissions, use the TFSSecurity command line tool.

Permission name	TFSSecurity Action	TFSSecurity Namespace	Description	Readers	Contributors	Project Administrators (Note 1)
Create tag definition (Note 2)	CREATE	Tagging	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 team project.
Delete tag definition (Note 3, 4)	DELETE	Tagging	Can remove a tag from the list of available tags for that project.
Enumerate tag definition (Note 4, 5)	ENUMERATE	Tagging	Can view a list of tags available for the work item within the team 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.
Update tag definition (Note 4)	UPDATE	Tagging	Can rename a tag by using the REST API.

Notes:

1. In addition, the Project Collection Service Accounts group has all tagging permissions explicitly assigned.

2. Readers and Contributors inherit the Create tag definition permission as it is set explicitly to Allow for the Project Valid Users group.

   Although the Create tag definition permission appears in the security settings at the team 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 team 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 team project collection. Keep this in mind when changing or setting these permissions.

3. There is no UI support to delete a tag. To delete a tag, remove the assignments that are associated with the tag. TFS automatically deletes unassigned tags after 3 days of non-use.

4. Does not appear in the UI; can only be set by using the TFSSecurity command.

5. The View project-level information set to Allow for Readers and Contributors implicitly allows users in these groups to view existing tags (Enumerate tag definition permission).

Area-level permissions for work item tracking

Area-level permissions grant or restrict access to work items defined for a project based on their location with their area tree hierarchy.

You can define and set area-level permissions from the TWA administration page for Areas or by using the TFSSecurity command line tool. All permissions are scoped to the specific area-path for which they are set.

Permission name	TFSSecurity Action	TFSSecurity Namespace	Description	Contributors	Build Administrators	Project Collection Build Service Accounts (Note 1)
Create child nodes (Note 2)	CREATE_CHILDREN	CSS	Can create area nodes. Users who have both this permission and the Edit this node permission can move or re-order any child area nodes.
Delete this node (Note 2)	DELETE	CSS	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.
Edit this node (Note 2)	GENERIC_WRITE	CSS	Can set permissions for this node and rename area nodes.
Edit work items in this node (Note 3)	WORK_ITEM_WRITE	CSS	Can edit work items in this area node.
Manage test plans (Note 4)	MANAGE_TEST_PLANS	CSS	Can modify test plan properties such as build and test settings.
Manage test suites (Note 4)	MANAGE_TEST_SUITES	CSS	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).
View permissions for this node	GENERIC_READ	CSS	Can view the security settings for this node.
View work items in this node (Note 5)	WORK_ITEM_READ	CSS	Can view, but not change, work items in this area node.

Notes:

1. In addition, the following default assignments are made to these built-in groups:

   • Readers: View permissions for this node and View-only permissions.

   • Project Collection Test Service Accounts: View-only permissions.

   • Team Foundation Administrators, Project Collection Administrators, and Project Administrators: All CSS permissions. Any user or group that has Edit instance-level information, Edit collection-level information, or Edit project-level information permissions can create and manage area nodes.

   • 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 area node.

2. Consider adding this permission to any manually added users or groups that may need to delete, add, or rename area nodes.

3. Consider adding this permission to any manually added users or groups that may need to edit work items under the area node.

4. Manage test suites permission was added with the TFS 2013.3 update. Consider adding these permissions to any manually added users or groups that may need to manage test plans or test suites under this area node.

5. 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 accounts that are members of administrative groups such as Team Foundation Administrators.

Iteration-level permissions for work item tracking

Iteration-level permissions grant or restrict access to create and manage iteration paths.

You can set iteration-level permissions for users and groups that you add to a team project or collection using the TWA administration page for Iterations or the TFSSecurity command line tool. All permissions are scoped to the specific iteration-path for which they are set.

Some work item tracking operations require multiple permissions. For example, you need multiple permissions to delete a node.

Consider granting team administrators, scrum masters, or team leads permissions to create, edit, or delete nodes.

Permission name	TFSSecurity Action	TFSSecurity Namespace	Description	Project Administrators (Note 1)
Create child nodes (Note 2)	CREATE_CHILDREN	Iteration	Can create iteration nodes. Users who have both this permission and the Edit this node permission can move or re-order any child iteration nodes.
Delete this node (Note 2)	DELETE	Iteration	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.
Edit this node (Note 2)	GENERIC_WRITE	Iteration	Can set permissions for this node and rename iteration nodes.
View permissions for this node (Note 3)	GENERIC_READ	Iteration	Can view the security settings for this node.

Notes:

1. Team Foundation Administrators and Project Collection Administrators are granted all Iteration permissions. Any user or group that has Edit instance-level information, Edit collection-level information, or Edit project-level information permissions can create and manage iteration nodes.

2. Consider adding this permission to any manually added users or groups that might need to delete, add, or rename iteration nodes.

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

Team Foundation Version Control (TFVC) permissions

You can set permissions on TFVC source code files and folders from the context menu for the file or folder definition in TWA or Team Explorer, or by using the tf permission command line tool. These permissions appear only for a team project set up to use TFVC as the source control system.

In version control permissions, explicit deny takes precedence over administrator group permissions.

Permission name	TFSSecurity Action and tfperm	TFSSecurity Namespace	Description	Contributors	Build Administrators	Project Collection Build Service Accounts	Project Administrators (Note 1)
Administer labels	tf: LabelOther	VersionControlItems	Can edit or delete labels created by another user.
Check in (Note 2)	tf: Checkin	VersionControlItems	Can check in items and revise any committed changeset comments. Pending changes are committed at check-in.
Check in other users' changes	tf: CheckinOther	VersionControlItems	Can check in changes that were made by other users. Pending changes are committed at check-in.
Check out (Note 2)	tf: PendChange	VersionControlItems	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.
Label	tf: Label	VersionControlItems	Can label items.
Lock	tf: Lock	VersionControlItems	Can lock and unlock folders or files.
Manage branch	tf: ManageBranch	VersionControlItems	Can convert any folder under that path into a branch, and also take the following actions on a branch: edit its properties, re-parent 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 (Note 3)	tf: AdminProjectRights	VersionControlItems	Can manage other users' permissions for folders and files in version control.
Merge (Note 4)	tf: Merge	VersionControlItems	Can merge changes into this path.
Read	tf: Read	VersionControlItems	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 (Note 5)	tf: ReviseOther	VersionControlItems	Can edit the comments on checked-in files, even if another user checked in the file.
Undo other users' changes Merge (Note 5)	tf: UndoOther	VersionControlItems	Can undo a pending change made by another user.
Unlock other users' changes (Note 5)	tf: UnlockOther	VersionControlItems	Can unlock files locked by other users.

Notes:

1. In addition, all permissions are set to Inherited allow for Project Collection Administrators and Project Collection Service Accounts.

   Readers group is assigned view-only permissions: Read.

2. 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 changeset comments.

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

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

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

Git repository permissions

You can set permissions on a Git project, repository, or branch from the context menu or from the administration page in TWA, or by using the TFSSecurity command line tool. These permissions appear only for a team project set up to use Git as the source control system.

You can set all permissions for a project or repository. You can set Administer, Contribute, and Rewrite and destroy history (force push) permissions for a branch. Repositories and branches inherit permissions from assignments made at the project level.

By default, the project-level and collection level Readers groups have only Read permissions.

Permission name	TFSSecurity Action	TFSSecurity Namespace	Description	Contributors	Build Administrators	Project Administrators (Note 1)
Administer (Note 2)	Administer	GitRepositories	Can rename the repository, add additional repositories, verify the database, and set permissions for the branch. Users who have this permission can delete the repository if they also have the Force permission. At the branch level, can set permissions for the branch and delete the branch.
Branch Creation	CreateBranch	GitRepositories	Can 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.  When a user creates a new branch on the server, they have Administer, Contribute, and Force permissions for that branch by default.
Contribute	GenericContribute	GitRepositories	Can push their changes to the repository. At the branch level, can push their changes to the branch.
Note Management	ManageNote	GitRepositories	Can push and edit Git notes to the repository.  They can also remove notes from items if they have the Force permission.  See this topic for more details on notes.
Read	GenericRead	GitRepositories	Can clone, fetch, pull, and explore the contents of the repository, but cannot push any changes they make to the repository.
Rewrite and destroy history (force push)	ForcePush	GitRepositories	Can force an update, which can overwrite or discard commits from any user. Deleting commits changes the history. Without this permission, users cannot discard their own changes. Rewrite and destroy history is also required to delete a branch. Because Rewrite and destroy history enables users to change the history or remove a commit from history, users who have this permission can delete a change and its history from the server. They can also modify the commit history of the server repository. At the branch level, can rewrite and destroy history of the branch.
Tag Creation	CreateTag	GitRepositories	Can push tags to the repository, and can also edit or remove tags from items if they have the Force permission.

Notes:

1. For Project Collection Administrators and Project Collection Service Accounts, all permissions are set to Inherited allow.

   Readers and Project Collection Build Service Accounts groups are assigned view-only permissions: Read.

2. Consider adding all permissions to any manually added users or groups that contribute to the development of the project.

Lab Management permissions

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-level and collection level Readers groups have only View lab resources (Read) permissions.

Permission name	TFSLabConfigperm	Description	Contributors (Note 1)	Project Administrators	Project Collection Build Service	Team Foundation Administrators, Project Collection Administrators
Delete Environment and Virtual Machines	Delete	Can delete environments and templates. The permission is checked for the object that is being deleted.
Delete Lab Locations	DeleteLocation	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	Edit	Can edit environments and templates. The permission is checked for the object that is being edited.
Environment Operations	EnvironmentOps	Can start, stop, pause, and manage snapshots, in addition to performing other operations on an environment.
Import Virtual Machine	Create	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	ManageChildPermissions	Can change the permissions of all the child Lab Management objects. For example, if a user has Manage Child Permission for a team project host group, the user can change permissions for all the environments under that team project host group.
Manage Lab Locations	ManageLocation	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	ManagePermissions	Can modify the permissions for a Lab Management object. This permission is checked for the object whose permissions are being modified.
Manage Snapshots	ManageSnapshots	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	Pause	Can pause an environment.
Start	Start	Can start an environment.
Stop	Stop	Can stop an environment.
View Lab Resources	Read	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	Write	Can create environments for a project host group. Users who have this permission for a project library share can store environments and templates.

Notes:

1. The Readers group is assigned view-only permissions: Read.

Release Management permissions

In Release Management, you can assign permissions based on the role assigned to a user, explicit functional permissions assigned to groups, or permissions assigned to specific instances of a release object. In addition, you can assign approvers and validators to specific stages within a release path to ensure that the applications being deployed meet quality standards.

• Role based: The two roles are Release Manager and Service User. Release Managers can manage all functions, regardless of the groups they are linked to. Service User corresponds to a service account role. To limit a user’s access, do not assign them to any role. Instead, have them inherit the permissions assigned to the group they are linked to.

• Group: To restrict access to specific functional areas, you assign the permissions allowed by that group. Members of that group inherit the permissions assigned to the group. Restricting access requires that you change the permissions granted to the Everyone group, which by default has all permissions.

• Object: In addition to roles and groups, you can restrict access to edit, view, and manage security of release paths and release templates. You do this through the Security tab on the release path and through the Properties page for a release template.

• Approvers and Validators: Approvers and validators must sign off at each step or stage of a release. You assign approvers and validators when you configure a release path. All approvers and validators must be added as users or a member of a group in Release Management.

Release Management defines a single default group, Everyone, to which all accounts that you add to Release Management belong. In addition, specific permissions are allocated to the Release Manager and Service User roles.

You manage Release Management permissions from the Release Management client. You can set these permissions by opening the sub-menu listed in the Where set column. To learn more about how to set these permissions, see Add users and groups and control access to Release Management. To install Release Management, go here.

Permission name or user role	Where set	Description	Everyone	Release Manager Role	Service User role
Release Manager	Administration > My Profile and New User page	Can administer the Release Management server, manage the connection between TFS and Release Management, and manage the following objects: Release paths and stage information defined in a release path. Release templates, including adding custom tools and actions and deployment sequence and configuration variables for all stages defined in a release template. Security for all functional areas. Consider adding: Users who will administer the Release Management server.
Service User	Administration > My Profile and New User page	Can manage deployments or web application pools. Consider adding: Service account identities assigned to run server application pools, deployment agent’s Windows Service, and Release Management monitoring of Windows Services.
View	Configure Apps > Release Template > Properties Configure Paths > Release Paths	Can view release templates or release paths and selectively assign view access to specific release templates and release paths to specific users. Consider adding: Users or groups that need to view specific release templates or release paths, but not edit them.
Edit	Configure Apps > Release Template > Properties Configure Paths > Release Paths	Can edit release templates or release paths and choose which users can edit specific release templates and release paths to specific users. Consider adding: Users or groups that need to edit specific release templates or release paths.
Can Release	Configure Apps > Release Template > Properties	Can initiate a release and specify which users can initiate a release from those release templates that they can view. Consider adding: Users or groups that will initiate a release. With this permission, you can specify which users can initiate a release from those release templates that they can view.
Manage Security	Configure Apps > Release Template > Properties Configure Paths > Release Paths	Can manage which groups have permissions to view, edit, or manage release templates or release paths. Consider adding: Users or groups that will manage which groups have permissions to view, edit, or manage release templates or release paths. With this permission, creators of release templates and release paths can control who can view, edit, or release specific templates or paths.
Can Create Release Template	Configure Apps > Release Template	Can define release templates. Without this permission, the New button on the Configure Apps > Release Template tab is hidden. Consider adding: Users or groups that need to create, start, or approve a release.
Can Create Release Path	Configure Paths > Release Paths	Can define the stages, approval process, and security of release paths. Without this permission, the New button on the Configure Paths > Release Paths tab is hidden. Consider adding: Users or groups that need to manage the release configuration used in deploying applications.
Can Manage Environment	Configure Paths > Environments	Can define the stages that comprise a release path and the servers and security for each stage. Without this permission, the Configure Paths > Environments tab is hidden. Consider adding: Users or groups that need to manage the servers and environments used to define the release paths.
Can Manage Server	Configure Paths > Server	Can define the release paths for deploying applications in your system. This permission supports access to defining the servers use to deploy applications to test, stage, and production servers. Without this permission, the Configure Paths > Server tab is hidden. Consider adding: Users or groups that will define the release paths for deploying applications in your system. This permission supports access to defining the servers used to deploy applications to test, stage, and production servers.
Can Manage Inventory	Inventory > Actions and Tools	Can define custom tools or actions for deploying applications in your system. With this permission they can view, edit, and create actions and tools. See Release actions to deploy an app for Release Management. Without this permission, the Inventory tab is hidden. Consider adding: Users or groups that will define custom tools or actions for deploying applications in your system. With this permission they can view, edit, and create actions and tools used in deploying applications.
Can Use Custom Tool in Actions and Components	Configure Apps > Component> Deployment Configure Apps > Release Template > Component > Deployment	Can edit the Command and Arguments fields when No Tool is selected. Without this permission, users cannot edit these fields. Consider adding: Users or groups that will define release paths or release templates or who will initiate releases. This allows them to edit the Command and Arguments fields when No Tool is selected.
Edit Values and Target Servers	Configure Apps > Release Template	Can edit deployment sequence and configuration variables for specific releases or stages. Without this permission, stage information is read-only. Consider adding: Users or groups that will define release paths or release templates or who will initiate releases. This allows them to edit deployment sequence and configuration variables for specific releases or stages.
Edit Approvals and Environment	Configure Paths > Release Path > Stages	Can edit approvals and environments for a specific stage. Without this permission, stage information is read-only. Consider adding: Users or groups that will define release paths or release templates. This allows them to edit approvals and environments for a specific stage.Without this permission, stage information is read-only.

Q & A

Q: What’s the difference between permissions and access levels?

A: Certain features in TFS are only available to users who have the appropriate licensing level for those features. Access to those features is not controlled by permissions but by membership in licensing groups for Team Web Access. See Change access levels.

Q: What permissions are assigned to team administrators?

A: Team administrators are granted several role-based permissions that are described here.

Q: What permissions are associated with Alerts?

A: There are no UI permissions associated with alerts that you can subscribe to through TWA.

By default, all Contributors can subscribe to alerts for themselves. Project Collection Administrators and Project Administrators or users or members of groups who have either the Edit collection-level information or Edit project-level information can set alerts for others or for a team.

You can manage alert permissions using TFSSecurity at the collection-level. The Team Foundation Event service is designed to be flexible and extensible.

TFSSecurity Action	TFSSecurity Namespace	Description	Project Collection Administrators and 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 team project.
GENERIC_WRITE	EventSubscription	Can create alerts for other users or for a team.
UNSUBSCRIBE	EventSubscription	Can unsubscribe from an event subscription.

Q: What additional features or tools reference groups?

A: These features reference built-in and custom (ones that you create) TFS groups:

• Work item queries: In Group, Not in Group operator

• Field (Definition) child XML element attribute: for and not attributes

• Field (Workflow) child XML element attribute: for and not attributes

• Access levels

Q: What is a Valid User? How are Valid User groups populated?

A: When you add accounts of users directly to a TFS group or through a Windows group, they are automatically added to one of the valid user groups.

• Server\Team Foundation Valid Users: All members added to server-level groups.

• ProjectCollectionName\Project Collection Valid Users: All members added to project-collection level groups.

• TeamProjectName\Project Valid Users: All members added to project-level groups.

The default permissions assigned to these groups are primarily limited to read access, such as View build resources, View project-level information, and View collection-level information.

This means that all users that you add to one team project can view the objects in other team projects within a collection. If you need to restrict view access, then you can set restrictions through the area path node. For additional methods, see Restrict access to functions and tasks.

If you remove or set the View instance-level information permission to Deny for one of the Valid Users groups, no users in the group will be able to access the team project, collection, or deployment, depending on the group you set.

In addition, the VALIDUSER element can be used to allow or restrict access for work item tracking.

Q: How do I manage permissions to access reports or the project portal?

A: For information about how to set permissions in Reporting Services and SharePoint Products for users in TFS, see Set administrator permissions for team project collections, and Set administrator permissions for Team Foundation Server.

For step-by-step examples of how to create custom groups, configure permissions to control access to resources, and other options, see Restrict access to functions and tasks.