Permissions and groups defined for Team Services and TFS

Last Update: 3/20/2017

Team Services | TFS 2017 | TFS 2015 | TFS 2013

To access the resources you manage in Team Services or TFS—like your code, builds, and work—you need to have permissions to those specific resources. Permissions may apply to an entire TFS instance, to a collection in that instance, to a team project, or to specific objects in a team project—builds, areas, iterations, work item queries, tagging, tfvc, git, lab and release management.

Each functional area uses groups to simplify management across the deployment. You add users and groups through the web portal administration context. Permissions are automatically set based on the group that you add users to, or based on the object, project, collection, or server level to which you add groups.

This topic provides descriptions for each built-in group and permission. To learn how to add users to a group or set a specific permission that you can manage through the web portal, see the following resources:

Conceptual image of permissions and access levels

Permission states

User or group has permissions to perform a task:

  • Allow
  • Inherited allow

User or group doesn't have permission to perform a task:

  • Deny
  • Inherited deny
  • Not set
To learn more about inheritance, go here.
NOTE

Certain features 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 an access level. To learn more, see Manage users and access (Team Services) or Change access levels (TFS).

Groups

Permissions can be granted directly to an individual, or to a group. Using groups can make things a lot simpler, and TFS sets up some built-in groups for that purpose. These groups and the permissions they're assigned to exist at several different levels: server (TFS deployment), team project collection, team project, and specific objects. You can also create your own groups and grant them the specific set of permissions that are appropriate for certain roles in your organization.

Server-level groups (TFS)

Server groups apply to TFS only. When you install TFS, the system creates default groups that have deployment-wide, server-level permissions. You can neither remove nor delete the built-in server-level groups.

  • Team Foundation Administrators ▼

    Permission: Has permissions to perform all operations for TFS.

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

    This group should be restricted to the smallest possible number of users who need total administrative control over TFS.

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

    Permission: Has service level permissions for Team Foundation Server Proxy, and some TFS service level permissions.

    Created when you install the TFS proxy service.

    Membership:

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

  • Team Foundation Service Accounts ▼

    Permission: Has service level permissions for TFS.

    Membership: Contains the service account that was supplied during installation.

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

  • Team Foundation Valid Users ▼

    Permission: Has permission to view instance level information.

    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.

    Membership: Contains all users known to exist in the Team Services account or TFS instance. You can’t modify the membership of this group.

  • Project Server Integration Service Accounts ▼
    Native support for TFS-Project Server integration is deprecated for TFS 2017. Go here to learn more.

    Permission: Has service level permissions for the Project Server deployments that are configured for interoperation with TFS and some TFS service level permissions.

    Created when you install Project Service integration.

    Membership: 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 ▼

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

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

The full name of each of these groups is [Team Foundation]/{group name}. So the full name of the server-level administrators group is [Team Foundation]/Team Foundation Administrators.

Collection-level groups

When you create a Team Services account or TFS collection, the system creates collection-level groups that have permissions in that collection. You can neither remove nor delete the built-in collection-level groups.

  • Project Collection Administrators ▼

    Permission: Has permissions to perform all operations for the account or collection.

    Membership: 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 CollectionName\Service Accounts group.

    This group should be restricted to the smallest possible number of users who need total administrative control over the collection.

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

    Permission: Has service level permissions for Team Foundation Server Proxy, and some TFS service level permissions.

    Created when you install the TFS proxy service.

    Membership:

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

  • Project Collection Build Service Accounts ▼

    Permission: Has service level permissions for TFS.

    Membership: Contains the service account that was supplied during installation.

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

  • Project Collection Proxy Service Accounts ▼

    Permission: Has service level permissions for Team Foundation Server Proxy, and some TFS service level permissions.

    Created when you install the TFS proxy service.

    Membership:

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

  • Project Collection Service Accounts ▼

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

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

  • Project Collection Test Service Accounts ▼
    Native support for TFS-Project Server integration is deprecated for TFS 2017. Go here to learn more.

    Permission: Has service level permissions for the Project Server deployments that are configured for interoperation with TFS and some TFS service level permissions.

    Created when you install Project Service integration.

    Membership: 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 Collection Valid Users ▼

    Permission: Has permission to view collection-level information.

    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.

    Membership: Contains all users known to exist in the TFS instance. You can’t modify the membership of this group.

  • Security Service Group ▼ (Team Services, TFS 2017)

    Permission: Has limited permissions to view collection-level information.

    Membership: Contains account identities that have been granted explicit permission to a resource. These identities are automatically added to this group if they were not previously a member of any other group. This is an internal group used by the system. Don't use this group to manage users or permissions.

The full name of each of these groups is [{collection name}]/{group name}. So the full name of the adminstrators group for the default collection is [Default Collection]/Project Collection Administrators.

Project-level groups

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

  • Build Administrators ▼

    Permission: Has permissions to administer build resources and build permissions for the team project. Members can manage test environments, create test runs, and manage builds.

    Membership: Add members of the team that will define and manage builds to this group.

  • Contributors ▼

    Permission: Has permissions to contribute fully to the team project code base and work item tacking.

    Membership: 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 ▼

    Permission: Has permissions to view the team project but not modify it.

    Membership: Assign to stakeholders who want to be able to view work in progress.

  • Project Administrators ▼

    Permission: Has permissions to administer all aspects of the team project, although they can’t create team projects.

    Membership: Assign to users who will manage user permissions, create teams, define area an iteration paths, or customize work item tracking.

  • Project Valid Users ▼

    Permission: Has permissions to access the team project.

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

    Membership: Contains all users and groups that have been added anywhere within the team project. You cannot modify the membership of this group.

  • Release Administrators ▼

    Permission: Has permissions to manage all aspects of release management.

    This group is defined for Team Services and TFS 2017.

    Membership: Add users to this group who will have responsibility for overseeing and managing releases and release permissions.

  • Team name

    Permission: Has permissions to contribute fully to the team 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.

    You can grant permissions to administer team assets by adding members to the team administrator role.

    Membership: Add members of a team to this group.


The full name of each of these groups is [{team project name}]/{group name}. contributors group for a team project called "My Project" is . [My Project]/Contributors.

Team administrator role

For each team that you add, you can assign one or more team members as administrators. The team admin role isn't a group with a set of defined permissions. Instead, the team admin role is tasked with managing the following team assets.

NOTE

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

Permissions

The system manages permissions at different levels—server, collection, project, or object—and by default assigns them to one or more built-in groups. You manage most permissions through the web portal.

Server-level permissions (TFS)

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

  • Administer warehouse ▼

    Can process or change settings for the data warehouse or SQL Server Analysis cube by using the Warehouse Control Web Service.

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


  • Create team project collection ▼

    Can create and administer collections.

  • Delete team project collection ▼

    Can delete a collection from the deployment. See Manage team project collections.

    Deleting a collection will not delete the collection database from SQL Server (TFS). For Team Services, you would delete your account as described in Delete or recover your account.
  • Edit instance-level information ▼

    Can edit server-level permissions for TFS users and groups, and add or remove server-level groups from the collection.

    Edit instance-level information includes the ability to perform these tasks for all team projects defined in all 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 team project level and collection- level permission ACLs
    • Create and modify global lists
    • Edit event subscriptions (email or SOAP).

    When set through the menus, the Edit instance-level information permission also implicitly allows the user to modify version control permissions. To grant all these permissions at a command prompt, you must use the tf.exe Permission command to grant the AdminConfiguration and AdminConnections permissions in addition to GENERIC_WRITE.

  • Make requests on behalf of others ▼

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

  • Trigger events ▼

    Can trigger TFS alert events. Only assign to service accounts and members of the Team Foundation Administrators group.

  • Use full Web Access features ▼

    Can use all web portal features.

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

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

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

Collection-level permissions

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

Project-level permissions

You manage project-level permissions from the web portal admin context or using the TFSSecurity command-line tool. Project Administrators are assigned all project-level permissions. Other project-level groups are assigned a subset of these permissions.

Build permissions (object-level)

You manage build permissions for each build defined in the web portal or using the TFSSecurity command-line tool. Project Administrators are granted all build permissions and Build Administrators are assigned most of these permissions. You can set build permissions for each build definition.

  • Administer build permissions ▼

    Can administer the build permissions for other users.

  • Delete build definition ▼

    Can delete build definitions for this team project.

  • Delete builds ▼

    Can delete a completed build.

  • Destroy builds ▼

    Can permanently delete a completed build.

  • Edit build definition ▼

    Can create and modify build definitions for this team project.

    You turn Inheritance Off for a build definition when you want to control permissions for specific build definitions.

    When inheritance is On, the build definition respects the build permissions defined at the team project level or a group or user. For example, a custom Build Managers group has permissions set to manually queue a build for team project Fabrikam. Any build definition with inheritance On for team project Fabrikam would allow a member of the Build Managers group the ability to manually queue a build.

    However, by turning Inheritance Off for team project Fabrikam, you can set permissions that only allow Project Administrators to manually queue a build for a specific build definition. This would then allow me to set permissions for that build definition specifically.

  • Edit build quality ▼

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

  • Manage build qualities ▼

    Can add or remove build qualities.

  • Manage build queue ▼

    Can cancel, re-prioritize, or postpone queued builds.

  • Override check-in validation by build ▼

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

    Assign the Override check-in validation by build permission only to service accounts for build services and to build administrators who are responsible for the quality of the code. For more information, see Check in to a folder that is controlled by a gated check-in build process.
  • Queue builds ▼

    Can put a build in the queue through the interface for Team Foundation Build or at a command prompt. They can also stop the builds that they have queued.

  • Retain indefinitely ▼

    Can mark a build so that it will not be automatically deleted by any applicable retention policy.

  • Stop builds ▼

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

  • Update build information ▼

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

  • View build definition ▼

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

  • View builds ▼

    Can view the queued and completed builds for this team project.

To manage build security, see build permissions.

Git repository permissions (object-level)

NOTE

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

You manage the security of each Git repository or branch from the web portal or using the TFSSecurity command-line tool. Project Administrators are granted most of these permissions (which appear only for a team project that's been configured with a Git repository). You can manage these permissions for each Git repository.

  • Contribute ▼

    At the repository level, can push their changes to existing branches in the repository. Users who lack this permission but who have create branch may push changes to new branches. Does not override restrictions in place from branch policies.

    At the branch level, can push their changes to the branch and lock the branch.

  • Create Branch ▼

    Can create and publish branches in the repository. Lack of this permission does not limit users from creating branches in their local repository; it merely prevents them from publishing local branches to the server. When a user creates a new branch on the server, they have Contribute, Edit Policies, Force Push, Manage Permissions, and Remove Others' Locks permissions for that branch by default.

  • Create Repository ▼

    Can create new repositories.

  • Create Tag ▼

    Can push tags to the repository.

  • Delete Repository ▼

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

  • Edit Policies ▼

    Can edit policies for the repository and its branches.

  • Exempt From Policy Enforcement ▼

    Can bypass branch policies.

  • Force Push (Rewrite History and Delete Branches) ▼

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

  • Manage Notes ▼

    Can push and edit Git notes. See this topic for more details on notes.

  • Manage Permissions ▼

    Can set permissions for the repository.

  • Read ▼

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

  • Remove Others' Locks ▼

    Can remove branch locks set by other users.

  • Rename Repository ▼

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

NOTE

Set permissions across all Git repositories by making changes to the top-level Git repositories entry. Individual repositories inherit permissions from the top-level Git repositories entry. Branches inherit permissions from assignments made at the repository level. By default, the team project level and collection-level Readers groups only have Read permissions.

To manage Git repo and branch permissions, see Set branch permissions.

TFVC permissions (object-level)

You manage the security of each TFVC branch from the web portal or using the TFSSecurity command-line tool. Project Administrators are granted most of these permissions which appear only for a team project that's been configured to use Team Foundation Version Control as the source control system. In version control permissions, explicit deny takes precedence over administrator group permissions.

  • Administer labels ▼

    Can edit or delete labels created by another user.

  • Check in ▼

    Can check in items and revise any committed changeset comments. Pending changes are committed at check-in.

    Consider adding these permissions to any manually added users or groups that contributes to the development of the team 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.
  • Check in other users' changes ▼

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

  • Check out ▼

    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.

    Consider adding these permissions to any manually added users or groups that contributes to the development of the team 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.
  • Label ▼

    Can label items.

  • Lock ▼

    Can lock and unlock folders or files.

  • Manage branch ▼

    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 ▼

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

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

    Can merge changes into this path.

    Consider adding this permission to any manually added users or groups that contribute to the development of the team project and that must be able to merge source files, unless the team project is under more restrictive development practices.
  • Read ▼

    Can read the contents of a file or folder. If a user has Read permissions for a folder, the user can see the contents of the folder and the properties of the files in it, even if the user does not have permission to open the files.

  • Revise other users' changes ▼

    Can edit the comments on checked-in files, even if another user checked in the file.

    Consider adding this permission to any manually added users or groups that are responsible for supervising or monitoring the team project and that might or must change the comments on checked-in files, even if another user checked in the file.
  • Undo other users' changes ▼

    Can undo a pending change made by another user.

    Consider adding this permission to any manually added users or groups that are responsible for supervising or monitoring the team project and that might or must change the comments on checked-in files, even if another user checked in the file.
  • Unlock other users' changes ▼

    Can unlock files locked by other users.

    Consider adding this permission to any manually added users or groups that are responsible for supervising or monitoring the team project and that might or must change the comments on checked-in files, even if another user checked in the file.

To learn more, see Restrict access.

Area path permissions (object-level)

You manage the security of each area path from the web portal or using the TFSSecurity command-line tool. Area permissions grant or restrict access to create and manage area paths as well as create and modify work items defined under area paths.

Members of the Project Administrators group are automatically granted permissions to manage area paths for a team project. Consider granting team administrators or team leads permissions to create, edit, or delete area nodes.

  • Create child nodes ▼

    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.

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

    Users who have both this permission and the Edit this node permission for another node can delete area nodes and reclassify existing work items from the deleted node. If the deleted node has child nodes, those nodes are also deleted.

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

    Can set permissions for this node and rename area nodes.

    Consider adding this permission to any manually added users or groups that may need to delete, add, or rename area nodes.
  • Edit work items in this node ▼

    Can edit work items in this area node.

    Consider adding this permission to any manually added users or groups that may need to edit work items under the area node.
  • Manage test plans ▼

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

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

    Can create and delete test suites, add and remove test cases from test suites, change test configurations associated with test suites, and modify suite hierarchy (move a test suite).

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

    Can view the security settings for this node.

  • View work items in this node ▼

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

    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.

Iterations permissions (object-level)

Multiple teams may contribute to a team project. When that's the case, you can set up teams that are associated with an area. Permissions for the team's work items are assigned by assigning permissions to the area. There are other team settings that configure the team's agile planning tools.

To learn more, see Set permissions to restrict access to work items.

You manage the security of each iteration path from the web portal or using the TFSSecurity command-line tool. Members of the Project Administrators group are automatically granted these permissions for each iteration defined for a team project. Consider granting team administrators, scrum masters, or team leads permissions to create, edit, or delete iteration nodes.

  • Create child nodes ▼

    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.

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

    Users who have both this permission and the Edit this node permission for another node can delete iteration nodes and reclassify existing work items from the deleted node. If the deleted node has child nodes, those nodes are also deleted.

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

    Can set permissions for this node and rename iteration nodes.

    Consider adding this permission to any manually added users or groups that might need to delete, add, or rename iteration nodes.
  • View permissions for this node ▼

    Can view the security settings for this node.

    Members of the Project Collection Valid Users, Project Valid Users, or any user or group that has View collection-level information or View project-level information can view permissions of any iteration node.

Work item query and folder permissions (object-level)

You manage query and query folder permissions through the web portal. Project Administors are granted all of these permissions. Contributors are granted Read permissions only. Consider granting the Contribute permissions to users or groups that require the ability to create and share work item queries for the team project.

  • Contribute ▼

    Can view and modify this query or query folder.

  • Delete ▼

    Can delete a query or query folder and its contents.

  • Manage permissions ▼

    Can manage the permissions for this query or query folder.

  • Read ▼

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

To learn more, see Set permissions on queries.

Plan permissions (object-level) (Team Services)

You manage plan permissions through the web portal. You manage permissions for each plan through it's Security dialog. Project Administors are granted all permissions to create, edit, and manage plans. Valid users are granted View (read-only) permissions.

NOTE

Feature availability: Plans is in preview and available only on Team Services. You access plans by installing the Plans Marketplace extension.

  • Delete ▼

    Can delete the selected plan.

  • Edit ▼

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

  • Manage ▼

    Can manage the permissions for the selected plan.

  • View ▼

    Can view the lists of plans, open and interact with a plan, but cannot modify the plan configuration or settings.

To learn more, see Set permissions on queries.

Work item tags

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

  • Create tag definition ▼

    Can create new tags and apply them to work items. Users who don't have this permission can only select from the existing set of tags for the team project.

    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 team 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 team project as part of the command syntax. Otherwise, your change will apply to the entire collection. Keep this in mind when changing or setting these permissions.
  • Delete tag definition ▼

    Can remove a tag from the list of available tags for that team project.

    This permissions does not appear in the UI. It can only be set by using the TFSSecurity command.

    There is also no UI to explicitly delete a tag. Instead, when a tag has not been in use for 3 days, the system automatically deletes it.

  • Enumerate tag definition ▼

    Can view a list of tags available for the work item within the 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.

    This permissions does not appear in the UI. It can only be set by using the TFSSecurity command.

    The View project-level information implicitly allows users to view existing tags.

  • Update tag definition ▼

    Can rename a tag by using the REST API.

    This permissions does not appear in the UI. It can only be set by using the TFSSecurity command.

To learn more about tags, see Add tags to work items to categorize and filter lists.

Release management permissions (object-level) (Team Services, TFS 2017)

Project Administrators and Release Administrators are granted all release management permissions. These permissions can be granted or denied in a hierarchical model at the team project level, for a specific release definition, or for a specific environment in a release definition. Within this hierarchy, permissions can be inherited from the parent or overridden.

In addition, you can assign approvers to specific steps within a release definition to ensure that the applications being deployed meet quality standards.

NOTE

If you are working with the Release Management client and server supported for TFS 2015, see Automate deployments with Release Management.

  • Administer release permissions ▼

    Can administer the release permissions for other users.

  • Create releases ▼

    Can create new releases.

  • Delete release definition ▼

    Can delete release definitions defined for the team project.

  • Delete release environment ▼

    Can delete environment(s) defined for release definition(s).

  • Delete releases ▼

    Can delete releases for a release definition.

  • Edit release definition ▼

    Can save any changes to a release definition, including configuration variables, triggers, artifacts, and retention policy as well as configuration within an environment of the release definition. To make changes to a specific environment in a release definition, the user also needs the Edit release environment permission.

  • Edit release environment ▼

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

  • Manage deployments ▼

    Can initiate a direct deployment of a release to an environment. This permission is only for direct deployments that are manually initiated by selecting the Deploy action in a release. If the condition on an environment is set to any type of automatic deployment, the system automatically initiates deployment without checking the permission of the user that created the release.

  • Manage release approvers ▼

    Can add or edit approvers for environment(s) in release definition(s). This permissions also controls whether a user can edit the approvers inside the environment of a specific release instance.

  • Manage releases ▼

    Can edit the configuration in releases. To edit the configuration of a specific environment in a release instance, the user also needs Edit release environment permission.

  • View release definition ▼

    Can view the release definitions that have been created for the team project.

  • View releases ▼

    Can view releases belonging to release definition(s) defined for the team project.

To learn more, see Release definition security, Environment security and Approvals and approvers.

Alert permissions

There are no UI permissions associated with managing email notifications or alerts. Instead, they can be managed using the TFSSecurity command line tool.

By default:

  • Members of the team project level Contributors group can subscribe to alerts for themselves.
  • Members of the Project Collection Administrators group, or users who have the Edit collection-level information can set alerts in that collection for others or for a team.
  • Members of the Project Administrators group, or users who have the Edit project-level information can set alerts in that team project for others or for a team.

Lab Management permissions (TFS 2015, TFS 2013)

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

NOTE

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

  • Delete Environment and Virtual Machines ▼

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

  • Delete Lab Locations ▼

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

  • Edit Environment and Virtual Machines ▼

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

  • Environment Operations ▼

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

  • Import Virtual Machine ▼

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

  • Manage Child Permissions ▼

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

  • Manage Lab Locations ▼

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

  • Manage Permissions ▼

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

  • Manage Snapshots ▼

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

  • Pause Environment ▼

    Can pause an environment.

  • Start ▼

    Can start an environment.

  • Stop ▼

    Can stop an environment.

  • View Lab Resources ▼

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

  • Write Environment and Virtual Machines ▼

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

Large numbers of users

If you need to set permissions for large numbers of users, create a group in Windows, Active Directory, or Azure Active Directory, add these groups to Team Services or TFS through the collection-level or project-level security page, and add the same groups to grant access to additional resources.

Of course, you don't need to grant permissions for reports or the project portal if your team project doesn't use SQL Server Reporting Services or a SharePoint site.

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 team project level. You use the web portal administration context to set most permissions.

Permission level Web portal security pages Team Foundation Administration Console TFSSecurity command-line tool Tf command-line tool TFSLabConfig command-line tool
Server-level check mark check mark
Collection-level check mark check mark check mark
Team project and test level check mark check mark
Build level check mark check mark
Git repository check mark check mark
Team Foundation Version Control check mark check mark
Area level for work item tracking check mark check mark
Iteration level for work item tracking check mark check mark
Work item query check mark check mark
Work item tags check mark
Alerts check mark
Release Management check mark
Lab Management check mark

Inheritance

If a permission isn't directly allowed or denied for a user, then it may be inherited in two ways.

  • Users inherit permissions from the groups to which they belong. When a permission is allowed for a user directly or through membership in a group that has that permission, and it is denied, either directly or through group membership, the permission is denied.

    NOTE

    Members of Project Collection Administrators or Team Foundation Administrators retain any allowed permissions, even if they belong to other groups that deny those permissions.

  • Object-level permissions that are assigned for nodes of a hierarchy - areas, iterations, version control folders, work item query folders - are inherited down the hierarchy. That is, a user's permissions that are set at area-1 are inherited by area-1/sub-area-1, if the same permission is not explicitly allowed or denied for area-1/sub-area-1. If a permission is set explicitly for an object, like area-1/sub-area-1, then the parent node is not inheritied, regardless of whether it is denied or allowed. If it's not set, then the permissions for that node are inheritied from the closest ancestor that has the permission explicitly set.

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.

When assigning permissions

Do:

  • Use Windows groups when managing lots of users.
  • Consider granting the work item quyery folders Contribute permission to users or groups that require the ability to create and share work item queries for the team 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.

Don't:

  • Don’t add accounts to the team project Readers group that you’ve added to the Project Administrators group. Because the Readers group denies several permissions that the Project Administrators group allows, and deny takes precedence.
  • Don’t change the default assignments made to the valid users groups. 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.

Valid user groups

When you add accounts of users directly to a built-in 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 collection-level groups.

  • TeamProjectName\Project Valid Users: All members added to team 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 in TFS.

If you remove or deny the View instance-level information permission 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.

SQL Server reports and the project portal (TFS 2015)

For information about how to set permissions in Reporting Services and SharePoint Products for users in TFS, see Add administrators to TFS.