one of our developers is having problems accessing our TFS repository.

I tried to follow this, but there seems to be a higher-level issue related to the two accounts I have for DevOps / Visual Studio / Microsoft. I think there are some wires crossed because on some forms I get can't accees, on others I am not seeing the fields to modify for the permissions, which may be that one account has permissions and the other doesn't or something simiar.

At this point, I am amazed any of us can check in code.

regards,

Harvey

Use a structured permissions and access check in Azure DevOps to isolate the problem.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.

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:

• Troubleshoot access and permission issues
• Troubleshoot connecting to a project