Connect Azure DevOps (Azure Repos) through Microsoft Entra ID, select repositories, and set up reviewer routing, branch policies, and optional bot-authored pull requests.

Azure DevOps

Watari connects to Azure DevOps (Azure Repos) through Microsoft Entra ID. It gets read access to your repositories for code mapping and write access to open draft pull requests — nothing more. Everything the pipeline does on GitHub, it does on Azure DevOps: index your code, map bugs to files and functions, open draft PRs, watch build validation, and confirm production deploys before publishing a customer-facing RCA.

Why Microsoft Entra ID, not a personal access token

Watari authenticates with your Azure DevOps organization through Microsoft Entra ID (the modern, tenant-backed OAuth flow), not a personal access token. An Entra connection is bound to your organization's tenant, uses short-lived access tokens that are refreshed automatically, and can be revoked in one place by an administrator — from Microsoft Entra → Enterprise applications or from your Azure DevOps organization's OAuth authorizations. Personal access tokens are user-bound, long-lived, harder to revoke cleanly, and carry broader scope than Watari needs.

Connecting Azure DevOps

In the Watari dashboard, go to Settings → Integrations and click Connect Azure DevOps (or use Connect repository → Azure DevOps on the Codebase page).

You are redirected to Microsoft to sign in and review the access Watari requests. Approve the consent screen. Depending on your organization's policies, an administrator may need to approve the connection on your tenant's behalf — this is a one-time step.

Watari discovers the Azure DevOps organizations you belong to. If you belong to exactly one eligible organization, it links automatically; if you belong to several, you choose which one to connect.

Choose the project and repository to connect. Watari only reads and opens PRs in repositories you explicitly connect here. Indexing starts immediately.

What Watari can do

Through Entra delegated access, Watari acts on the Azure DevOps REST API on your behalf, using only the operations the pipeline needs:

Capability	Access	Why
Code (repositories)	Read + Write	Read source files for indexing; push commits for draft PR patches
Pull requests	Read + Write	Open draft PRs, request reviewers, respond to iteration comments
Work items (Boards)	Read + Write	Sync bug records to Azure Boards when that integration is enabled
Service hooks	Read + Write	Subscribe to push, PR-merge, and pipeline events so status stays current
Build & pipelines	Read	Read build validation and stage status to confirm CI and production deploys

Watari never deletes branches, force-pushes, or changes organization settings. Draft PRs are opened against your default branch and always sit behind your own branch policies.

Repository indexing

After you connect a repository, Watari fetches it and builds a searchable index of its code. For a typical SaaS repository, the first index completes in a few minutes; large monorepos take longer — progress is visible under Codebase in the dashboard.

Azure Repos often use master as the default branch rather than main. Watari resolves your repository's actual default branch automatically — there is nothing to configure.

Subsequent pushes to the default branch trigger an incremental reindex automatically (Watari subscribes to a service hook for this at connect time), so the index stays current without any manual action.

Reviewer routing

Azure DevOps does not use a CODEOWNERS file. Watari infers reviewer candidates from the commit history of the files a bug maps to, and adds them as reviewers on the draft PR. The reviewers chosen for each mapped bug are shown on the bug detail page.

If you enforce required reviewers through a branch policy, those take precedence — Watari's inferred reviewers are added alongside them, never in place of them.

Branch policies

Watari opens draft PRs against your repository's default branch. Azure DevOps runs build validation and required-reviewer policies only once a pull request leaves draft state, so Watari publishes the draft when the fix is ready — at which point your branch policies run exactly as they would for any human-opened PR.

Watari does not bypass branch policies. If your policy requires build validation to pass or a minimum number of approvals, the PR will not complete until those are satisfied by your pipelines and human reviewers.

Bot-authored pull requests (optional)

By default, a draft PR is authored by the user who connected Azure DevOps — because Entra sign-in acts on that user's behalf. If you would prefer PRs to be authored by Watari instead of a teammate, add Watari's service principal to your Azure DevOps organization once:

In your Azure DevOps organization, go to Organization settings → Users → Add users.

Search for Watari (the service principal), assign Basic access, and add it to the project and the Project Contributors group. Basic access is free within your organization's included user allotment.

Once added, new draft PRs are authored by Watari. This mirrors how tools like Renovate, GitHub Copilot, and Devin operate on Azure DevOps — Azure has no way to auto-install an app identity into your organization, so this one-time step is what grants the bot identity.

This step is entirely optional. If you skip it, everything still works — PRs are simply authored by the connecting user instead of by Watari. Nothing in the pipeline depends on it.

Multi-repo support

If a bug maps to code across more than one connected Azure DevOps repository, Watari opens linked draft PRs in each repository and tracks them as a stack. The customer-facing RCA is held until every contributing PR merges and a successful production deploy is confirmed across all affected repos.

Watari can map and open PRs across GitHub and Azure DevOps repositories in the same workspace — a bug is routed to whichever repositories its code actually lives in, regardless of provider.

Deploy confirmation and RCA

Watari confirms a production deploy before it publishes a customer-facing RCA. For Azure DevOps, it listens for the stage of your YAML pipeline that targets your production environment to complete successfully. Once the merge and the production stage are both confirmed, the RCA is generated and (if you have enabled auto-publish) delivered to the originating ticket.

Disconnecting

Disconnecting Azure DevOps from Settings → Integrations immediately revokes Watari's access and stops indexing and PR generation for the connected repositories. Historical bugs, mappings, and RCAs remain in your Watari workspace for 30 days after disconnect, then are purged. You can reconnect at any time.

For a complete revocation, also remove Watari from your identity provider — Microsoft Entra → Enterprise applications → Watari → Delete, or revoke the authorization in your Azure DevOps organization's OAuth settings. Disconnecting inside Watari stops all activity; removing the Entra authorization is the authoritative revocation of the underlying access grant.

Next: Routing and notifications — Slack, Linear, and Jira setup — configure Slack, Linear, Jira, and issue-tracker sync.

Azure DevOps

On this page