Recommended Free Tools
Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
Azure DevOps access has three separate layers: access determines whether someone can connect to an organization or project; an access level unlocks product features; and permissions authorize specific actions on projects and resources. For a typical developer, start with Basic access and the project’s Contributors group. Use Stakeholder for limited business participation, Basic + Test Plans for full Test Plans use, and administrator groups only for people who actually administer resources.
This guide covers Azure DevOps Services and Azure DevOps Server 2022. Licensing, billing, identity integration, and some interface details differ between them.
Access level is not the same as permission
Think of the model as three questions:
- Can the person connect? The account must have access to the relevant Azure DevOps organization or Server collection and, where applicable, the project.
- Which features are available? The access level—such as Stakeholder, Basic, or Basic + Test Plans—controls feature availability.
- What can the person do here? Permissions, usually granted through security-group membership, control actions such as editing work items, pushing to a repository, queueing a pipeline, or managing an environment.
These layers work together, but they are not interchangeable. A Basic user may still lack permission to push to a particular repository. A Stakeholder may be able to update selected work items but cannot use Azure Repos as a code contributor. A user with a Test Plans entitlement may still need project permissions to work with a particular test resource. See Microsoft’s organization management overview and permissions overview.
Free tools Windows power users keep installed
One-click scans. No signup required.
Choose an access level for the work
The table summarizes the usual choice. Feature availability can vary by project type, platform, subscription entitlement, and resource permissions; “available” does not mean every action is automatically authorized.
#1 Best Overall
| Access level or entitlement | Typical user | What it is for | Important limitation or licensing signal |
|---|---|---|---|
| Stakeholder | Business sponsor, manager, customer, occasional reviewer | Selected Boards and collaboration activities, including some work-item actions | Free for unlimited users in Azure DevOps Services, but limited. No Azure Repos contribution workflow or Test Plans web portal. Pipeline access is also limited, not a full developer workflow. |
| Basic | Developer, product owner, Scrum master, project contributor | Most day-to-day Azure Boards, Repos, Pipelines, and Artifacts use | In Azure DevOps Services, the first five Basic users are free; additional Basic users are paid. Basic does not grant every project or resource permission. |
| Basic + Test Plans | Manual tester, QA engineer, test manager | Basic features plus full Azure Test Plans use | Paid in Azure DevOps Services, with a documented 30-day trial. Eligible Visual Studio subscriptions may include the corresponding benefit. |
| Visual Studio subscriber | User with a qualifying subscription | Azure DevOps benefits associated with the subscription tier | Qualifying subscriptions documented by Microsoft include Professional, Enterprise, Test Professional, and MSDN Platforms. Benefits differ by subscription; verify the current terms. |
| GitHub Enterprise entitlement | User associated with a GitHub Enterprise license | Recognized Azure DevOps entitlement | Microsoft says associated users receive Basic access even if Stakeholder was manually selected. This does not mean every GitHub plan provides this entitlement. |
For current entitlement details, consult Microsoft’s access-level documentation and its Stakeholder access guide.
When Stakeholder is appropriate
Choose Stakeholder when someone needs limited participation—for example, reviewing progress or working with selected work items—but does not need to contribute code or use the Test Plans portal. It is not simply “read-only”: Stakeholders can perform certain work-item and collaboration actions, subject to the project and permissions. Capabilities also differ between public and private projects.
Do not assign Stakeholder to a developer who needs Azure Repos. Also check for entitlement overrides: a qualifying Visual Studio subscription or GitHub Enterprise license can result in a higher effective access level when the person signs in. See Microsoft’s user access guidance.
When Basic or Basic + Test Plans is appropriate
Basic is the usual starting point for someone doing normal development, work tracking, pipeline, or artifact work. Add the person to an appropriate project group as well; assigning Basic alone does not make them a project administrator or grant access to every repository and pipeline.
Choose Basic + Test Plans when the person needs the full Azure Test Plans web experience, such as creating or managing test plans, suites, cases, and runs. Stakeholder access does not unlock that portal. Microsoft’s Test Plans permissions and licensing guidance explains the requirements. Check whether an eligible Visual Studio subscription already covers the user’s need before assigning a separate paid level.
Use groups to grant permissions
Azure DevOps permissions are commonly managed through security groups. Groups make onboarding and reviews easier than maintaining many individual assignments. Common project groups include:
- Readers: a starting point for people who need visibility without broad modification rights. A particular resource can still have its own access rules.
- Contributors: the normal group for day-to-day project work. Members typically need read/write access to work tracking, repositories, pipelines, and related project features, within the permissions configured for those resources.
- Project Administrators: people who manage project resources and settings. Do not use this group as a catch-all for contributors.
- Project Collection Administrators: highly privileged administrators with authority across the organization or Server collection. Keep membership very small.
- Custom groups: useful for focused roles, such as release managers, testers, auditors, or a role shared across selected projects.
Service identities should not automatically be treated like human users. Use the appropriate service-account groups and grant only the resource permissions needed for the workload. Microsoft’s permissions reference describes default group permissions; check it rather than assuming a group grants the same rights everywhere.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
| Role | Typical access level | Typical group or approach |
|---|---|---|
| Executive or customer reviewing progress | Stakeholder, if its limits fit | Readers, or another project group if specific work-item actions are needed |
| Developer or routine project contributor | Basic | Contributors, plus narrowly scoped resource permissions where needed |
| Manual tester using full Test Plans | Basic + Test Plans or eligible subscription | Contributors or a focused test group, with access to relevant test resources |
| Project administrator | Appropriate licensed access | Project Administrators |
| Organization or collection administrator | Appropriate licensed access | Project Collection Administrators; restrict membership |
| Build or automation identity | Depends on workload and platform | Service identity and specific pipeline/resource roles |
Permissions have scopes and inheritance
A user may have project access but not access to every object in it. Permissions can be scoped at the organization or collection, project, team, repository, branch, pipeline, agent pool, variable group, service connection, environment, area path, iteration path, shared query, and other resource levels. For example, a Contributor may be able to view a project but not push to a protected branch, use a service connection, or deploy to a restricted environment.
Permission screens can show Allow, Deny, inherited states, system states, or Not set. Effective access is calculated from the relevant assignments, group memberships, inheritance, access level, and resource-specific rules. Do not reduce this to “Deny always wins” or assume that adding another group will fix it. Inspect the permission for the exact action and object. Microsoft’s guide to viewing permissions shows how to examine effective permissions.
Assign and inspect access in the portal
Labels can vary between Azure DevOps Services and Server versions and between settings pages. The following paths reflect Microsoft’s documented organization and project settings areas.
Inspect a user’s organization access
- Open the Azure DevOps organization.
- Select Organization settings, then open the user or access-management area.
- Inspect the user’s access level, entitlement source, and group memberships.
Inspect project or resource permissions
- Open the project and select Project settings.
- Open Permissions or the relevant resource’s Security page.
- Select the group or user, then review the permissions and inheritance for the failed action.
- For a repository, pipeline, environment, or other object-specific issue, inspect that exact resource rather than stopping at project settings.
Set the default access level for new users in Azure DevOps Services
- Open Organization settings and select Billing.
- Find Default access level for new users, choose Stakeholder or Basic, and save.
Users added directly to projects generally receive Stakeholder by default unless the organization default or a group rule supplies another level. Group rules take precedence over the default. Use Microsoft Entra groups for broad role-based access and Azure DevOps project groups for project-specific permissions; document which group grants what and remove conflicting direct assignments. See Microsoft’s billing and access assignment instructions and permission inspection guide.
Automate user and group assignment
For Azure DevOps Services, the Azure DevOps CLI can add a user with an access level. First configure the CLI and authenticate with an identity that has the necessary organization administration rights. Set the organization context as appropriate for your environment; the command is not a replacement for project or resource permission assignments.
az devops user add
--email-id [email protected]
--license-type stakeholder
--output tableTo list security groups:
az devops security group listTo add a member to a project security group, obtain the correct group ID and member identity for your organization, then use:
az devops security group membership
--group-id <security-group-id>
--member-id [email protected]Microsoft documents these examples in its add-organization-users guidance. For integrations, the User Entitlement – Add REST API is another option.
Keep the operations distinct in scripts and change records: adding someone to the organization, assigning an access level, adding them to a project, adding them to a security group, and granting a resource-specific permission are separate tasks. Validate the resulting entitlement and permissions after automation, especially when group rules or subscription entitlements are involved. Azure DevOps Server has different operational and licensing considerations; do not assume every Services workflow applies unchanged.
Troubleshoot the failed action, not the person
Before changing access, write down exactly what the user cannot do and on which resource. “Cannot access Azure DevOps” is too broad to diagnose. Use this sequence:
- Identify the action. Is the user unable to see a project, see a repository, clone, push, queue a pipeline, approve a deployment, edit a work item, change its Area Path, or create a test run? These are controlled by different layers.
- Check the access level. A missing feature may require Basic or Basic + Test Plans, not another permission. Verify Stakeholder, Basic, Test Plans, Visual Studio subscriber, or GitHub Enterprise entitlement as applicable.
- Check group membership. Review direct and inherited membership in Readers, Contributors, Project Administrators, custom groups, and any relevant organization or collection group.
- Inspect the exact resource. Check the repository, branch, pipeline, environment, service connection, agent pool, area path, iteration path, query, or test resource involved.
- Review effective permission and inheritance. Look for explicit or inherited assignments and not-set states. Avoid solving a narrow access problem by granting broad administrator rights.
- Check identity synchronization. If membership comes through Microsoft Entra ID, changes may not show immediately. Sign out and back in or trigger a refresh so Azure DevOps reevaluates membership and inherited permissions.
- Check entitlement expiration and source. An expired Visual Studio subscription or GitHub Enterprise entitlement can reduce effective access. Also look for group rules or direct assignments that explain an unexpected level.
- Check organization and billing state. Confirm the user is in the intended organization, has an active identity, and has the required paid access if applicable. Microsoft’s permissions troubleshooting guide and billing FAQ cover additional cases.
A few common patterns make the diagnosis clearer:
- Feature is missing: verify access level and subscription entitlement first.
- Project is visible but a repository is not: inspect repository access and identity/group membership.
- Resource is visible but an action is blocked: inspect the permission for that action on the object, branch, or pipeline.
- Access changed without an obvious edit: check group rules, nested or synchronized group membership, subscription status, and GitHub Enterprise association.
- Unexpected charge: review paid access assignments and inactive users. Remove users who no longer need access or downgrade them to Stakeholder where its limits are suitable.
Billing and Azure DevOps Server differences
Azure DevOps Services: Microsoft’s current documentation describes Stakeholder as free for unlimited users, Basic as free for the first five users and paid beyond that, and Basic + Test Plans as paid with a 30-day trial. Eligible Visual Studio subscriptions and GitHub Enterprise entitlements can affect what access level is provided. Removing a user or assigning free Stakeholder access can stop paid access charges under the documented billing model; verify your current Azure billing details and entitlement source before making changes.
Azure DevOps Server: This is an on-premises product with a different licensing model. Access may involve Azure DevOps Server CALs, Visual Studio subscription benefits, or monthly access options in documented scenarios. Do not apply the Azure DevOps Services five-free-Basic-user allowance or cloud billing instructions automatically to Server. See Microsoft’s Azure DevOps Server access and licensing page.
Public and private projects can also differ in Stakeholder capabilities. Microsoft documentation says existing public projects are scheduled to convert to private beginning in 2027; that is a future policy, not a change already completed as of September 23, 2026. Check the current Stakeholder documentation for updates.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchQuick Recap
Safer access-management practices
- Assign permissions to groups where possible, and use Microsoft Entra groups for broad organizational roles and Azure DevOps groups for project-specific roles.
- Keep Project Collection Administrators membership exceptionally small; reserve Project Administrators for actual project administration.
- Grant narrowly scoped rights to repositories, branches, pipelines, service connections, environments, and agent pools rather than assuming project membership is sufficient.
- Document the purpose and owner of elevated access, group rules, and direct exceptions.
- Review inactive accounts, paid access, subscription expiration, and entitlement sources regularly.
- After a permission change, test the exact action with a non-administrator account. Administrators may not see the same restrictions as ordinary users.
- Use identity lifecycle and governance controls in Microsoft Entra ID where appropriate. Entra controls complement Azure DevOps permissions; buying an identity product does not automatically grant Azure DevOps resource access.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
