Azure Pipelines · YAML pipelines and resources · Checked November 5, 2026

Azure Pipelines: "There was a resource authorization issue": a variable as the service connection name, a name that does not match, or a connection that is disabled or not authorized

Before a stage starts, Azure Pipelines looks up every service connection, secure file, variable group and agent pool its jobs reference, and checks that this pipeline may use it. The run fails here when one is missing, disabled or not authorized. Read the name after references service connection: if it is still $(something), the name came from a variable the pipeline did not have yet, and a template parameter fixes it; otherwise copy the exact name from Project settings → Service connections and authorize the pipeline (a Stack Overflow question on this message has been seen more than 11,000 times).

When this fails a pull request's build validation, the build fails before its first stage, and the pull request cannot complete until a run passes: Azure DevOps Pull Requests, a plugin for JetBrains IDEs, lists the pull request's branch policies with their state in your IDE, so the failed required build is next to the pull request that waits on it. Get it on JetBrains Marketplace

What it looks like

• There was a resource authorization issue: "The pipeline is not valid. Job Deploy: Step AzureCLI input connectedServiceNameARM references service connection my-azure which could not be found. The service connection does not exist, has been disabled or has not been authorized for use. For authorization details, refer to https://aka.ms/yamlauthz."
• Read three parts: the job and the step; the input (connectedServiceNameARM is the task's azureSubscription; others are backendServiceArm, kubernetesServiceConnection, containerRegistry); and the name after references service connection, exactly as the pipeline had it.
• The same message names a secure file (input secureFile references secure file file_B.txt which could not be found), a variable group (Variable group was not found or is not authorized for use) or a pool (Could not find a pool with the name ... The pool does not exist or has not been authorized for use).
• The link in the message opens Microsoft's Resource authorization. Microsoft's Pipeline runs page gives the order: templates and template expressions first, then, for each stage it selects, the check of all the jobs' resources, and only after that the jobs, their conditions and their steps.

The name is still $(...): a variable as the connection name

• If the message says references service connection $(serviceConnection), the pipeline checked the connection before it had the variable's value. Microsoft says plainly that variables cannot resolve service connection or environment names, because resources are authorized before a stage starts: stage and job variables are not there yet, and a variable group is itself a resource, so its values are not either. An output variable of an earlier job or task, or a value set with a logging command, comes even later.
• A template parameter or a runtime parameter is resolved in the first step, from the text of the YAML, so ${{ parameters.serviceConnection }} works where $(serviceConnection) does not (Runtime parameters):

parameters:
- name: serviceConnection
  type: string
  default: azure-dev
  values:
  - azure-dev
  - azure-prod

steps:
- task: AzureCLI@2
  inputs:
    azureSubscription: ${{ parameters.serviceConnection }}
    scriptType: bash
    scriptLocation: inlineScript
    inlineScript: az account show

• A different connection for each stage (asked on Stack Overflow, seen almost 9,000 times): put the stage in a template with the connection as a parameter, and call the template once per stage with its own value. A variable under each stage does not work, for the reason above.
• A value written in the pipeline's own top-level variables: is available. For an Azure subscription taken from an earlier task's output, Microsoft's troubleshooting for Azure Resource Manager connections says to define the value in the pipeline's variables section instead.
• Each connection a parameter can choose must also be authorized for the pipeline, like a connection written by name.

A name that does not match a connection in this project

• The input takes the service connection's name as Project settings → Service connections shows it (Use a service connection). The Azure subscription's name, the subscription ID and the name of the app registration in Microsoft Entra ID are not found. Copy the name from that list.
• In a pipeline split into templates, the name in the message is the value after the templates were expanded. If the template works alone, check what the calling pipeline passes to it.
• A template from another project runs in the project of the pipeline that calls it, and a service connection is not shared with other projects by default. An organization-level administrator can share it: the connection → Security → Project permissions → Add projects. In the other project the shared connection's name has the project name appended, and it can be renamed there, so use the name that the calling project shows (Set service connection project permissions).

A disabled connection

• The message says the connection may have been disabled. Service connection administrators and Project Administrators can select Disable on the connection's More options menu, and pipelines that reference it then fail until someone selects Enable on the same menu.
• Azure Pipelines can also disable a connection by itself after 100 days without use. The list of service connections and the connection's page show that it is disabled, and the Audit log records when it was disabled and enabled (Edit a service connection, updated October 15, 2026). A connection used only by a deployment that runs a few times a year can reach those 100 days.
• To check, open the connection from Project settings → Service connections: the Overview and Usage history tabs show that it is disabled and when it was last used (Microsoft's troubleshooting).

A connection the pipeline is not authorized for

• Microsoft's steps: make sure you have at least the User role on the resource, choose the option to authorize the resources on the failed run, and start a new run.
• To authorize ahead of time, add the pipeline under the connection's Security → Pipeline permissions. Grant access permission to all pipelines also exists, and Microsoft does not recommend it (Authorize pipelines).
• If the run waits with View and Permit instead of failing, it is the other side of the same check: "This pipeline needs permission to access a resource before this run can continue", with who can select Permit on each kind of resource.

Secure files, variable groups and pools

• A secure file follows the same rules as a connection: references secure file $(CertSecureFile) is a variable the pipeline did not have yet. A step whose condition: would skip it still has its secure file checked, because the check comes before conditions are evaluated (a Stack Overflow question about downloading a secure file only for some runs). To leave the file out, remove the step with ${{ if }} on a parameter, which happens when the templates are expanded.
• Variable group was not found or is not authorized for use: the name under - group: must match a group in Pipelines → Library of the pipeline's project, and a YAML pipeline must be authorized to use the group (Authorization via the Pipelines UI).
• Could not find a pool with the name ...: the name under pool: must be one of the pools in Project settings → Agent pools of the pipeline's project, and the pool must allow this pipeline. A pool with the right name but no agent for the job fails differently: "No agent found in pool ... which satisfies the specified demands".

Azure DevOps pull requests in IntelliJ IDEA and Rider

Azure DevOps Pull Requests, a plugin by Lesstep for JetBrains IDEs 2024.1 or later and Android Studio, reads the organization, project and repository from your git remote and lists the pull requests that wait for your review in an IDE tool window, on Azure DevOps Services and on Azure DevOps Server. It shows the branch policies of a pull request with their state, so a required build that has not passed is next to its pull request, and when a required policy has not passed, its Complete dialog offers auto-complete first. The review inbox is free; voting, commenting, completing and creating are Pro, with a 30-day trial.

Get it on JetBrains Marketplace

Azure DevOps, Azure Pipelines and Microsoft Entra ID are trademarks of Microsoft Corporation; IntelliJ IDEA and Rider are trademarks of JetBrains s.r.o. This page is not affiliated with or endorsed by Microsoft or JetBrains.

More: a run that waits for Permit · no agent in the pool meets the demands · no Microsoft-hosted parallel job yet · 日本語