Use a structured permissions and access check in Azure DevOps to isolate the problem.
- Confirm the developer’s identity and sign-in
- Ensure the developer signs in with the correct UPN (for example,
******@contoso.com) and not an alias. Alias vs. UPN confusion can cause 401/Not Authorized errors. - If the organization is backed by Microsoft Entra ID and the user is a guest, verify that the B2B invitation has been accepted. If it shows as “Pending acceptance,” resend the invitation and have it accepted before retrying access.
- Ensure the developer signs in with the correct UPN (for example,
- Verify the user is in the Azure DevOps organization and project
- In Azure DevOps, go to Organization settings → Users and confirm the user appears there with the correct identity.
- If the user can reach
https://dev.azure.com/{orgName}but not a specific project (https://dev.azure.com/{orgName}/{projectName}) or repo, this indicates insufficient project-level permissions.
- Check access level and subscription status
- In Organization settings → Users, verify the user’s Access level is at least Basic or equivalent (Visual Studio subscription / GitHub Enterprise) for code operations.
- If a Visual Studio or GitHub Enterprise license was used, confirm it has not expired. If it has, either renew it or temporarily assign Basic access.
- If the Azure subscription used for billing is inactive or removed, restore or relink billing so paid access levels remain valid.
- Confirm project and repo permissions
- In the target project, go to Project settings → Permissions → Users, select the developer, and review effective permissions.
- Ensure the user (directly or via groups such as Contributors) has at least Read and Contribute permissions on the repository and branch used for check-in.
- If the user recently had permissions changed, allow up to an hour for Microsoft Entra group membership and permission propagation, then have the user refresh/restart the client.
- Trace permissions to find the root cause
- In Project settings → Permissions → Users, select the user.
- For any permission that appears incorrect (for example, Contribute = Deny or Not set), select the information icon next to that permission to trace where it is granted or denied.
- Adjust the relevant group or direct assignment so the user inherits the correct permissions. Avoid explicit Deny unless necessary, as it overrides Allow.
- Check for special limiting conditions
- Confirm the user is not only in a limited-scope group such as Project-Scoped Users, which can restrict access.
- Verify the project or specific services (Repos, Boards, Pipelines) have not been disabled at the project or collection level.
- If the user lost partial access after changes, review recent group rule or custom rule changes that might restrict operations on work items or code.
- Validate after changes
- After updating access level and permissions, have the developer:
- Sign out and sign back in to Azure DevOps.
- Restart Visual Studio or other client and retry check-in.
- If 401 or permission errors persist on specific resources, re-check the resource-level permissions (repo, branch, pipeline, etc.) and ensure at least Read access is granted.
- After updating access level and permissions, have the developer:
If these steps do not resolve the issue, capture the exact error message (HTTP code or Azure DevOps error text) and re-run permission tracing on the specific feature (repo/branch or work item area) where the failure occurs.
References: