Azure DevOps

Our Azure DevOps integration collects metadata about your organization’s activity across repositories, pull requests, and deployments. We never read, transmit, or store source code. Sensitive data, such as branch names and pull request titles, are always encrypted.

Connecting Azure DevOps

You connect through Azure DevOps’ standard OAuth authorization path: an administrator consents to our Microsoft Entra enterprise application, and Azure DevOps returns an access token and a refresh token, both of which we store encrypted. We never ask for, receive, or store a password or a personal access token, and you can revoke the grant in Azure DevOps at any time.

We recommend connecting with a dedicated service account rather than a personal account. It gives the integration a controlled, non-personal identity, so access is auditable, survives personnel changes, and can be scoped and revoked independently of any individual’s account. There are three ways to connect:

Option 1 — a dedicated service account with organization-wide read access. Recommended.
Option 2 — a dedicated service account limited to specific projects and repositories. The least-privilege option.
Option 3 — a personal account. Fastest to set up, but tied to an individual.

Important

You must be an Entra admin or able to install Microsoft Entra enterprise applications. If you do not have permissions, you may need to request approval before you can install our application. See Steps to Approve a Request.

Option 1: Connect as a “Service Account” (Recommended)

This method involves creating a dedicated user account in your Azure DevOps organization (e.g., svc-antenna@yourcompany.com ) solely for this integration.

In this setup, the integration is not tied to an individual person, so it will not break due to personnel changes; however, it will consume an extra paid user license in Azure DevOps.

Create a new user account

Create a new user account in your Microsoft Entra ID or Active Directory that is connected to your Azure DevOps organization.

Add the user to your Azure DevOps organization:
Navigate to Organization Settings > Users and click Add users.
Add the new service account user (e.g., svc-antenna@yourcompany.com ).
Set the Access level to “Basic”. This will consume one license.

Grant Administrator permissions

Navigate to Organization Settings > Permissions.

Select the Project Collection Service Accounts group.
Click the Members tab, then Add, and add the new service account user to this group.

Create an Antenna account

Connect to Azure DevOps

If you have not yet connected a Git provider, you can connect to Azure DevOps by clicking the Azure DevOps icon on the Connect Git page. You can also navigate to Settings, then Connected Apps to view available integrations.

Sign in and authorize

Sign in to Azure DevOps using the service account credentials, then authorize Antenna to access your Azure DevOps organization. Once authorized, we will start backfilling your historical data.

Option 2: Connect as a Service Account Without Project Collection Access

Some organizations prefer not to grant the broad permissions that come with the Project Collection Service Accounts group. In that case, you can instead give the service account explicit access to only the projects and repositories you want to analyze.

This approach follows the principle of least privilege — the service account can only read the specific projects you choose, rather than having organization-wide visibility. The tradeoff is that you must manually grant access for each project.

Important

Without Basic access (or higher) and explicit repository permissions, a service account may only be able to see users and groups but not repositories. Project membership alone is not enough — Stakeholder access cannot read private project repos.

Create a service account with Basic access

Follow the same steps as in Option #1 to create a new user account, but set the Access level to “Basic” (this will consume one license). Do not add the account to the Project Collection Service Accounts group.

Add the service account to each project

Navigate to the Project Settings of each Azure DevOps project you want to analyze. Under General > Teams or Permissions, add the service account as a member of the project.

Grant repository Read access

For each project, grant the service account read access to repositories. You can do this in one of two ways:

Via a group: Add the service account to the project’s Readers or Contributors group, which includes repository read permissions by default.
Explicitly: Navigate to Project Settings > Repositories > Security > All repositories and grant the service account Read access directly.

Grant pipeline and release access (optional)

If you want deployment metrics (e.g., release frequency, lead time to deploy), ensure the service account also has read access to Pipelines, Builds, and Releases for each project.

Connect in the Antenna app

Complete the same steps as in Option #1, but use the credentials of this service account to establish the connection.

Option 3: Connect Using a Personal Account

This method is the simplest and fastest way to get started. It uses the personal credentials of an existing user in Azure DevOps to establish the connection.

The user who connects should have “Project Collection Administrator” or “Organization Owner” permissions in order to provide access to all the repositories in your organization.

A disadvantage of this approach is that the connection is linked to an individual’s account. If that user leaves the company or their permissions are changed, the integration will break and must be re-established by another owner.

Create an account

Connect to Azure DevOps

Sign in and authorize

Sign in to Azure DevOps using your personal Azure DevOps account. Authorize Antenna to access your Azure DevOps organization. Once authorized, we will start backfilling your historical data.

Permissions

We request only the narrowest scopes that Azure DevOps offers for the data we need. Below is each scope we request, what we use it for, and why a narrower scope is not available.

Scope	Description
Code (read) `vso.code`	Read repository, commit, branch, and pull request metadata — SHAs, authors, timestamps, file paths, and line counts — for delivery, review, and quality metrics. We do not read, process, or store source code. Azure DevOps has no metadata-only scope for version control, so `vso.code` is the lowest privilege option; every alternative (`vso.code_write`, `vso.code_manage`, `vso.code_full`) adds write or manage access. Microsoft describes this scope as granting the ability to read source code and metadata, because the two cannot be separated — we call only the metadata endpoints and never fetch file contents.
Code (status) `vso.code_status`	Read the status of commits and pull requests, such as CI checks and policy evaluations, to measure delivery and change failure rate. We never create, update, or delete a status. Azure DevOps publishes a single status scope that bundles read and write, with no read-only equivalent. The grant confers no ability to modify commits or pull requests — only their status, which we only ever read.
Build (read) `vso.build`	Read build definitions, results, and timelines to measure deployment frequency and lead time to deploy. This is the read-only option; the alternative (`vso.build_execute`) adds the ability to queue builds.
Release (read) `vso.release`	Read release definitions, environments, and deployment records for deployment and DORA metrics. This is the read-only option; the alternatives add execute and manage rights.
Work items (read) `vso.work`	Read work items, boards, and iteration paths for planning metrics. Optional — omit it if you do not use Azure Boards. This is the read-only option; the alternatives (`vso.work_write`, `vso.work_full`) add write access.
Project and team (read) `vso.project`	Enumerate the projects and teams we are authorized to analyze, and roll metrics up by team. This is the read-only option; the alternatives add write and manage rights.
Graph (read) `vso.graph`	Resolve users, groups, and group memberships so activity is attributed to the right contributor and team. This is the read-only option; the alternative (`vso.graph_manage`) allows adding users and managing memberships.
Member entitlement management (read) `vso.memberentitlementmanagement`	Read the organization’s user list and access levels to build the contributor roster. This is already the narrowest option; the alternative (`vso.memberentitlementmanagement_write`) can manage users and licenses.

Scope names and privilege levels are defined in Microsoft’s documentation .

Note

Scopes define the maximum access the token can have. Actual access is always bounded by the permissions of the account that consents, so you can further restrict what we can see by connecting a service account with access to only the projects and repositories you want analyzed. See Option 2.

Data Collected

We collect only the metadata required to produce delivery, quality, and AI impact metrics. We never read, process, or store source code. For the full, provider-independent reference, see Data Collection.

Area	Data we collect	Azure DevOps APIs
Organization and projects	Organization name and ID, project name and ID, team name and ID, iteration (sprint) paths	Accounts, Projects, Teams, Classification Nodes
Users and groups	Display name, email, user ID, license/access level, group and team membership	Member Entitlements, Graph, Group Entitlements
Repositories	Repository name, ID, URL, default branch, visibility, project association	Git Repositories
Commits	Commit SHA, author and committer name/email, timestamps, commit message, changed file paths, and line counts	Git Commits, Pushes
Pull requests	Title, ID, URL, status, labels, source and target branch, author, reviewers, timestamps, iteration and thread (review comment) events, changed file paths, and line counts	Git Pull Requests, Iterations, Threads, Labels, File Diff
Commit and pull request status	Status name, state, and timestamp of checks reported against a commit or pull request	Commit Statuses, Pull Request Statuses
Builds and releases	Build and release definition name, ID, result, stage and job names, start and finish times, and the commit deployed	Builds, Build Timeline, Pipeline Runs, Release Deployments
Work items (optional)	Work item ID, title, type, state, assignee, story points, area and iteration path, parent/child and commit/pull request links, and field revisions	Work Item Tracking (WIQL, Work Items, Reporting Revisions and Links, Fields)
Events	Service hook subscriptions for push, pull request, build, and release events so metrics stay current	Service Hooks (Subscriptions)

We request file paths and line counts, not file contents. Sensitive values, such as branch names and pull request titles, are encrypted at rest.

Steps to Approve a Request (Entra Admin) in Azure AD

Note

Once approved, the user who initially tried to connect Azure DevOps can repeat the steps in whichever connection option you chose to connect Azure DevOps to Antenna.

If your organization requires Admin approval to install Enterprise Apps into Azure AD, follow these instructions to approve the application.

Sign in to the Azure Portal with your Azure AD administrator credentials. You will need to have at least a Cloud Application Administrator role to review and act on these requests.
Navigate to Azure Active Directory in the left-hand navigation pane.
In the left-hand navigation pane, go to Identity > Applications > Enterprise applications.
Under the Activity section, select Admin consent requests.
Select the Antenna application from the list of pending requests.
Go to the Review permissions and consent tab.
Click Grant Admin Consent to approve the request.

Once approved, all users who requested the app will be notified, and the application will be available for use by all users in the tenant unless you have configured it to require user assignment.