How to Integrate ServiceNow with Azure DevOps: Closing the Loop from Incident to Deployed Fix
Last updated: November 2026
To integrate ServiceNow with Azure DevOps effectively, connect the incident in ServiceNow to a bug in Azure DevOps, and then let engineering progress flow back: the work item state, the pull request, the build and the release that contains the fix. When the fix is deployed, the incident is updated automatically so the service desk can confirm and resolve it. This incident-to-fix loop is what turns a basic ServiceNow Azure DevOps connection into an integration both teams rely on. No-code platforms such as ZigiOps, the integration platform by ZigiWave, let you configure the whole loop without scripts in either system.
Organizations that run ServiceNow for IT service management and Azure DevOps for software delivery often connect the two with a one-way push: an incident creates a work item, and that is where the integration stops. The service desk then spends days asking developers whether the bug is fixed, deployed, or still waiting in a backlog.
This article follows one incident end to end, from a priority 1 report to a resolved incident with release information, and shows which data should travel between ServiceNow and Azure DevOps at each stage.
The example scenario
A customer-facing payment page starts returning errors after a release. Users call the service desk. Within minutes, several incidents are logged, and one is raised to priority 1. Monitoring confirms the issue is in the application, not the infrastructure. The application is built by a team that works entirely in Azure Boards, Azure Repos and Azure Pipelines.
Without integration, the major incident manager pastes details into a Teams chat, a developer creates a bug manually, and the service desk has no visibility until someone remembers to update them. With integration, the flow looks very different.
Stage 1: Incident logged and escalated
The incident is created in ServiceNow, categorized and assigned. When it is assigned to the application's assignment group (for example, "Payments - Development"), the integration triggers. Assignment group is the most reliable trigger for a ServiceNow Azure DevOps integration because it reflects routing decisions the service desk already makes. In ZigiOps, this is a trigger filter on the incident, such as "assignment group is Payments - Development", configured in the UI.
If several incidents describe the same problem, the service desk should link them to a single problem record or to the parent major incident, and only that parent should create a work item. This prevents engineering from receiving five copies of the same bug.
Stage 2: Bug created in Azure DevOps
The integration creates a Bug work item in the right Azure DevOps project and area path. Mapping assignment groups to area paths (System.AreaPath) is a clean way to route work to the right team's backlog.
| ServiceNow incident field | Azure DevOps Bug field | Notes |
|---|---|---|
| number | Custom field "ServiceNow Incident" or a tag | Correlation reference |
| short_description | System.Title | Prefix with the incident number if helpful |
| description | Microsoft.VSTS.TCM.ReproSteps | Bugs use Repro Steps rather than Description by default |
| priority (from impact and urgency) | Microsoft.VSTS.Common.Priority and Severity | Map P1 to Priority 1 and Severity 1 - Critical |
| assignment_group | System.AreaPath | Routes to the correct team backlog |
| cmdb_ci | Custom field or tag | Identifies the affected service or application |
| work_notes | Discussion (System.History) | Troubleshooting history so far |
| Attachments | Attachments | Screenshots and logs, within size limits |
Immediately after creation, the work item ID is written back to the incident, typically into the correlation_id field or a custom field. From this point, both records reference each other.
How this works in ZigiOps
In ZigiOps, the table above is the field mapping of a create operation from ServiceNow to Azure DevOps. Conditional mapping turns the incident priority, which ServiceNow derives from impact and urgency, into Azure DevOps priority and severity, and can route each assignment group to its area path. ZigiOps then stores the correlation reference on both records, so later updates reach the right pair.
Stage 3: Developer picks up the bug
A developer sets the bug to Active and starts investigating. The integration updates the incident:
- A work note such as "Azure DevOps Bug 4821 is now Active, assigned to the Payments team."
- Optionally, the incident state moves to "In Progress" if it was "On Hold - Awaiting Development".
Comments flow both ways. A developer's question in the Azure DevOps Discussion appears as a work note in ServiceNow, and the service desk's answer comes back. Customer-visible additional comments in ServiceNow should not be filled automatically from developer discussion. ZigiOps reads comments and work notes from ServiceNow's journal fields and can write Azure DevOps discussion back as work notes only, with conditions that skip the integration user's own entries.
Stage 4: Pull request and build
The developer creates a branch and a pull request linked to the bug. Azure DevOps records these links on the work item. Developers do not need to tell anyone; the integration can surface the progress:
- When a linked pull request is completed, a work note informs the service desk that a fix is in review or merged.
- When a build containing the fix succeeds, the build number can be written to a field on the incident.
Not every integration tool reads pull request and build links. If yours does not, a simpler alternative is to have developers set the bug to Resolved when the fix is merged, which triggers an update in ServiceNow.
Stage 5: Release and deployment
This is the stage most integrations skip, and it is the one that matters most to the service desk. A merged fix is not a deployed fix. The incident should only move toward resolution when the release reaches production.
There are two common ways to capture this:
- Work item state: the team's process moves the bug to Closed only after production deployment. The integration maps Closed to the incident's "Resolved" state, or to a "Fix Deployed" work note.
- Pipeline-driven updates: a stage in the Azure Pipelines release, after production deployment, updates linked work items or calls ServiceNow directly. ServiceNow also offers DevOps Change capabilities that link pipelines to change requests, which some organizations combine with incident sync.
Either way, the incident should receive the release name or build number, the deployment date and a resolution note that the service desk can use with users.
Stage 6: Incident resolved
The service desk verifies with the user that the payment page works, sets the resolution code and resolves the incident. The integration can then add a final comment to the Azure DevOps bug confirming that the incident is resolved, which closes the loop on both sides. If the user reports the problem again, reopening the incident should reopen or flag the bug rather than create a new one.
The full data map
| Stage | ServiceNow to Azure DevOps | Azure DevOps to ServiceNow |
|---|---|---|
| Escalation | New Bug with title, repro steps, priority, area path, attachments | Work item ID |
| Investigation | New work notes and attachments | State Active, Discussion comments as work notes |
| Fix in progress | Priority changes | Pull request completed, build number |
| Deployment | None | State Closed, release or build, deployment date |
| Resolution | Incident resolved comment | None |
| Reopen | Reopen flag or comment | State change to Active |
State mapping
ServiceNow incident states (New, In Progress, On Hold, Resolved, Closed, Canceled) and Azure DevOps Bug states (New, Active, Resolved, Closed in the Agile process) do not line up one-to-one. A workable mapping is:
- Azure DevOps New: incident On Hold with reason "Awaiting Development".
- Azure DevOps Active: incident In Progress.
- Azure DevOps Resolved: incident stays In Progress, with a work note that the fix is merged.
- Azure DevOps Closed (deployed): incident Resolved, or a work note prompting the service desk to verify and resolve.
In ZigiOps, a mapping like this is configured with conditional mapping in the update operation from Azure DevOps to ServiceNow, with a fallback condition for any state you did not plan for. Many organizations prefer the last option, letting a human resolve the incident after confirming with the user. Remember that ServiceNow usually requires resolution code and resolution notes when resolving, so the integration has to fill them or leave the final step to an agent.
Handling major incidents differently
A priority 1 incident behaves differently from a routine bug. Speed matters more than process, and many people are involved at once. A few adjustments help the integration support major incident management instead of getting in the way:
- Create the bug immediately. For P1 incidents, trigger the work item on creation or on major incident promotion, not only on assignment, so engineering is involved from the first minute.
- Sync more often. If your tool polls rather than receiving events, check whether it can run more frequently, or rely on service hooks in Azure DevOps and business rules or flows in ServiceNow for near real-time updates.
- Keep communication in one place. The major incident manager writes updates for users in ServiceNow. Developers write technical findings in the Azure DevOps Discussion. The integration links the two without mixing audiences.
- Capture the post-incident review. After resolution, a problem record in ServiceNow and a follow-up item in Azure DevOps (for example, a root cause fix or a monitoring improvement) should be linked the same way, so preventive work is visible to both sides.
What not to sync
Just as important as what travels is what stays local. Assignees usually stay separate because people exist in one system but not the other. Azure DevOps fields such as remaining work, original estimate and iteration path mean little to the service desk. ServiceNow fields such as caller, contact type, location and SLA details mean little to developers and may include personal data. Leaving these out keeps the integration simpler, faster and easier to maintain.
Implementation checklist
- Create dedicated integration accounts in ServiceNow and Azure DevOps with the minimum required roles and permissions.
- Add correlation fields: the work item ID on the incident and the incident number on the work item.
- Map assignment groups to Azure DevOps projects and area paths.
- Agree on the state mapping, including what "deployed" means for your team.
- Decide how comments and work notes travel, and filter out the integration user's own updates.
- Test the full loop in sub-production, including reopen, attachments and parallel incidents.
- Monitor errors and expiring credentials, especially Azure DevOps personal access tokens.
Integration options
ServiceNow offers an Azure DevOps spoke through IntegrationHub, which works well for ServiceNow-driven flows when you already have the subscription. A standalone no-code platform such as ZigiOps focuses on two-way synchronization, including updates from Azure DevOps back to ServiceNow, and ships with ready-made templates for common incident and work item flows. ZigiOps connects through both systems' APIs, installs nothing inside either platform and does not store the transferred data. Other sync tools such as Exalate or Getint, and iPaaS tools such as Workato, are also used. Custom integrations use the ServiceNow Table API and the Azure DevOps REST API, with service hooks for event-driven updates. Test whichever option you choose against the full loop above, not just incident-to-bug creation.
Frequently asked questions
How do I connect Azure DevOps with ServiceNow?
Use the ServiceNow Azure DevOps spoke, a dedicated integration platform or a custom integration on both REST APIs. Create integration accounts, add correlation fields, map incidents to bugs and statuses to states, and configure updates in both directions.
Can Azure DevOps work items update ServiceNow incidents automatically?
Yes. With two-way integration, state changes, comments and release information from Azure DevOps update the linked incident, typically as work notes and field changes.
Can ZigiOps sync ServiceNow and Azure DevOps in both directions?
Yes. ZigiOps creates Azure DevOps work items from ServiceNow incidents and syncs states, comments, work notes and attachments in both directions, all configured in a no-code UI.
Should the integration resolve incidents automatically?
It can, but many teams prefer to let the service desk resolve after confirming with the user. A work note or state change that signals "fix deployed" is often the better final automated step.
How do I sync Azure DevOps work items with ServiceNow without duplicates?
Escalate only one record per problem (a parent or problem record), store correlation IDs on both sides, and have the integration check them before creating new work items.
Which Azure DevOps field holds the incident description?
For Bug work items, the default field is Repro Steps (Microsoft.VSTS.TCM.ReproSteps) rather than Description.
Key takeaways
- A ServiceNow Azure DevOps integration should close the loop, not stop at creating a work item.
- Use assignment groups and area paths to route incidents to the right team.
- Send pull request, build and deployment information back so the service desk knows when the fix is live.
- Map states carefully, and decide whether a human or the integration resolves the incident.
- Test the full incident-to-fix loop, including reopen scenarios, before going live.
- No-code platforms such as ZigiOps let you configure triggers, conditional mapping and both update directions in a UI, which makes the loop easier to change as processes evolve.