Azure DevOps PAT scopes for DevOps

  • Release version: Xanadu
  • Updated July 31, 2025
  • 2 minutes to read
  • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Azure DevOps PAT scopes for DevOps

    This guide explains the necessary Personal Access Token (PAT) scope access levels required to integrate Azure DevOps with ServiceNow using the ServiceNow DevOps extension. Properly configuring PAT scopes ensures seamless connectivity and functionality between the two platforms without needing manual setup of webhooks or service connections in Azure DevOps.

    Show full answer Show less

    Note that the PAT owner must have specific administrative privileges depending on whether you are onboarding a project or an organization in Azure DevOps.

    Scope Access Levels and Their Practical Use

    The table below summarizes the scopes and their impact on different Azure DevOps capabilities that ServiceNow interacts with:

    • Boards (Work items): Requires Work item Read scope to discover boards and access work items through import, polling, or real-time webhooks.
    • Repos (Code): Requires Code Read scope to discover repositories and receive branch, commit, and tag information.
    • Build pipelines: Requires Build Read & Execute scopes. Read access enables discovery and retrieval of pipeline execution details (stages, artifacts, test results, code security results), while Execute access allows pausing/resuming pipelines during change control steps.
    • Release pipelines and gates: Requires Release Read, Write, and Execute scopes. Read scope supports discovery and execution details, while Write and Execute allow pipeline control during change management.
    • Test build and release pipelines (Test management): Requires Test management Read scope to receive test results from pipeline executions.
    • Service Connections: Requires Service connection Read, query, and manage scopes to automatically create and manage service connections, which are essential for configuring ServiceNow tasks such as change acceleration and artifact registration.
    • Packaging: Requires Packaging Read scope to discover artifact repositories and receive feeds and packages.

    Important: To ensure all pipeline features work without issue, the integration user must have the "Update build information" permission on the pipeline. Contact your Azure DevOps Project Administrator if you lack this permission.

    Key Considerations and Limitations

    • The PAT owner must belong to the Project Administrators group for project onboarding or the Project Collection Administrators group for organization onboarding to grant the necessary privileges.
    • If you create an Azure tool with custom-defined access levels and later reconfigure it due to credential changes, existing service hooks for releases are not updated but duplicated. To prevent this duplication, it is recommended to create the tool with full access levels.

    Scope access levels are required when using a personal access token (PAT) to access Azure DevOps during setup.

    Scope access level settings are based on the capability you have configured. Set the corresponding access level for seamless functionality. For information on creating a PAT, see Personal access token (PAT).

    Important:
    With the access level permissions specified in the following table in Azure DevOps, and the ServiceNow DevOps extension, you can connect to Azure DevOps from ServiceNow. Your Azure DevOps admin does not have to manually configure webhooks and service connections in Azure DevOps.
    Important:
    • When onboarding a Project, the Project Administrators privilege requires the owner of the PAT to be a member of the project's Project Administrators group.
    • When onboarding an Organization, the Project Administrators privilege requires the owner of the PAT to be a member of the organization's Project Collection Administrators group.
    Table 1. Scope access level settings per capability and their impact
    Capability Scope Access level Impact
    Boards Work item Read Required to discover the boards and receive the work items either through import/polling or real time with a configured webhook.
    Repos Code Read Required to discover repositories and receive branches, commits, and tags either through import/polling or real time with a configured webhook.
    Build pipelines Build Read & Execute
    • Read: Required to discover the build pipelines and receive pipeline execution details like stages, artifacts, test results, code security results, etc., either through import/polling or real time with a configured webhook.
    • Execute: Required to pause/resume the pipelines based on the change control step.
    Release pipelines and gates Release Read, write and execute
    • Read: Required to discover the release pipelines and receive pipeline execution details like stages, artifacts, test results, code security results, etc, either through import/polling or real time with a configured webhook.
    • Write and Execute: Required to pause/resume the pipelines based on change control step.
    Test build and release pipelines Test management Read Required to receive test results for pipeline execution.
    Service Connections Service connection Read, query, and manage Required to create Service connection automatically which is used to configure ServiceNow tasks like change acceleration, artifact and package registration, etc.
    Packaging Packaging Read Required to discover the artifact repositories and receive the feeds and packages either through import/polling or real-time with a configured webhook.
    Note:
    You must have the Update build information permission on your pipeline for all pipeline features to work seamlessly. Contact your ADO Project Administrator if you don't have this permission.

    Limitation of Azure DevOps

    If you create an Azure tool with custom defined access level, and you reconfigure such a tool because of change in your Integration user credentials, then the existing service hooks for release created and release deployment are not updated. Instead, two new service hooks are created with new configuration details. To avoid the duplication of these service hooks, you must create the tool with full access level.