DevOps Built-in Access Levels, Security Groups and AAD Groups


in large organizations it’s so important that not all the colleagues who are working together on a project to be able to release/ deploy the product in production environment.

There must be always a check list to get ready for deploying in production. Nowadays this check list is called continuous integration/deploy (CI/CD).

The check list before deploy the product on production environment

Therefore the project team try to grant permission according to the responsibilities and tasks or each colleagues to team. On of the tools which we can use to develop a project with the agile method is Azure DevOps.

There is also possible to assign built-in Access Level and Security Group to each member of team as explained in follows.

The users/ members in Azure DevOps always have an assigned DevOps Group and Access Level.

DevOps Built-in Access Level

Access Level defines the Azure DevOps Features that a user or group can use.

Access Levels Description
Basic Basic supports full access to all Azure DevOps Board features
Stakeholders Provides partial support for viewing and modifying work items but not using all features.
Visual Studio Subscriber Free access to a limited set of features.

DevOps built-in security Groups

Security Groups define what users of groups can do with each Azure DevOps features.

Azure DevOps has mainly two different level of built-in groups [Microsoft Doc]:

  • Collection-Level
  • Project-Level

The Team Administrator is the person who can grant permissions to specific features.


Your Text Here

Project-Level Security Groups

Each project contains the following built-in groups:

  • Build Administrator
  • Contributor
  • Project Administrators
  • Project Valid Users
  • Readers

<ProjectName> Team

DevOps Security Groups Description [Microsoft Doc]
Project readers Permission to view project information, the code base, work items, and other artifacts but not modify them.  
Project Contributors Permission to contribute fully to the project code base and work item tracking. They cannot manage or administrator resources.
Project Administrators Permission to administer all aspects of teams and project. Although they cannot create team projects.

Combination Matrix of the Access Level and Security Group in Project-Level

DevOps Security GroupsAccess Levels Description
Project ReadersStakeholder
Project Readers Basic
Project Readers Visual Studio subscriber
Project Contributors Stakeholder Managers or users who don’t actively contribute to the code base but want to check project status or provide direction, feedback, feature ideas, and business alignment to a team.
Project Contributors Basic Full-time workers who contribute to the code base or manage project.
Project Contributors Visual Studio subscriber Code base contribution
Project Administrators Stakeholder The users, who are tasked to managing project resources. If them also need to contribute to the code base, then the Basic Access Level must be assigned to them.
Project Administrators Basic Managing project resources + Code base contribution
Project Administrators Visual Studio subscriber Code base contribution

Combination Matrix of the Access Level and Security Group in Collection-Level

DevOps Security GroupsAccess Levels Description
Project Collection AdministratorsStakeholdersThe users, who are tasked with managing organization or collection resources and if they need to be contributed to the code base then they must be assigned to Basic Access Level.
Project Collection Administrators Basic
Project Collection Administrators Visual Studio Subscriber

Azure DevOps Levels

DevOps can be configured at different levels:

  • Organization/Collection
  • Project
  • Object

The focus of this document is Project-Level and object-Level.

Object-Level Groups

Managing the permission on Git branches.

Using Azure ADD Group in Azure DevOps

For managing the users the Azure DevOps can be connected to Azure AD. The AAD Groups can be used in Azure DevOps as well. But the Active directory Group hierarchy is not usable in Azure DevOps. It means the sub groups will not inherit the access level and permission group of their parent group.

Each AAD parent and sub group must be added separately to Azure DevOps and an Access Level and a Permission Group must be assigned to each one separately them.

The users which are assigned to the same AAD Group will have the same Access Level and Permission Group, which has been assigned to this AAD group in Azure DevOps.


Your Text Here

The Advantage is:

  • A newly added user to AAD Group can login to Azure DevOps and there is no need for additional configuration.


Default permissions and access for Azure DevOps

About user, team, project, and organization-level settings

Azure DevOps: Getting Started

Microsoft Azure DevOps Engineer: Provision Azure Resources

Permissions lookup guide for Azure DevOps

Published by parisamoosavinezhad

- Software Engineer - Software Architect - Software and database specialist - Cloud solution architect

%d bloggers like this: