About security roles

5 minutes to read

In this article

VSTS | TFS 2018 | TFS 2017 | TFS 2015

While the majority of features and functional tasks are managed by [individual permissions](about-permissions.md), there are several artifacts and features that the system manages through role-based permissions. You can add users or groups to a role. Each role determines the set of operations that the user can perform as described in the following sections.

Many role-based permissions can be set for all artifacts of a specific type in a team project, or for the project or collection and then selectively inherited for a specific artifact. Role memberships for individual items automatically inherit those set for the project or collection. If required, you can turn off Inheritance for a specific artifact.

Can view the pool as well as agents. You typically add operators to this role that are responsible for monitoring the agents and their health.

Service Account

Can use the pool to create an agent queue in a team project. If you follow the guidelines for creating new pools and queues, you typically do not have to add any members to this role.

Administrator

Can register or unregister agents from the pool and manage membership for all pools, as well as view and create pools. They can also use the agent pool when creating an agent queue in a team project. The system automatically adds the user that created the pool to the Administrator role for that pool.

Can manage membership of all other roles for the service endpoint as well as use the endpoint to author build or release definitions. The system automatically adds the user that created the service endpoint to the Administrator role for that pool.

Marketplace extensions

The Manager role is the only role used to manage the security of Marketplace extensions. Members of the Manager role can install extensions and respond to requests for extensions to be installed.

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.

Create and manage team alerts Can add and modify alerts so that the team can receive email notifications as changes occur to work items, code reviews, source control files, and builds. For details, see Manage team alerts.

Select team area paths Can select the default area path(s) associated with the team. These settings affect a number of Agile tools available to the team. For details, see [Set team defaults](../work/scale/set-team-defaults.md).

Select team sprints
Can select the default area path(s) associated with the team. These settings affect a number of Agile tools available to the team. For details, see Set team defaults.

Configure team backlogs Can choose which backlog levels are active for a team. For example, a feature team may choose to show only the product backlog and a management team may choose to show only the feature and epic backlogs. For details, see Select backlog levels for your team.

Customize the Kanban board Can fully customize the team's Kanban boards associate with the product and portfolio backlogs. This includes the following elements:

Manage team dashboards Can add, configure, and manage permissions for team dashboards. For details, see Add and manage dashboards.

Set working days off Sprint planning and tracking tools automatically consider days off when calculating capacity and sprint burndown. Team admins can choose which days are non-working days through the team's Settings dialog. For details, see Set working days.