How to fix Azure DevOps queue build permissions
Azure Pipelines will not let a user queue a run unless that user has permission to queue the target pipeline. BranchDeploy follows the same rule: it queues the configured pipeline as the current Azure DevOps user, so it cannot be used to bypass Azure DevOps security.
If a deployment works for an admin but fails for QA or delivery users, queue permissions are one of the first things to check.
Symptoms
- The user can open the work item but BranchDeploy cannot queue the pipeline.
- The same BranchDeploy configuration works for project admins.
- A manual pipeline run fails or the Run pipeline button is unavailable for the user.
- The error refers to queueing builds, build permissions, or pipeline authorization.
Permission BranchDeploy needs
The user needs permission to queue the Azure Pipeline configured in BranchDeploy. In Azure DevOps this is commonly controlled by the Queue builds permission on the pipeline or build security scope.
They also need normal read access to the work item, repository links, and pipeline run page so they can resolve the branch and view the result.
How to check pipeline security
- Open the Azure DevOps project.
- Go to Pipelines and select the deployment pipeline.
- Open the pipeline's security or permissions menu. In many Azure DevOps projects this is under the pipeline's overflow menu as Manage security.
- Find the user or group that should be allowed to deploy, such as a QA or release-management group.
- Set Queue builds to Allow.
- Ask the user to try a manual run first, then retry BranchDeploy from a linked work item.
Azure DevOps UI labels vary between pipeline views, but the key permission is the ability to queue the build or pipeline. If the user cannot queue the pipeline manually, fix that before testing BranchDeploy.
Other permissions that can look similar
Repository read access
BranchDeploy resolves branches and PRs from Azure Boards Development links. If the user cannot view the repository or pull request, the branch may not resolve correctly.
Service connection authorization
A user may be able to queue the pipeline, but the pipeline may fail because the pipeline identity or service connection is not authorized for the target resource. That is a pipeline execution problem, not a BranchDeploy button problem.
Environment approvals and checks
Deployment jobs that target Azure DevOps environments may pause on approvals, checks, or environment permissions. BranchDeploy can queue the run, but Azure Pipelines still enforces those controls.
Branch policies and branch filters
If YAML conditions or branch filters exclude the selected feature branch, the run may queue but skip deployment stages. Check the pipeline YAML when the run starts but does not deploy.
Recommended group setup
For a QA-driven deployment workflow, create or reuse an Azure DevOps group for the people allowed to deploy to non-production environments. Grant that group:
- Read access to the relevant work items and repositories.
- Queue builds on the deployment pipeline.
- Access required by any Azure DevOps environment checks or approvals.
Keep broader permissions, such as editing pipeline YAML or administering project settings, limited to the users who actually need them.
BranchDeploy admin permissions
There are two separate actions:
- Configuring BranchDeploy in Project Settings requires project admin-level access.
- Deploying with BranchDeploy requires permission to queue the configured pipeline and view the linked repo artifacts.
This lets a project admin set the pipeline ID, environment, and branch allowlist once, while QA or delivery users can queue approved deployments without editing configuration.
