I work for Exalate, and I lead support and services here. This post is a heads-up about a live session I'm running, not a sales pitch, so read on even if you've never touched our product.
Why do ITSM integrations between Jira and ServiceNow fail?
Almost every team has some version of a connection already, and almost every version breaks the same way eventually. I've worked with teams on every rung of this ladder: the ones scoping their first integration, and the ones unwinding one that's been running for two years.
On September 24, 2026, at 10:30 AM EST / 4:30 PM CET, I'm walking through five ways teams connect Jira and ServiceNow, where each one breaks, and what a durable fix actually requires.
The five approaches, and what they cost
- Manual handling. One team measured this at four hours a week of a product owner's time, moving information between ServiceNow and Jira and chasing status. That's over five working weeks a year, and evades standard budget lines. And this setup collapses when the person holding this together goes on annual leave.
- Email escalation. An 800-user service desk escalates to vendors by email and tracks both ticket numbers by hand in the subject line. A much larger enterprise automated the same pattern with rules crawling the replies, and still calls it patchwork. Email moves messages. It doesn't hold state, which is why you cannot get status updates by simply opening your mailbox.
- Automation platforms. One team runs Asana into Jira into ServiceDesk Plus through a Zapier-style chain. Their own verdict: "It works, but field updates don't reliably propagate." Chained automations fire on events. When a step doesn't fire, you cannot come back to it later.
- Custom scripts. One team built integration code inside both Jira Cloud and ServiceNow directly. They're replacing all of it, because maintaining that code across two platforms became a standing cost for two teams with other priorities. I'll also cover a 276-project environment where the in-house ServiceNow team offered to build it, and why that decision came down to bandwidth, not capability.
- Buying the wrong fit. A large media company bought an integration to bring ServiceNow work into Jira for time tracking and reporting. During onboarding, their own team realized part of what they needed was already reachable through ServiceNow directly.
What they have in common
All five fail in similar ways: they move events instead of holding state, nothing reconciles when a step fails so the gap just persists, and it’s difficult to notice the drift until the teams affected by it bring it up.
There's another reason too, and it isn't technical: nobody was assigned to own the integration after it went live.
What I'll cover for a durable approach
Both sides need to see the current state of the same item.
Failures need to be retried and re-aligned.
Drift needs to be visible before it needs to be manually caught by someone.
Related projects should be grouped rather than mapped one at a time.
A team member needs to own it by name. And phase one needs to be small enough to describe in a single sentence.
I'll show this across Jira, Jira Service Management, ServiceNow, and Azure DevOps, including cases where a built-in automation, or no integration at all, was the right call.
What you'll leave with
An honest read on which rung you're on and what it's costing you. A way to scope phase one so it ships well. A build-vs-buy checklist framed around ownership rather than capability.
The question I'll open with: what will someone do differently once this exists?
If you've got a scenario of your own on any of these five patterns, I'd like to hear it in the comments before the session.
