Manage access to specific features
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Managing access to specific features in Azure DevOps can be crucial for maintaining the right balance of openness and security. Whether you're looking to grant or restrict access to certain functionalities for a group of users, understanding the flexibility beyond the standard permissions provided by built-in security groups is key.
If you're new to the permissions and groups landscape, see Get started with permissions, access, and security groups. This article covers the essentials of permission states and how they inherit.
Tip
The structure of your project in Azure DevOps plays a pivotal role in determining the granularity of permissions at an object level, such as repositories and area paths. This structure is the foundation that allows you to fine-tune access controls, enabling you to specifically delineate which areas are accessible or restricted. For more information, see About projects and scaling your organization.
Prerequisites
Category | Requirements |
---|---|
Permissions | Member of the Project Collection Administrators group. Organization owners are automatically members of this group. |
Use security groups
For optimal maintenance, we recommend using the default security groups or establishing custom security groups to manage permissions. The permission settings for the Project Administrators and Project Collection Administrators groups are fixed by design and can't be altered. However, you have the flexibility to modify permissions for all other groups.
Managing permissions for a few users individually might seem feasible, but custom security groups provide a more organized approach. They streamline the oversight of roles and their associated permissions, ensuring clarity and ease of management design and can't be altered. But, you have the flexibility to modify permissions for all other groups.
Delegate tasks to specific roles
As an administrator or organization owner, delegating administrative tasks to team members who oversee specific areas is a strategic approach. The primary built-in roles equipped with predefined permissions and role assignments include:
- Readers: Have read-only access to the project.
- Contributors: Can contribute to the project by adding or modifying content.
- Team Administrator: Manage team-related settings and permissions.
- Project Administrators: Have administrative rights over the project.
- Project Collection Administrators: Oversee the entire project collection and have the highest level of permissions.
These roles facilitate the distribution of responsibilities and streamline the management of project areas.
For for more information, see Default permissions and access and Change project collection-level permissions.
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 (Team Foundation Version Control (TFVC))
Manage repository and branches
Administer labels, Manage branch, and Manage permissions
See Set TFVC repository permissions.
Software architect (Git)
Manage repositories
Create repositories, Force push, and Manage permissions
See Set Git repository permissions
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 Change project-level permissions.
Process template manager (Inheritance process model)
Work tracking customization
Administer process permissions, Create new projects, Create process, Delete field from account, Delete process, Delete project, Edit process
See Change project collection-level permissions.
Process template manager (Hosted XML process model)
Work tracking customization
Edit collection-level information, See Change project collection-level permissions.
Project management (On-premises XML process model)
Work tracking customization
Edit project-level information, See Change project-level permissions.
Permissions manager
Manage permissions for a project, account, or collection
For a 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 request a change in permissions, See Request an increase in permission levels.
In addition to assigning permissions to individuals, you can manage permissions for various objects within Azure DevOps. These objects include:
These links provide detailed steps and guidelines for setting up and managing permissions effectively for the respective areas in Azure DevOps.
Limit user visibility
Warning
Consider the following limitations when using this preview feature:
- The limited visibility features described in this section apply only to interactions through the web portal. With the REST APIs or
azure devops
CLI commands, project members can access the restricted data. - Users in the limited group can only select users who are explicitly added to Azure DevOps and not users who have access through Microsoft Entra group membership.
- Guest users who are members in the limited group with default access in Microsoft Entra ID, can't search for users with the people picker.
Organizations and projects
By default, users added to an organization can view all organization and project information and settings. You can restrict specific users, such as Stakeholders, Microsoft Entra users, or member sof a particular security group, with the Limit user visibility and collaboration to specific projects preview feature for the organization. Once the feature gets turned on, any user or group that gets added to the Project-Scoped Users group is restricted in the following ways:
- Access is confined to only the projects to which they're explicitly added.
- Views displaying lists of users, projects, billing details, usage data, and more accessed through Organization settings are restricted.
- The set of people or groups that appear in people-picker search selections and the ability to @mention people is limited.
Identity search and selection
With Microsoft Entra ID, you can use people pickers to search for any user or group in your organization, not just the ones in your current project. People pickers support the following Azure DevOps functions:
- Selection of a user identity from a work tracking identity field such as Assigned To
- Selection of a user or group using @mention in a work item discussion or rich-text field, a pull request discussion, commit comments, or changeset or shelveset comments
- Selection of a user or group using @mention from a wiki page
As shown in the following image, start entering a user or security group name into a people picker box until you find a match.
Users and groups who are added to the Project-Scoped Users group can only see and select users and groups in the project they're connected to from a people picker.
Turn on the preview feature and add users to the security group
Do the following steps to turn on the preview feature and add users and group to the Project-Scoped Users group:
Turn on the Limit user visibility and collaboration to specific projects preview feature for the organization.
Add the users to your project as described in Add users to a project or team. Users added to a team are automatically added to the project and team group.
Open Organizations settings > Security > Permissions and choose Project-Scoped Users. Select the Members tab.
Add all users and groups that you want to scope to the project they're added to. For more information, see Set permissions at the project- or collection-level.
The Project-Scoped Users group only appears under the Permissions > Groups when the Limit user visibility and collaboration to specific projects preview feature is turned on.
All security groups in Azure DevOps are considered organization-level entities, even if they only have permissions for a specific project. This means that security groups get managed at the organization level.
From the web portal, the visibility of some security groups might be restricted based on the user's permissions. However, you can still discover the names of all security groups within an organization by using the azure devops CLI tool or the REST APIs. For more information, see Add and manage security groups.
Restrict access to view or modify objects
Azure DevOps is designed to allow all authorized users to view all defined objects within the system. However, you can tailor access to resources by setting the permission state to Deny. You can set permissions for members who belong to a custom security group or for individual users. For more information, see Request an increase in permission levels.
Area to restrict
Permissions to set to Deny
View or contribute to a repository
View, Contribute
See Set Git repository permissions or Set TFVC repository permissions.
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 pipelines
Edit build pipeline, View build pipeline
Edit release pipeline, View release pipeline
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 or select fields
For examples that illustrate how to restrict modification of work items or select fields, see Sample rule scenarios.