Share via

Azure Devops - Sudden Loss of Repos

Toby Walke 5 Reputation points
2026-04-20T11:21:26.5333333+00:00

I are experiencing a sudden loss of Azure Repos visibility for users who have valid Visual Studio Professional subscriptions.

Repos were previously accessible and no configuration changes were made.

Affected users include Project Administrators with correct access levels.

Azure Repos is enabled at project level.

I have been assigned a visual studio professional licence but when I am added to a clients Devops as a guest, the option to add my Visual Studio Pro licence is not available. This works on my own companies Devops but not on 3rd party clients.

Azure DevOps

2 answers

Sort by: Most helpful
  1. Siddhesh Desai 7,050 Reputation points Microsoft External Staff Moderator
    2026-04-20T11:59:53.4366667+00:00

    Hi @Toby Walke

    Thank you for reaching out to Microsoft Q&A.

    Why was Azure Repos access suddenly lost?

    Azure DevOps access to Repos is controlled by two independent layers:

    Permissions (Project Administrators, Contributors, etc.)

    Access Level / License (Stakeholder, Basic, Visual Studio Subscriber)

    Even if a user is a Project Administrator, they will not see Azure Repos unless they have Basic-level access or higher. If the access level silently drops to Stakeholder, the Repos hub disappears completely.

    Common reasons this happens without any configuration change:

    Visual Studio subscription expired, was reassigned, or identity mismatch occurred

    Organization exceeded free/paid Basic licenses, so Azure DevOps automatically downgraded inactive users to Stakeholder

    Guest users were re-evaluated during license reconciliation

    This explains the “sudden” loss of repo visibility.

    Why does your Visual Studio Professional license not appear in 3rd‑party DevOps orgs?

    This is the most important point:

    Visual Studio subscriptions are personal benefits, but they are detected per Azure DevOps organization based on identity and org policy.

    For guest users in external organizations:

    Azure DevOps does NOT always allow auto-detection of Visual Studio subscriptions

    The “Visual Studio Subscriber” option may not appear at all

    Guests default to Stakeholder access, even if they own a VS Pro license

    What needs to be done to restore Azure Repos access?

    Refer below points to resolve this issue or apply the workaround:

    1. Explicitly assign Basic access (recommended for guests)

    Guest users cannot always rely on VS subscription auto‑detection.

    An Organization Owner or Project Collection Administrator must assign:

    Basic (paid/free slot), or

    Basic + Test Plans (if required)

    This immediately restores Repos access.

    2. Do NOT rely on “Visual Studio Subscriber” for guest users

    That option is:

    Auto-detected only for member identities

    Often unavailable for B2B guest accounts

    This is expected behavior, not a bug.

    3. Verify access level for affected users

    Go to:

    Organization settings → Users → Access level

    Ensure users are not Stakeholder.

    Stakeholders cannot access Azure Repos in private projects, regardless of permissions.

    4. Check Basic license capacity

    If the organization:

    • Exceeded free Basic users, or
    • Has no paid Basic licenses

    Azure DevOps automatically downgrades users silently.

    Was this answer helpful?


  2. Q&A Assist
    2026-04-20T11:21:49.12+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    Azure DevOps access to Repos and other features depends on two things together:

    1. The user’s access level in the Azure DevOps organization (Stakeholder, Basic, Visual Studio subscription, etc.)
    2. The user’s permissions via security groups in that organization

    For Visual Studio subscribers and guest users, the key points from the documentation are:

    1. Visual Studio subscription detection is per organization and based on the identity used
      • Azure DevOps automatically recognizes Visual Studio subscribers based on the email address or alternate identity associated with the subscription when they sign in.
      • Administrators can assign the “Visual Studio Subscriber” access level, but the effective access is determined automatically by the subscription once the user signs in.
      • If the user doesn’t have a valid, active Visual Studio subscription (as seen from that identity), they can only work as a Stakeholder.
    2. What happens when the Visual Studio subscription is missing or expired
      • If a user’s Visual Studio subscription expires or is removed, Azure DevOps treats them as unlicensed for that benefit.
      • In Azure DevOps, that user can still work as a Stakeholder, or an admin can explicitly assign Basic or Basic + Test Plans access to restore feature access.
      • From the Visual Studio side, when a subscription is removed, access to Azure DevOps as a subscription benefit is lost.
    3. Why users suddenly lose access to Repos or features
      • A user can lose access to features (such as Repos) if:
        • The Visual Studio subscription expired or was removed.
        • The Azure subscription used for billing is no longer active or was removed from the organization.
        • The organization has more Basic users than are paid for; in that case, Azure DevOps automatically removes Basic access from users who haven’t signed in for the longest time, leaving them effectively at Stakeholder level.
      • In all these cases, the user may still appear in the organization and even be a Project Administrator, but their access level may no longer include Repos.
    4. Guest users in a client’s Azure DevOps organization
      • Visual Studio subscription benefits are tied to the subscription and the identity used to sign in.
      • The client’s Azure DevOps organization must:
        • Recognize the same identity (email/alternate identity) that is associated with the Visual Studio Professional subscription.
        • Assign an access level that allows use of the subscription (for example, “Visual Studio Subscriber” or at least not restrict the user to Stakeholder only).
      • If the client organization only assigns Stakeholder or doesn’t allow Visual Studio subscription access for guests, the Visual Studio Pro benefit won’t be applied there, even if it works in the home organization.
    5. How to restore or ensure access in the client organization For affected users in the client’s Azure DevOps organization:
      1. Verify the access level and subscription status
      • In the client’s Azure DevOps organization, an admin should go to Organization settings → Users and check:
        • The user’s access level (Stakeholder, Basic, Visual Studio subscription, etc.).
        • Whether the Visual Studio subscription is detected or marked invalid/expired.
      1. If the Visual Studio subscription is expired or not detected
      • The user can still work as a Stakeholder, but to restore Repos and other features, the client admin should:
        • Assign Basic or Basic + Test Plans access to that user in the client organization.
      • Once the Visual Studio subscription is renewed and the user signs in, Azure DevOps automatically restores subscription-based access.
      1. If the Visual Studio subscription was removed
      • From the Visual Studio side, removal of the subscription means Azure DevOps access as a benefit is lost.
      • In that case, the client organization must license the user directly (Basic or Basic + Test Plans) if continued access is required.
    6. Group rules and multiple access sources
      • If the client organization uses group rules, access level is determined by the highest access available across:
        • Group rules (Basic, Basic + Test Plans, Stakeholder)
        • Visual Studio subscription detection
      • If a group rule only grants Stakeholder and the Visual Studio subscription is not detected or is invalid, the user will effectively be Stakeholder and lose Repos access.

    In summary, the behavior described is consistent with:

    • Visual Studio subscription not being detected or being expired/removed for the identity used in the client’s Azure DevOps organization, or
    • The client organization only granting Stakeholder (or insufficient) access to guest users.

    The practical remediation for the client’s Azure DevOps admin is:

    • Confirm that the guest user signs in with the identity that has the Visual Studio Pro subscription.
    • In Organization settings → Users, verify whether the subscription is detected and not marked invalid.
    • If the subscription is not available or not detected, explicitly assign Basic (or Basic + Test Plans) access to restore Repos visibility.

    References:

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.