Jira Bug to Azure DevOps Work Item Bridge
When a bug is created or escalated in Jira, the flow creates a linked Azure DevOps work item for the engineering team, keeps status, comments, and resolution in sync both ways, and notifies the Jira reporter on fix. Bridges Jira and Azure DevOps for teams split across both.
Provided as-is, without warranty of any kind. Review and test each pattern in a non-production environment before deploying it to live automations. See our Terms.
Overview
This solution bridges Jira and Azure DevOps for teams split across both tools, and keeps them in sync both ways. When a bug is created or escalated in Jira, a linked Azure DevOps work item is created automatically; when that work item is later resolved in Azure DevOps, the resolution is synced back to the Jira issue and the reporter is notified. A correlation id is minted at the start of the bridge and propagated across both systems for end-to-end traceability.
Why it matters: cross-tool handoffs lose context and updates. A live, two-way bridge keeps both systems consistent without manual copying, so product/support (Jira) and engineering (Azure DevOps) always see the same state.
Built as two flows in one solution (producer and back-sync); both ship Off.
Use Case
Product and support teams work in Jira while engineering works in Azure DevOps. Bugs raised in Jira must reach engineering's backlog, and fixes made in Azure DevOps must flow back to the Jira reporter - without anyone re-keying data between the two systems.
Flow Architecture
Flow 1: When a New Bug Is Created in Jira
Jira - OnNewIssueJQLDetects new/escalated bugs via the JQL in flowlibs_BugSyncJQL (polling, 15 min).
Build & Create Work Item
Compose + Azure DevOps HttpRequestMints a correlation id, builds the work item Tags (JiraBridge; cid:<guid>; jira:<key>), a [KEY] title prefix, and a JSON-Patch document, then POSTs to create the ADO work item.
Link Back & Notify
Jira AddComment_V2 + TeamsComments the work-item id/URL/correlation id onto the Jira issue and notifies engineering in Teams.
Flow 2: When a Work Item Is Updated in ADO
Azure DevOps - OnWorkItemUpdatedV2Fires on updates to work items of the configured type (polling, 15 min).
Guard & Map
Condition + ComposeParses the Jira key from the title prefix and the correlation id from the tags; proceeds only when the state is resolved AND the bridge tag is present (echo-loop guard); maps the ADO state to a Jira transition.
Transition, Comment & Notify
Jira ListTransitions/UpdateTransition/AddComment_V2 + TeamsMoves the Jira issue to the mapped status when available, posts the resolution comment (notifying the reporter), and posts a resolution card to Teams.
Environment Variables
| Schema name | Type | Default | Description |
|---|---|---|---|
| flowlibs_BugSyncJQL | String | project = FLOW AND issuetype = Bug ORDER BY created ASC | JQL the Jira trigger polls for new/escalated bugs. |
| flowlibs_StatusMap | String | {"Resolved":"Done","Closed":"Done","Done":"Done"} | Maps Azure DevOps state to Jira transition name. |
| flowlibs_ResolvedStates | String | Resolved,Closed,Done | ADO states that count as resolved and trigger back-sync. |
| flowlibs_BridgeTag | String | JiraBridge | Tag stamped on bridge work items so the back-sync can identify them. |
| flowlibs_ADOAccount | String | your-org | Azure DevOps organization name. |
| flowlibs_AdoProject | String | FlowLibs | Target Azure DevOps project. |
| flowlibs_AdoWorkItemType | String | Task | Work item type to create/watch (set to Bug for bug tracking). |
| flowlibs_JiraInstance | String | REPLACE_WITH_JIRA_INSTANCE | Jira instance for the X-Request-Jirainstance header. |
| flowlibs_TeamsGroupId | String | <your-team-id> | Teams group/team id for notifications. |
Connectors & Connections
| Connector | API name | Actions used |
|---|---|---|
| Jira | shared_jira | OnNewIssueJQL ListTransitions UpdateTransition AddComment_V2 |
| Azure DevOps | shared_visualstudioteamservices | OnWorkItemUpdatedV2 HttpRequest |
| Microsoft Teams | shared_teams | PostMessageToConversation |
Note — All connections are referenced as solution connection references; the flow is portable between environments as long as a connection is mapped at import time.
Customization Guide
Almost every realistic variant of this flow can be implemented by changing environment variable values. A few cases require small edits inside the flow definition — those are called out explicitly below.
- Field mapping / work item type
- Set flowlibs_AdoWorkItemType to your engineering type; add fields to the JSON-Patch array (e.g. /fields/Microsoft.VSTS.Common.Priority) to map Jira severity/priority.
- Which bugs bridge
- Edit flowlibs_BugSyncJQL (e.g. add AND labels = escalated, or scope to a project/component). Replace the trigger with a Jira webhook for real-time.
- Status mapping
- Edit flowlibs_StatusMap (ADO state to Jira transition) and flowlibs_ResolvedStates to match your Jira workflow and ADO process template.
- Attachment sync
- Add an ADO attachment upload step (work item attachments API via HttpRequest) fed from the Jira issue attachments.
- Notifications
- Point the Teams ids at your engineering channel; the message HTML in the two Teams actions can be branded.
Key Expressions
The flow is intentionally light on Power Fx / WDL gymnastics — the heaviest expressions are the branch-name concatenation and the approval outcome check. They are listed below in the order they appear in the flow.
EXPR.01Work item Tags (Flow 1)
Stamps the bridge tag, correlation id, and Jira key onto the work item.
EXPR.02ADO create URI (Flow 1)
POST target for the JSON-Patch work-item create.
EXPR.03Recover correlation id from tags (Flow 2)
Reads the correlation id back off the work item tags.
EXPR.04Map ADO state to Jira transition (Flow 2)
Resolves the Jira transition for the resolved ADO state.
Comments
Sign in to join the conversation.
Sign inNo comments yet. Be the first to share your experience with this flow.