Azure DevOps access levels
What they are
An Azure DevOps access level controls which web-portal features a user can use. The main levels are Stakeholder, Basic, and Basic + Test Plans. Stakeholder has limited access for private projects; Basic covers most day-to-day Azure Boards, Repos, Pipelines, and Artifacts work.
Why they exist
Access levels provide a feature and licensing boundary. They complement, rather than replace, security permissions: a person needs a suitable access level and appropriate group or object permissions for the task.
Not the same as
- azure-devops-security-groups — groups and permissions decide whether an identity may perform a particular action; access levels decide which portal features are available.
- GitHub outside collaborator — an outside collaborator is a person with repository access without ordinary organization membership. GitHub assigns repository roles such as Read, Triage, Write, Maintain, or Admin; it does not use Azure DevOps Stakeholder/Basic levels.
- rbac — neither Azure DevOps access levels nor its security groups grant permission to deploy into an Azure subscription. A service-connection identity needs Azure RBAC separately.
Decision rule
For an occasional private-project participant, assess whether Stakeholder has the required feature set. For a regular contributor, assign Basic and the least capable Azure DevOps security group that permits the work. For an external GitHub contributor, grant the minimum repository role and remove it at the end of the engagement.
Operational failure mode
Changing a user from Readers to Contributors might not solve an inaccessible feature if their access level remains Stakeholder. Conversely, upgrading to Basic does not override an explicit Azure DevOps permission Deny.
Related
azure-devops-security-groups · security-group · service-connection · github · devops-platform-authentication
Sources: Azure DevOps access levels · GitHub repository roles