Permission reference for Team Foundation Server

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

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

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

TFS version

New or changed permissions

TFS 2013.3

Manage test suites permission added, and Manage test plans permission re-scoped to manage only test plans. These permissions are set for an area path. Previously, it covered permission management of both test plans and test suites.

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

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

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

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

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.

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

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.

Group (prefix: ProjectName\)

Group-level permissions

Additional notes

Project Administrators

Can administer all aspects of the team project, although they can’t create projects.

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

Build Administrators

Can administer build resources and build permissions for the project. Members can manage test environments, create test runs, and manage builds.

Contributors

Can contribute fully to the project code base and work item tacking.

By default, the team group created when you create a team project is added to this group, and any user you add to the team will be a member of this group. In addition, any team you create for a team project will be added to this group by default, unless you choose a different group from the list.

Readers

Can view the project but not modify it.

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

TeamName

Inherit the same permissions assigned to the Contributors group. Can contribute fully to the project code base and work item tacking.

The default Team group is created when you create a team project, and by default is added to the Contributors group for the team project. Any new teams you create will also have a group created for them and added to the Contributors group.

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

TeamProjectCollectionName\Project Collection Administrators

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

TeamProjectCollectionName\Project Collection Build Service Accounts

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

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

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

Permission

Authorization

Allow

Explicitly grants users to perform the task associated with the specific permission. Allow is usually inherited from group membership. For users to access a task, the associated permission must be set to Allow or Inherited allow.

Deny

Explicitly prevents users from performing the task associated with the specific permission. Deny is usually inherited from group membership.

Inherited allow/Inherited deny

Allows or denies a user to perform the task associated with the permission based on the permission set for a group to which the user belongs.

Not set

Implicitly prevents users from performing the action associated with the permission.

Because the permission is neither explicitly set to Deny nor explicitly set to Allow, authorization for that permission can be inherited from other groups of which the user or group is a member.

By default, most permissions are not set to either Deny or Allow. The permissions are left Not set.

Permission states follow these precedence settings:

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

Exceptions to this rule are:

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

Source control folders for Team Foundation version control

Git repositories

Area and iteration nodes for work item tracking

Work item shared queries and query folders

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

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

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.

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.

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.

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

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

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

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.

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.

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

When you set Edit collection-level information to Allow through TWA, users can add or remove collection-level TFS groups and implicitly allows these users to modify version control permissions. To grant all these permissions at a command prompt, you must use the tf.exe Permission command to grant the AdminConfiguration and AdminConnections permissions, in addition to GENERIC_WRITE.

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:

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.

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:

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

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.

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.

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

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

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.

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.

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

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

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.

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.

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:

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.

Consider adding this permission to any manually added users or groups that might need to delete, add, or rename iteration 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 iteration node.

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

Permission name

TFSSecurity Action and tfperm

TFSSecurity Namespace

Description

Contributors

Build Administrators

Project Collection Build Service Accounts

Project Administrators (Note 1)

Administer labels

tf: LabelOther

VersionControlItems

Can edit or delete labels created by another user.

Check in (Note 2)

tf: Checkin

VersionControlItems

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

Check in other users' changes

tf: CheckinOther

VersionControlItems

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

Check out (Note 2)

tf: PendChange

VersionControlItems

Can check out and make a pending change to items in a folder. Examples of pending changes include adding, editing, renaming, deleting, undeleting, branching, and merging a file. Pending changes must be checked in, so users will also need the Check in permission to share their changes with the team.

Label

tf: Label

VersionControlItems

Can label items.

Lock

tf: Lock

VersionControlItems

Can lock and unlock folders or files.

Manage branch

tf: ManageBranch

VersionControlItems

Can convert any folder under that path into a branch, and also take the following actions on a branch: edit its properties, re-parent it, and convert it to a folder.Users who have this permission can branch this branch only if they also have the Merge permission for the target path. Users cannot create branches from a branch for which they do not have the Manage Branch permission.

Manage permissions (Note 3)

tf: AdminProjectRights

VersionControlItems

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

Merge (Note 4)

tf: Merge

VersionControlItems

Can merge changes into this path.

Read

tf: Read

VersionControlItems

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

Revise other users' changes (Note 5)

tf: ReviseOther

VersionControlItems

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

Undo other users' changes Merge (Note 5)

tf: UndoOther

VersionControlItems

Can undo a pending change made by another user.

Unlock other users' changes (Note 5)

tf: UnlockOther

VersionControlItems

Can unlock files locked by other users.

Notes:

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

Readers group is assigned view-only permissions: Read.

Consider adding these permissions to any manually added users or groups that contributes to the development of the project; any users who should be able to check in and check out changes, make a pending change to items in a folder, or revise any committed changeset comments.

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

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

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

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

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

Permission name

TFSSecurity Action

TFSSecurity Namespace

Description

Contributors

Build Administrators

Project Administrators (Note 1)

Administer (Note 2)

Administer

GitRepositories

Can rename the repository, add additional repositories, verify the database, and set permissions for the branch. Users who have this permission can delete the repository if they also have the Force permission.

At the branch level, can set permissions for the branch and delete the branch.

Branch Creation

CreateBranch

GitRepositories

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

Contribute

GenericContribute

GitRepositories

Can push their changes to the repository.

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

Note Management

ManageNote

GitRepositories

Can push and edit Git notes to the repository. They can also remove notes from items if they have the Force permission. See this topic for more details on notes.

Read

GenericRead

GitRepositories

Can clone, fetch, pull, and explore the contents of the repository, but cannot push any changes they make to the repository.

Rewrite and destroy history (force push)

ForcePush

GitRepositories

Can force an update, which can overwrite or discard commits from any user. Deleting commits changes the history. Without this permission, users cannot discard their own changes. Rewrite and destroy history is also required to delete a branch.

Because Rewrite and destroy history enables users to change the history or remove a commit from history, users who have this permission can delete a change and its history from the server. They can also modify the commit history of the server repository.

At the branch level, can rewrite and destroy history of the branch.

Tag Creation

CreateTag

GitRepositories

Can push tags to the repository, and can also edit or remove tags from items if they have the Force permission.

Notes:

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

Visual Studio Lab Management permissions are specific to virtual machines, environments, and other resources. In addition, the creator of an object in Lab Management is automatically granted all permissions on that object. You can set these permissions by using the TFSLabConfig permissions command-line tool.

By default, the project-level and collection level Readers groups have only View lab resources (Read) permissions.

Permission name

TFSLabConfigperm

Description

Contributors (Note 1)

Project Administrators

Project Collection Build Service

Team Foundation Administrators, Project Collection Administrators

Delete Environment and Virtual Machines

Delete

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

Delete Lab Locations

DeleteLocation

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

Edit Environment and Virtual Machines

Edit

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

Environment Operations

EnvironmentOps

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

Import Virtual Machine

Create

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

Manage Child Permissions

ManageChildPermissions

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

Manage Lab Locations

ManageLocation

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

Manage Permissions

ManagePermissions

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

Manage Snapshots

ManageSnapshots

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

Pause Environment

Pause

Can pause an environment.

Start

Start

Can start an environment.

Stop

Stop

Can stop an environment.

View Lab Resources

Read

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

Write Environment and Virtual Machines

Write

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

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.

Can initiate a release and specify which users can initiate a release from those release templates that they can view.

Consider adding: Users or groups that will initiate a release. With this permission, you can specify which users can initiate a release from those release templates that they can view.

Manage Security

Configure Apps > Release Template > Properties

Configure Paths > Release Paths

Can manage which groups have permissions to view, edit, or manage release templates or release paths.

Consider adding: Users or groups that will manage which groups have permissions to view, edit, or manage release templates or release paths. With this permission, creators of release templates and release paths can control who can view, edit, or release specific templates or paths.

Can Create Release Template

Configure Apps > Release Template

Can define release templates.

Without this permission, the New button on the Configure Apps > Release Template tab is hidden.

Consider adding: Users or groups that need to create, start, or approve a release.

Can Create Release Path

Configure Paths > Release Paths

Can define the stages, approval process, and security of release paths.

Without this permission, the New button on the Configure Paths > Release Paths tab is hidden.

Consider adding: Users or groups that need to manage the release configuration used in deploying applications.

Can Manage Environment

Configure Paths > Environments

Can define the stages that comprise a release path and the servers and security for each stage.

Without this permission, the Configure Paths > Environments tab is hidden.

Consider adding: Users or groups that need to manage the servers and environments used to define the release paths.

Can Manage Server

Configure Paths > Server

Can define the release paths for deploying applications in your system. This permission supports access to defining the servers use to deploy applications to test, stage, and production servers.

Without this permission, the Configure Paths > Server tab is hidden.

Consider adding: Users or groups that will define the release paths for deploying applications in your system. This permission supports access to defining the servers used to deploy applications to test, stage, and production servers.

Consider adding: Users or groups that will define custom tools or actions for deploying applications in your system. With this permission they can view, edit, and create actions and tools used in deploying applications.

Can Use Custom Tool in Actions and Components

Configure Apps > Component> Deployment

Configure Apps > Release Template > Component > Deployment

Can edit the Command and Arguments fields when No Tool is selected.

Without this permission, users cannot edit these fields.

Consider adding: Users or groups that will define release paths or release templates or who will initiate releases. This allows them to edit the Command and Arguments fields when No Tool is selected.

Edit Values and Target Servers

Configure Apps > Release Template

Can edit deployment sequence and configuration variables for specific releases or stages.

Without this permission, stage information is read-only.

Consider adding: Users or groups that will define release paths or release templates or who will initiate releases. This allows them to edit deployment sequence and configuration variables for specific releases or stages.

Edit Approvals and Environment

Configure Paths > Release Path > Stages

Can edit approvals and environments for a specific stage.

Without this permission, stage information is read-only.

Consider adding: Users or groups that will define release paths or release templates. This allows them to edit approvals and environments for a specific stage.Without this permission, stage information is read-only.

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

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

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

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.