A practical deep-dive into Azure DevOps permission layers: Project Admin vs Organization Access Level, and how ‘Stakeholder’ can block repo creation.
tags: [“Azure DevOps”, “Git”, “Permissions”, “Security”, “Repos”, “Troubleshooting”]
The Problem
You open Azure DevOps, you are listed as a Project Administrator, you can manage almost everything in the project…
…but when you try to create a new Git repository, Azure DevOps blocks you with a message that effectively says:
You can’t create a repository because your access level is Stakeholder.
This feels contradictory at first—how can a project admin be blocked from creating a repository?
The answer is that Azure DevOps uses two separate control layers:
- Project-level permissions (groups like Project Administrators / Contributors)
- Organization-level access level (license) such as Stakeholder vs Basic
Even if you are an admin at the project level, your organization access level may still restrict what you can do.
Azure DevOps Has Two Different “Power” Layers
Layer 1: Project Permissions (What you can do inside a project)
Inside your project, permissions are usually controlled by groups like:
- Project Administrators
- Contributors
- Readers
- Build Administrators
- Project Valid Users
- (and the project’s default Team)
Being a Project Administrator is very powerful at the project scope—configuration, pipelines, boards, many security settings, and more.
Layer 2: Organization Access Level (Your license / entitlement)
At the organization scope, Azure DevOps assigns each user an access level, typically:
- Stakeholder
- Basic
- Visual Studio Subscriber (often treated as Basic+ depending on subscription)
- (Enterprise scenarios may have additional variations)
This access level is not “just a label”.
It is an entitlement that affects which product features you can use—even if you’re an admin inside the project.
✅ Key point:
Project permissions do not override organization access level limitations.
Why Stakeholder Can Block Repository Creation
A Stakeholder user is meant for limited participation (think: business stakeholders, reviewers, occasional access).
In many organizations, Stakeholder is intentionally restricted to avoid consuming paid seats.
So the repository creation flow checks:
- Are you allowed by project security settings?
- Do you have an access level that permits this operation?
If your user is Stakeholder, Azure DevOps may refuse certain Git/Repo operations depending on organizational policy and licensing constraints.
Result:
You appear as admin, but the platform still blocks repo creation because your entitlement is too limited.
The Most Common Fix: Change Access Level from Stakeholder to Basic
Step-by-step (Organization Admin required)
- Go to Organization settings
- Open Users
- Find your user account
- Change Access level from Stakeholder to:
- Basic, or
- Visual Studio Subscriber (if applicable)
- Save
After that, try creating a repository again.
✅ In most real-world cases, this resolves the issue immediately.
What If You Can’t Access “Organization settings → Users”?
If you cannot open Organization settings → Users, it usually means:
- You are not an Organization Administrator
- You only have permissions inside the project, not at the org level
In that case, you need an Organization Admin to update your access level.
What to request from your Org Admin
Ask them to:
- Change your access level from Stakeholder to Basic
- Or assign a Visual Studio subscription entitlement if that’s your organization standard
Additional Checks (Less Common, But Worth Verifying)
Even after switching to Basic, there are a few other settings that can still block repo creation.
1) Confirm Repos is enabled for the project
Azure DevOps projects can enable/disable services (Repos, Boards, Pipelines, etc.)
- Go to Project settings
- Open Overview
- Find Azure DevOps services
- Ensure Repos is Enabled
If Repos is disabled, no one can create repositories in that project regardless of access level.
2) Confirm “Create repository” permission is allowed
In rare cases, a security policy or customization may explicitly deny repo creation.
- Go to Project settings
- Open Repositories
- Select Security
- Choose your identity or group (e.g., Project Administrators)
- Ensure Create repository is set to Allow
If this is set to Deny or inherited from an org-level policy, it can override expectations.
Quick Diagnostic: Which Layer Is Blocking You?
Use this mental model:
- If Azure DevOps says something like “You are a Stakeholder” → it’s almost always Access Level / entitlement
- If it says “You do not have permission” → it’s usually project security settings
- If you can’t even see “Repos” → it may be service disabled
A practical shortcut
If the UI explicitly mentions Stakeholder, start at Organization settings → Users.
Best Practices for Organizations
If you manage an Azure DevOps organization, this issue appears frequently due to default policies.
Recommended approach
- Use Stakeholder for users who only need:
- read-only visibility
- collaboration on work items (Boards) at a basic level
- Assign Basic to developers who:
- need Git repos
- create pipelines
- manage code
- work actively in engineering tasks
Document your onboarding
Create a simple internal guide:
- “If you need to create repos/pipelines: request Basic”
- “Stakeholder is for view/review only”
This prevents repeated confusion and support requests.
Summary
If you are a Project Administrator but cannot create a repository and Azure DevOps says you’re a Stakeholder, that’s not a bug—it’s the platform working as designed.
- Project Admin controls project permissions
- Stakeholder vs Basic controls feature entitlement at the org level
- You need Basic (or VS Subscriber) to avoid repo creation restrictions
The most common fix
✅ Change your Organization Access Level from Stakeholder → Basic
Optional: Copy/Paste Message to Send to Your Org Admin
Hi! I’m a Project Administrator in Azure DevOps, but repo creation is blocked because my access level is Stakeholder.
Could you please update my user entitlement to Basic (or assign my Visual Studio subscription) in Organization settings → Users?
Thanks!
