Support ticket to Azure DevOps: structured bug handoff without the rewrite

Watari turns a free-form Zendesk or Intercom ticket into a structured bug report, maps it to a specific file and function in Azure Repos using Microsoft Entra ID authentication, and opens a draft pull request — all without a human rewriting the ticket into an Azure DevOps work item. The same two-gate confidence model that qualifies a Mapped Bug on a GitHub repository applies identically on Azure Repos.

The format mismatch that kills Azure DevOps escalations

The handoff tax between support and engineering is not a GitHub problem or an Azure DevOps problem — it is a format problem. A Zendesk ticket is empathy prose: "Ever since the April release, payments fail intermittently for our enterprise accounts." An Azure DevOps work item is a reproduction artifact: severity, steps to reproduce, expected behavior, affected component, assignee. The gap between those two formats is where bugs go to rot.

On teams using Azure DevOps, the typical escalation path looks like this:

1. A support agent reads five customer threads about the same error.
2. The agent opens a new Azure DevOps work item and tries to synthesize those threads into a description an engineer can act on.
3. The work item lands in the backlog as a vague title — "payment failures" — with no repro steps and no code pointer.
4. The engineering manager triages it into a sprint two weeks out.
5. By the time an engineer picks it up, the customer has already churned or the thread context has been lost.

This loop happens regardless of whether your source control is GitHub, Azure Repos, or anything else. The structural problem is that free-form support conversation and structured engineering artifact are different objects, and converting one to the other manually is slow, lossy, and person-dependent.

Watari's extraction step solves the conversion problem automatically. When a ticket arrives from Zendesk or Intercom via webhook, the extraction model pulls out a structured bug: severity, reproduction steps, expected versus actual behavior, customer impact, and the customer's original words verbatim. That structured output — not a paraphrase, not a summary — is what reaches your engineering team. The same extraction quality applies whether your repository lives on GitHub or Azure Repos.

How Azure DevOps authentication works — and why Entra ID matters

Watari connects to Azure DevOps through Microsoft Entra ID rather than a personal access token. This distinction matters operationally for engineering managers and support-ops leads who have dealt with the classic PAT problem.

A personal access token is user-bound. When the engineer who created it leaves the company or rotates their credentials, every integration that depended on that token breaks simultaneously — often at 2 a.m. on a Sunday. Auditing which systems hold a given PAT is painful, and revoking it is even more so because you don't know what you'll break until it's already broken.

Microsoft Entra ID authentication is organization-scoped. According to the Azure DevOps integration docs, Watari requests read access to your repositories for code mapping and write access to open draft pull requests — nothing more. Any organization admin can revoke access in one click from the Azure portal, and that revocation is immediate across every repository in the installation. No individual engineer's credentials are in the chain.

This is the same principle Watari applies to its GitHub App: scoped to an organization, revocable by any admin, narrower in privilege than a PAT. The security model is consistent across both providers.

The two-gate confidence model on Azure Repos

A ticket becoming a Mapped Bug requires two independent confidence gates to clear. Neither gate is relaxed for Azure Repos — the pipeline runs identically.

Gate 1 — Extraction confidence. The extraction model must produce a structured bug with high confidence. Low-signal tickets — a one-line complaint with no repro, a feature request phrased as a complaint — fail this gate and are not promoted. That keeps your Azure DevOps work-item queue from filling with unactionable noise.

Gate 2 — Code location confidence. Watari indexes your Azure Repos repositories with tree-sitter, parsing every supported source file at the function level and storing vector embeddings in a pgvector HNSW index. The mapping stage embeds the structured bug and queries that index, reranks the top candidates, and confirms at least one file-and-function match above the confidence threshold. If no match clears the threshold, the bug is routed for manual review rather than promoted — no false-positive code pointers.

Only when both gates clear does the Mapped Bug qualify. That is the moment the billing meter fires, and it is also the moment the draft pull request opens against your Azure Repos branch.

The practical implication: your Azure DevOps backlog receives work items that already have a code location attached. An engineer opening the item sees the specific file and function implicated — not a vague component label, but a pinned location. That changes triage from "figure out where this lives" to "confirm this is the right place and review the proposed fix."

What happens after the Mapped Bug qualifies

Everything downstream of the Mapped Bug is bundled — it never adds to your bill. On Azure DevOps, that downstream behavior is identical to GitHub:

• Draft pull request. Watari reads the relevant source files, reads the structured bug, and produces a proposed fix in a draft PR against your configured branch. Your CI runs. If CI fails, Watari iterates. A human engineer reviews every diff before merge — the code-to-PR docs are explicit that merging without review is never appropriate.
• Reviewer routing. On Azure Repos, Watari resolves commit-history-inferred owners to Azure identity GUIDs via Microsoft Entra ID, so the draft PR lands with the right reviewers attached — not a broadcast to the entire engineering team.
• Slack, Linear, and Jira sync. If you have routing destinations configured, Watari posts the Mapped Bug to your Slack channel, creates a Linear issue, or syncs a Jira ticket. These work the same way regardless of whether the repository is on GitHub or Azure Repos.
• RCA publish. After the fix ships and Watari detects the production deploy, it drafts a customer-facing root-cause analysis and publishes it back to the originating Zendesk or Intercom ticket. The support agent does not write the post-incident summary — Watari generates it from the structured bug, the confirmed code location, and the merged diff.

The closed loop — ticket in, RCA back to ticket — is what makes the handoff tax disappear rather than just move. The support agent who received the original complaint sees the resolution appear in the thread. The engineering manager sees a work item that moved from triage to merged in a measurable cycle time. Neither of them spent an hour rewriting prose.

Routing Zendesk and Intercom tickets to Azure DevOps — the setup path

Setup follows the same quickstart sequence regardless of your SCM. From Settings → Integrations:

1. Connect Zendesk or Intercom via OAuth. Watari registers its webhook on your account immediately — tickets flow in automatically from that point.
2. Authenticate Azure DevOps through Microsoft Entra ID. Select the repositories you want Watari to index. Watari clones and indexes them in the background; a typical SaaS codebase finishes in a few minutes.
3. Configure confidence thresholds if the defaults don't match your team's precision-recall preference. Higher thresholds mean fewer Mapped Bugs but tighter code-location confidence; lower thresholds surface more candidates for manual review. These are tunable in Settings → AI Behavior.
4. Wire routing destinations — Slack, Linear, or Jira — if you want the wider team to see Mapped Bugs as they qualify. This step is optional; draft PRs and RCAs work through Azure Repos alone.
5. Invite your engineering team. Teammates added in Settings → Team see the Mapped Bug dashboard, can flag mismapped bugs within the 7-day credit window, and manage their own notification preferences.

Plan limits on how many repositories you can connect vary by tier — see plans and pricing for the current numbers. Connecting a repository beyond your plan's limit is blocked at connect time; upgrading immediately reactivates the excess repositories.

The handoff tax is a format problem, not a tooling problem

Every tool that tries to solve support-to-engineering escalation by adding a "create work item" button in Zendesk is solving the wrong problem. The button doesn't extract structure from the conversation — it just moves the rewrite burden from the engineer to the support agent.

The extraction step is what matters. A structured bug with confirmed code locations is a different object than a support ticket, and producing that object reliably — at extraction-confidence and code-location-confidence thresholds — is the work Watari does before anything touches Azure DevOps. The Azure Repos integration via Microsoft Entra ID, the reviewer routing, the draft PR, the RCA publish: all of that is downstream of the extraction quality.

For teams on Azure DevOps, the pipeline is first-class. Not a GitHub port, not a second-tier integration — the same confidence gates, the same authentication model, the same closed loop from Zendesk or Intercom ticket to merged fix to published RCA.