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.

Notes:

1. To learn more about valid user groups, jump to this

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.

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.

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

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.

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

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:

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

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

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

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

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.

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.

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

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

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

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

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

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

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