How DSALTA integrates with Azure DevOps — data collected, setup guide, and automated compliance checks.
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 Data Library modules. 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.
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:
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.
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
1
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.
2
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.
3
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.
4
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.
5
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.
.png?fit=max&auto=format&n=tsMQJyneJ1xquFUo&q=85&s=4d401cc03b547d99b6f75a6bd170c334)