Jaa


Change permissions at the organization or collection-level

TFS 2017 | TFS 2015 | TFS 2013

Several permissions are set at the organization or collection level. You can grant these permissions by adding a user or group to the Project Collection Administrators group. Or, you can grant select collection-level permissions to a custom security group or to a user.

A project collection is the container for several projects that share resources. For more information about projects and project collections, see About projects and scaling your organization.

See the following articles for related information:

Note

All security groups are collection-level entities, even those groups that only have permissions to a specific project. From the web portal, visibility of some security groups may be limited based on user permissions. However, you can discover the names of all groups in an organization using the REST APIs. To learn more, see Add and manage security groups.

Collection-level permissions

The following table lists the permissions assigned at the organization or collection-level. All of these permissions, except for the Make requests on behalf of others permission, are granted to members of the Project Collection Administrators group. For a description of each permission, see Permissions and groups reference, Groups.

General

  • Alter trace settings
  • Create new projects
  • Delete team project
  • Edit instance-level information
  • View instance-level information

Service Account

  • Make requests on behalf of others
  • Trigger events
  • View system synchronization information

Boards

  • Delete field from organization or account

Repos (TFVC)

  • Administer shelved changes
  • Administer workspaces
  • Create a workspace

Pipelines

  • Administer build resource permissions
  • Manage build resources
  • Use build resources
  • View build resources Test Plans
  • Manage test controllers

Prerequisites

  • To manage permissions or groups at the organization or collection level, you must be a member of the Project Collection Administrators security group. If you created the organization or collection, you are automatically added as a member of this group. To get added to this group, you need to request permissions from a member of the Project Collection Administrators group. See Look up a project collection administrator.
  • If want to add security groups defined in Azure Active Directory or Active Directory, make sure those are first defined. To learn more, see Add AD/Azure AD users or groups to a built-in security group.

Note

Users granted Stakeholder access, won't be able to access select features even if granted permissions to those features. To learn more, see Permissions and access.

Add members to the Project Collection Administrators group

You can add users who've been added to a project, organization, or collection to the Project Collection Administrators group, or any other group at the organization or collection level. To add a custom security group, first create the group as described in Add or remove users or groups, manage security groups.

Here we show how to add a user to the built-in Project Collection Administrators group. The method is similar to adding an Azure Active Directory or Active Directory group.

  1. Open the web portal and choose the project where you want to add users or groups. To choose another project, see Switch project, repository, team.

  2. Choose the gear icon to open the administrative context.

    Open Project Settings, horizontal nav

  3. Choose Security, Project Administrators group, Members, and then Add.

    Project Settings>Security, Add member

  4. Enter the name of the user account into the text box. You can enter several identities into the text box, separated by commas. The system automatically searches for matches. Choose the match(es) that meets your choice.

    Add users and group dialog, TFS 2018 and earlier versions.

    Note

    Users that have limited access, such as Stakeholders, won't be able to access select features even if granted permissions to those features. To learn more, see Permissions and access.

  5. Choose Save changes. Choose the refresh icon to see the additions.

Change permissions for a group

You can change the project-level permissions for any project-level group. Each team added to a project is automatically added as a project-level group. To add security groups to a project, see Add or remove users or groups, manage security groups. To understand permission assignments and inheritance, see About permissions, Permission states.

  1. Open the Security page as described in the previous section, Add a user or group to the Project Collection Administrators group.

  2. From the Security page, choose the group whose permissions you want to change.

    For example, here we choose the Stakeholders Limited group, and change several permissions.

    Screenshot of Collection-level Prmissions for a selected group, current page.

  3. Choose Save changes.

Change permissions for a user

You can change the collection-level permissions for a specific user. To understand permission assignments and inheritance, see About permissions, Permission states.

  1. Open the Security page as described in the previous section, Add a user or group to the Project Administrators group.

  2. From the Security page, in the Filter users and groups text box, enter the name of the user whose permissions you want to change.

  3. Change change the assignment for one or more permissions.

    For example, here we change the Edit project-level information for Christie Church.

    Screenshot of selected user , change Edit project-level information permission level.

  4. Choose Save changes.

On-premises deployments

For on-premises deployments, see these additional articles:

If your on-premises deployment is integrated with a SharePoint product or SQL Server Reports, you'll need to manage membership for those products separately from their websites.

FAQs

Q: When do I need to add someone to the Project Collection Administrator role?

A: It varies. For most organizations that use Azure DevOps, Project Collection Administrators manage the collections that members of the Team Foundation Administrators group create. Members of the Project Collection Administrators group don't create the collections themselves. Project collection administrators also do many operations required to maintain the collection. Operations include creating team projects, adding users to groups, modifying the settings for the collection, and so on.

Q: What are the optimal permissions to administer a project collection across all of its components and dependencies?

A: Project collection administrators must be members of the following groups or have the following permissions:

  • Team Foundation Server: A member of the Project Collection Administrators group, or have the appropriate collection-level permissions set to Allow.

  • SharePoint Products: If the collection is configured with a site collection resource, then a member of the Site Collection Administrators group.

  • Reporting Services: If the collection is configured with reporting resources, then a member of the Team Foundation Content Manager group.

Q: I'm an admin, but I don't have permission to add a Project Collection Administrator. What do I need?

A: The following permissions are required:

  • You must be a Project Collection Administrator, or your View Server-Level Information and Edit Server-Level Information permissions must be set to Allow.

  • To add permissions for SharePoint Products, you must be a member of the Site Collection Administrators or Farm Administrators groups for SharePoint Products.

  • To add permissions for Reporting Services, you must be a member of the Content Managers or Team Foundation Content Managers groups for Reporting Services.

Important

To perform administrative tasks like creating project collections, your user requires administrative permissions. The service account that the Team Foundation Background Job Agent uses must have certain permissions granted to it. For more information, see Service accounts and dependencies in Team Foundation Server and Team Foundation Background Job Agent.

Next steps