View permissions and effective access

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

This article shows how to view permissions and check effective access for users and groups at the organization, project, and repository (or other object) levels. It explains permission states (Allow, Deny, Inherit), how inheritance and group membership affect effective permissions, and steps to troubleshoot common access issues.

What you'll learn:

• Where to view permission assignments in the web portal.
• How to check effective permissions for a user or group.
• Common reasons permissions don't have the expected effect (inheritance, denies, Stakeholder access, Microsoft Entra ID group mapping).

Quick steps:

1. Open Organization settings or Project settings > Security (or Permissions).
2. Select the object (project, repository, or group) and view assigned permissions.
3. Use the Users/Groups or Effective Permissions UI to inspect effective access.
4. If needed, examine group memberships and deny rules that override allows.

Permission model basics

Permissions in Azure DevOps use three assignment states:

• Allow—explicitly grants a permission.
• Deny—explicitly denies a permission and overrides Allow.
• Inherit — no explicit assignment at this level; the permission is inherited from parent scopes or group membership.

Effective permissions are computed by evaluating assignments across:

• The object itself (project, repo, area path, etc.)
• Parent scopes (collection, organization, project)
• Group memberships (built-in groups, custom groups, Microsoft Entra ID groups)
• Explicit Deny assignments (take precedence)

What "effective" permissions means:

Effective permissions are the net access a user or group actually has on an object after Azure DevOps evaluates every relevant permission assignment. The system combines explicit Allow and Deny assignments across the object, parent scopes, and all group memberships; explicit Deny entries take priority. In practice, "effective permissions" show the final result (what someone can actually do), not every individual assignment that contributed to that result.

For a deep dive on permission resolution and inheritance, see About permissions, Permission states.

Where to view permissions

You can view permissions at multiple places in the web portal depending on the object:

• Organization or collection level: Organization settings > Security (or Organization settings > Permissions).
• Project level: Project settings > Permissions (or Project settings > Security in older UIs).
• Repository, pipeline, board, or other resource: Open the resource, then Settings or Security (for example, Repos > select repository > Security).

The Security/Permissions page shows assigned groups and users and a permission matrix you can filter by user or group.

Check effective permissions (UI)

Check effective permissions (command line / REST)

If you prefer automation, use the REST API to read ACLs or the Azure DevOps CLI/PowerShell modules to script permission checks. Look up the security namespace for the resource and evaluate ACL bits to compute effective access.

Common scenarios and troubleshooting

• Deny overrides Allow: An explicit Deny on any scope wins. Check for denies on higher or lower scopes and across group memberships.
• Membership in multiple groups: Effective permissions combine group assignments; a Deny in any group applies.
• Inheritance from parent scopes: If a permission is Inherit at the current level, check parent scopes for assignments.
• Microsoft Entra ID group mapping: If users are added through Microsoft Entra groups, ensure the correct group is synced to Azure DevOps and that the group's membership is what you expect.
• Stakeholder access limits: Users with Stakeholder access have limited feature availability regardless of permission assignments—verify access level if a user can't perform an action.
• Dynamic or temporary access: Some policies (like conditional access) or external provisioning might affect sign-in/access—check Microsoft Entra conditional access policies if sign-in fails.

Quick troubleshooting checklist

1. Confirm the user account being used to sign in (matches the identity shown in Azure DevOps).
2. Inspect the user's direct and indirect group memberships.
3. Search for any explicit Deny assignments at the object and parent scopes.
4. Check the user's access level (Stakeholder vs Basic) and licensing limits.
5. If you're using Microsoft Entra groups, confirm group sync and membership.
6. If needed, use REST/CLI to list ACLs for the resource and evaluate programmatically.

Audit and history

Use the audit logs (Organization settings > Audit logs) to track changes to security groups, permission assignments, and membership changes if your organization has auditing enabled. Audit events can help trace when a permission or membership was changed.

Useful links and tools

• About permissions and security groups
• Set object-level permissions
• Permissions lookup guide
• Manage users and groups

Next step

Related content

• Security groups, service accounts, and permissions reference
• Manage and configure team tools
• Stakeholder access quick reference