Azure DevOps

Overview
How to connect
Automated checks
Useful links

DSALTA connects to Azure DevOps using read-only API access to collect compliance evidence automatically. Data feeds into your Access accounts, Inventory and Code Changes pages. Compliance checks re-run once a day at 02:00 America/New_York.

Read-only access. DSALTA never modifies, creates, or deletes resources in your Azure DevOps environment.

What DSALTA reads

DSALTA reads the Azure DevOps user roster — display name and mail address — which appears on your Access page (every row is recorded with the role Member and status Active; the Graph users endpoint returns neither an Azure DevOps role nor an account state); and your Azure DevOps resources, which appear on your Inventory page. It also reads your pull requests, which appear on your Code Changes page — DSALTA does not read commits.It calls these Azure DevOps endpoints:

/_apis/projects
/_apis/graph/users
/{project}/_apis/git/repositories
/{project}/_apis/git/repositories/{repositoryId}/pullrequests
/{project}/_apis/policy/configurations

Permissions the checks require: Code (Read), Policy (Read), Project and team (Read) — plus Graph & Identity (Read) and User profile (Read) for the user roster on your Access pageEvery request is a read. DSALTA has no code path that creates, modifies, or deletes anything in your Azure DevOps environment.

Troubleshooting

Integration shows Disconnected

There is no Reconnect button. Open Integrations → Connected, click Manage on the Azure DevOps card, and check the Status tab — it shows either Connected and working properly or Connection issues detected. To restore a broken connection you must Disconnect and connect again, which permanently deletes the data and tests collected from Azure DevOps. This usually happens when API tokens expire.

Data is not syncing

Verify the connected account still holds the permissions listed under Before you begin. Then open Integrations in the DSALTA sidebar, stay on the Connected tab, and click Sync from integrations at the top right. That button refreshes every connected integration at once — there is no per-integration sync control.

Connect with an Azure DevOps Personal Access Token for your organization. We use read APIs for repositories, pull requests, and compliance tests; optional Work items (Read & write) only if you enable write access below.Before you begin

Organization admin (or equivalent) to confirm org policies and create a PAT with the right scopes

You will need:

Field	Where to find it	Example
Azure DevOps organization	See the steps below	`my-org`
Personal access token	See the steps below	`PAT from User settings → Personal access tokens`

Start in DSALTA

Open Integrations in the DSALTA sidebar, find Azure DevOps, and click Connect to open the connect panel. Leave it open — it lists every value you need, and you create those in the steps below.

Verify permissions

Let’s get started linking your Azure DevOps organization.First, verify that you are an administrator of the Azure DevOps organization that houses your company’s codebase (not only a single project).An easy way to check: open your Azure DevOps organization page and confirm Organization settings is available in the sidebar.To allow third-party tools to connect, many teams enable OAuth-based app access. In Organization settings, open Policies (under Security). On the Application connection policies page, ensure Third-party application access via OAuth is turned On if that matches your security policy.For this DSALTA connection you will use a Personal Access Token (PAT). Confirm your account can create PATs: user menu → Personal access tokens. Some organizations restrict PAT creation via policy—your admin may need to allow it.

Configure write access

Choose the access level for the token you will create in the next step. Read access is enough for DSALTA to monitor repositories, pull requests, and run most compliance tests.

Write access is needed only if DSALTA should create or update Azure DevOps work items on your behalf (for example, ticketing integrations). If you only need monitoring and evidence collection, use Read access only.

Create a personal access token

Give the token these read-only scopes: Code (Read), Project and team (Read), Policy (Read) (branch-policy checks) and Graph & Identity (Read) plus User profile (Read) (the user roster on your Access page). Nothing else is needed.Add Graph & Identity → Read (and User profile → Read) as well. The Access page is filled from https://vssps.dev.azure.com/{organization}/_apis/graph/users, which Microsoft gates behind the vso.graph scope — “Graph (read): grants the ability to read user, group, scope, and group membership information”. Without it the repository and branch-policy checks still work, but DSALTA collects no user roster and the access-review checks have nothing to compare against.

Copy the token on the confirmation screen — Azure DevOps shows it once — and choose the expiration deliberately. When a PAT expires the nightly sync starts failing, and DSALTA has no Reconnect button: you have to Disconnect and connect again with a fresh token, which permanently deletes the evidence and test results already collected from Azure DevOps.

Authenticate and connect Azure DevOps

DSALTA will use your organization name and PAT to reach Read (and Write only if you selected read/write) APIs for monitoring.

After you click Connect, we validate the token against your organization before saving the integration.

DSALTA validates the credential when you click Connect. On success the integration moves to the Connected tab, and Manage → Status reads Connected and working properly. Checks begin reporting after the first sync.

If the connection is rejected. Could not validate token. Check organization name, PAT scopes, expiration, and org policies (OAuth / PAT).The on-screen message is generic — see Connection error messages.

Each check below re-runs once a day, at 02:00 America/New_York, while this integration is connected. Click any check for step-by-step remediation guidance.

Check	Severity	What it verifies
Code repo should be classified	Info	Ensures Azure DevOps Git repositories are not left in generic/default project layouts without distinct naming.
Peer review should be enforced for code changes	Info	Checks that minimum reviewer branch policies apply to default branches.
Merging of code changes should require passing status-checks	Info	Checks for build validation policies on default branches.
Branch Protection rules should be enforced for admins	Info	Flags minimum-reviewer policies that are not marked as blocking.
Code changes should be reviewed by peers before merging	Info	Mirrors peer-review policy enforcement on default branches.
User access to Critical System should be valid	Info	Checks that everyone with Azure DevOps access is an active employee on the People page.
Offboarded users should not have active access	High	Checks that offboarded employees no longer have active Azure DevOps access.

Topic	Link
Setup	Use personal access tokens
Setup	Application connection policies
General	Azure DevOps website
DSALTA	Connection error messages

Getting Connected

Identity Providers

Cloud Infrastructure

Code Repositories

Security & Monitoring

Databases

SaaS & Productivity

What DSALTA reads

Troubleshooting

​What DSALTA reads

​Troubleshooting

What DSALTA reads

Troubleshooting