Grant or restrict access to select features and functions

VSTS | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013

You can grant or restrict access to resources that you manage in Visual Studio Team Services (VSTS) or Team Foundation Server (TFS). Depending on your project needs, you may want to open up or close down access to a select set of features and for a select set of users. While the built-in security groups provide a standard set of permission assignments, you may need additional security requirements not met by these assignments.

If you are new to administrating permissions and groups, review About permissions and groups to learn about permission states and inheritance.

Use this topic to learn:

  • Recommended method for granting and restricting permissions
  • How to delegate tasks by assigning select permissions to specific roles
  • How to restrict access to view or modify objects
  • How to restrict modification of work items based on a user or group

Tip

Because you set many permissions at an object-level, such as repositories and area paths, how you structure your team project will determine the areas you can open up or close down.

For maintenance purposes, we recommend you use either the built-in security groups or custom security groups to manage permissions.

You can't change the permission settings for the Project Administrators group or the Project Collection Administrators group. This is by design. However, for all other groups, you can change the permissions.

If you manage a small number of users, then you may find changing individual permissions a valid option. However, custom security groups allows you to better track roles and permissions assigned to those roles.

Delegate tasks to specific roles

As an administrator or account owner, it's a good idea to delegate administrative tasks to those team members who lead or manage an area. Several of the main built-in roles which come with default permissions and role assignments are:

  • Readers
  • Contributors
  • Stakeholders (access role)
  • Team administrator role
  • Project Administrators
  • Project Collection Administrators

For a summary of permissions provided to the above roles, see Default permissions and access, or for the Project Collection Administrators, see Add administrators

To delegate tasks to other members within your organization, consider creating a custom security group and then granting permissions as indicated in the following table.

Role Tasks to perform Permissions to set to Allow
Development lead (Git) Manage branch policies Edit policies, Force push, and Manage permissions
See Set branch permissions.
Development lead (TFVC) Manage repository and branches Administer labels, Manage branch, and Manage permissions
See Set repository permissions for Git or TFVC.
Software architect (Git) Manage repositories Create repositories, Force push, and Manage permissions
See Set repository permissions for Git or TFVC.
Team administrators Add area paths for their team
Add shared queries for their team
Create child nodes, Delete this node, Edit this node
See Create child nodes, modify work items under an area path
Contribute, Delete, Manage permissions (for a query folder), See Set query permissions.
Contributors Add shared queries under a query folder, Contribute to dashboards Contribute, Delete (for a query folder), See Set query permissions
View, Edit, and Manage dashboards, See Set dashboard permissions.
Project or product manager Add area paths, iteration paths, and shared queries
Delete and restore work items, Move work items out of this project, Permanently delete work items
Edit project-level information, See Add administrators, set permissions at the project-level or project collection-level.
Process template manager (Inheritance process model) Work tracking customization Administer process permissions, Create new projects, Create process, Delete field from account, Delete process, Delete team project, Edit process
See Add administrators, set permissions at the project-level or project collection-level.
Process template manager (Hosted XML process model) Work tracking customization Edit collection-level information, See Add administrators, set permissions at the project-level or project collection-level.
Team project management (On-premises XML process model) Work tracking customization Edit project-level information, See Add administrators, set permissions at the project-level or project collection-level.
Permissions manager Manage permissions for a team project, account, or collection For a team project, Edit project-level information
For an account or collection, Edit instance-level (or collection-level) information
To understand the scope of these permissions, see Permission lookup guide. To grant permissions, See Add administrators, set permissions at the project-level or project collection-level.

You can also grant permissions to manage permissions for the following objects:

Restrict access to view or modify objects

VSTS and TFS are designed to enable all valid users to be able to view all objects defined in the system. You can restrict access to resources by setting the permission state to Deny. You can set permissions for members that belong to a custom security group or for an individual user. To learn more about how to set these types of permissions, see Change individual permissions, grant select access to specific functions.

Area to restrict
Permissions to set to Deny
View or contribute to a repository View, Contribute
See Set repository permissions for Git or TFVC.
View, create, or modify work items within an area path Edit work items in this node, View work items in this node
See Set permissions and access for work tracking, Modify work items under an area path.
View or update select build and release definitions Edit build definition, View build definition
Edit release definition, View release definition
You set these permissions at the object level. See Set build and release permissions.
Edit a dashboard View dashboards
See Set dashboard permissions.

Restrict modification of work items based on a user or group

For the Hosted XML process model and On-premises XML process model, you can customize work item types to support these restriction requests:

  • Restrict who can create or modify a work item
  • Restrict who can create specific work item types, such as Epics or Features

You achieve this by adding a rule to the work item type, usually within the WORKFLOW section. To learn more, see Add a rule to a work item type, Apply or ignore rules based on user or group.

Note

These restriction types aren't available for VSTS accounts and the Inheritance process model.

Try this next