Azure DevOps integration
From conversation to work item in Azure DevOps.
Backlog.cloud listens to the meeting, or reads whatever transcript, recording or notes you give it, and turns the conversation into User Stories, Bugs, Tasks and Epics. After you review them, they land in your Azure DevOps project under the area path you chose, with the full structured description intact.
Work item types
Native types where they exist, honest fallbacks where they do not
Azure DevOps work item types depend on your process template, and pretending otherwise produces failed pushes. This is the actual mapping, with the template nuance spelled out. Every default can be remapped per project by an organisation admin.
| Artefact | Work item type | Notes |
|---|---|---|
| User Story | User Story | INVEST-shaped, numbered Gherkin acceptance criteria in the description. |
| Bug | Bug | Observed and expected behaviour, steps to reproduce, impact, environment. |
| Task | Task | Goal, context and deliverable. |
| Epic | Epic | Hypothesis, MVP scope, outcomes, success metrics. |
| Spike | Task + spike tag | ADO has no spike type by default. Remap it if your process adds one. |
| Requirement | Requirement on CMMI, Task elsewhere | Only the CMMI process template has a native Requirement type. Agile, Scrum and Basic projects get a tagged Task. |
| Action item | Task + action tag | Owner and due context carried in the description. |
Field mapping
The fields, by their real names
Each item becomes one JSON Patch create call against the work item tracking API. The description goes in as HTML because that is what System.Description actually renders, so headings, bold labels and bullet lists survive the trip instead of arriving as raw markup.
Acceptance criteria arrive as numbered Gherkin scenarios under their own heading in the description, and a Traceability section names who raised the item in the meeting. The reviewer has already seen the verbatim source quote before approving the push.
Area and iteration
Your area path, your sprint decisions
Area path is yours to set
Each Backlog.cloud project maps to one Azure DevOps project and one area path, set by an admin before the first push. Every work item lands under that node, so meeting output stays inside the team's slice of the tree rather than scattering across the project.
Iteration is left to planning
Pushed items arrive without a sprint assignment, on purpose. They land in the backlog and your team pulls them into an iteration when it actually plans the work. A tool that guesses your sprint for you is a tool whose guesses you spend Monday undoing.
Review, then push
Nothing reaches your backlog unreviewed
The queue comes first
Every extracted item waits in a review queue with the verbatim quote it came from. Edit, discard or approve, then push up to 200 items as one job. The push runs serially with live progress, skips anything already pushed, and records each work item's id and link back on the item. You can cancel mid-job.
OAuth 2.0, per user
You authorise with your own Azure DevOps account. No shared service account, no personal access token pasted into a form. Tokens are stored encrypted and refreshed before expiry. Revoke access and the next push stops with a clear connection error, and the job halts rather than burning through the rest of the batch.
Azure DevOps is one of six destinations: Backlog.cloud pushes to Jira, Azure DevOps, Linear, GitHub Issues, Notion and ClickUp, all listed on the integrations overview.
FAQ
Azure DevOps integration, answered
- Which work item types does Backlog.cloud create?
- User Story, Bug, Task and Epic map to their native Azure DevOps types. Spikes and action items land as tagged Tasks. Requirements are the interesting one: CMMI projects get the native Requirement type, while Agile, Scrum and Basic projects get a Task with a requirement tag, because those templates simply do not have a Requirement work item. Every mapping is remappable per project.
- How do work items get created technically?
- Through the Azure DevOps work item tracking REST API, one JSON Patch document per item against your organisation and project. Title, description, area path, tags and any configured default state or assignee are set in a single create call, and the response gives Backlog.cloud the work item id and a direct link.
- What happens with area and iteration paths?
- You set the area path once per project and every pushed item lands under it. Iteration is deliberately not stamped: items arrive in the backlog, not in a sprint, so your team pulls them into an iteration during planning. Automation that pre-assigns work to sprints tends to get reverted anyway.
- Is there a review step before anything reaches Azure DevOps?
- Yes. Extracted items wait in a review queue, each carrying the verbatim meeting quote it came from. You edit, discard or approve, then push. A per-project auto-push option exists once the output has earned trust.
- How does authentication work?
- OAuth 2.0, per user. You authorise Backlog.cloud against your own Azure DevOps account, tokens are stored encrypted and refreshed before expiry, and revoking access stops the next push with a clear connection error rather than a silent half-failure.
- What does not push to Azure DevOps?
- RAID entries, decision logs and meeting minutes, because a work item is the wrong shape for them. They stay in Backlog.cloud, push to Notion, or export directly. Process models download as BPMN 2.0 XML and Discovery Packs export as .docx.
Keep going
Related workflows and resources
Jira integration
The same pipeline with ADF descriptions and issue type mapping.
Linear integration
Issues with team targeting and markdown descriptions.
Meeting to backlog
The wider workflow: one conversation, twelve artefact types.
User stories
The INVEST structure and Gherkin criteria behind every pushed story.
Bug reports
Observed behaviour, reproduction steps and impact, extracted properly.
For product owners
How product owners run refinement and planning with Backlog.cloud.
Your next meeting could end as work items
Create a free account, run a meeting or transcript through it, and push the reviewed output to Azure DevOps. 3 free generations, no card.