How to Integrate ServiceNow, Jira Service Management, and Azure DevOps
I want to share a practical walkthrough of how we helped a financial institution eliminate the manual handoffs and data loss that happen when tickets move across ServiceNow, Jira Service Management (JSM), and Azure DevOps.
The Problem
Picture this: A customer reports an issue through ServiceNow. Someone manually creates a ticket in JSM for the regional team. They realize it's a software bug and manually create another ticket in Azure DevOps.
Now you've got three tickets across three systems, and updates don't flow automatically.
Sound familiar? Okay, let me walk you through a live integration that connects all three platforms bidirectionally using Exalate.
The flow starts with an incident created in ServiceNow, which automatically syncs to JSM as a Service Request. If the ticket gets escalated, it creates a subtask that syncs to Azure DevOps, and all updates flow back through the chain.
Setting Up The Integration
The magic happens in the Exalate scripting engine with the help of Groovy scripts. In the outgoing sync, I'm controlling what gets sent with filters like excluding internal comments.
For the incoming sync, I'm mapping fields from ServiceNow to JSM, setting the summary, description, and mapping impact values to priority levels.
Exalate connects to the REST API of all these tools, which means that you can fetch and set virtually any field available in any of these platforms.
For Jira, you can sync fields from tasks, tickets, epics, and sprints. ServiceNow users can sync almost anything, while Azure DevOps managers can sync work items and projects bidirectionally.
The Sync Implementation and Results
Starting in ServiceNow, I created an incident assigned to the “Database” group with a short description, "Issues with new ITSM software," and medium impact. The trigger fires when the assignment group is populated, the ticket is active, and there's a caller assigned.
Within about 20 seconds (the average polling interval), the ticket appeared in JSM with the summary and description synced, status mapped appropriately, and an internal comment added noting "This ticket has been requested on behalf of [caller name] from ServiceNow."
This caller tracking is crucial because your JSM team can see who the actual end user is, even though the ticket came from ServiceNow.
When I added a public comment in JSM, it automatically appeared in ServiceNow's notes section. The sync respects comment types, so public comments stay public and internal comments become work notes (though you can configure this differently).
I then changed the priority in ServiceNow from “Medium” to “Critical”. Within 20 seconds, the priority was updated to “Critical” in JSM. The flexibility here is powerful because you can exclude certain comment types or customize exactly what syncs between systems.
Status Updates and Resolution
Here's where it gets interesting. When the JSM team escalated the ticket by moving it to "Escalation" status, Exalate automatically created a subtask in JSM, synced that subtask to Azure DevOps, and added an internal comment in ServiceNow.
Now your dev team in Azure DevOps can work on their ticket while updates flow back through JSM to ServiceNow.
When the Azure DevOps team updated the priority, it reflected in JSM and can flow to ServiceNow. Their comments appeared in JSM, and when they marked the ticket as Done, the JSM subtask was marked as Done too.
The Jira team then resolved their ticket with a comment to the customer. This updated ServiceNow to "Resolved" with the customer-facing message visible in the notes.
We configured it so that when ServiceNow closes the ticket, it automatically stops the sync (“un-Exalates” it). This prevents unnecessary noise by stopping further updates from flowing back.
Handling Configuration Errors
During the demo, ServiceNow threw an error about mandatory fields (close notes). Instead of the sync failing silently, I checked the error in the sync status, updated the incoming script to include the required field, and re-synced successfully.
This kind of real-time troubleshooting is possible because you have complete visibility into what's happening at each step.
Key Takeaways
Bidirectional syncing works out of the box with no one-way limitations. The flexible Groovy scripting lets you handle any edge case that comes up. You get full control over comment types to decide what's public versus internal.
Automatic escalation creates subtasks and routes them to different teams seamlessly. Since you have full API access, if the platform exposes something via REST API, you can sync it.
Do you have any 3-way integration scenarios?
I'd love to hear your experiences and thoughts. Check out the Exalate app to start your trial. Let's continue the conversation and explore what more can be done!