Community resources
Community resources
Community resources
JSM ServiceNow integration: 5 questions to settle before go-live
A JSM ServiceNow integration is a two-way sync between Jira Service Management issues and ServiceNow records. Incidents, changes, problems, RITMs, catalog tasks, and in some setups CMDB entries.
Disclosure first: I work with Exalate, and we build one of the integration apps in this category.
Connectivity is almost never the thing that fails. Both platforms have decent REST APIs, both are stable, and a proof of concept usually works inside a day. The failures come from field mapping, identity models, and permissions, and they show up once everything is in production.
Here are the 5 issues that come up most often.
Why does the assignee come across as an unreadable string?
Because Jira Cloud identifies users by accountId and ServiceNow identifies them by sys_id. Neither is human readable, and neither means anything to the other system.
An IT systems admin at a US insurance carrier described their native ServiceNow to Jira setup to us like this: they couldn't even sync the assignee, because it landed in Jira as a hash-tagged primary key. That wasn't a bug in their config. Atlassian removed username and userKey from the Jira Cloud REST APIs back in 2019 for GDPR reasons, and accountId is the only supported identifier now.
The Atlassian user privacy API migration guide has the full details.
The workable approach is to match on email address at sync time and resolve the ID on each side, rather than storing a mapping table. Email is the one attribute both systems agree on, assuming your users exist in both.
If a user only exists on one side, decide the fallback before you go live. A default assignee per assignment group works better than letting the sync error out.
What happens when someone closes the ServiceNow incident first?
The sync errors out because ServiceNow ACLs make closed incidents read-only.
One of our users hit this in a way I still think about. Their Jira Service Management instance was suspended for 6 days over a payment processing error they faced. Nothing synced for almost a week. When the backlog finally flushed, a chunk of the matching ServiceNow incidents had already been closed by their agents, and every one of those updates failed against the ACL.
You have 2 options here, and you should pick one deliberately. Filter closed records out of the sync so the queue stays clean, or let the errors surface so somebody knows a ticket went out of alignment. That user chose the second, and I think they were right. Their reasoning was that if it happens, they'd rather be notified than have it silently ignored.
Silent divergence between an incident and its linked Jira issue is worse than a visible error.
Should you pre-map ServiceNow assignment groups?
No. Resolve them at runtime with an HTTP call to the ServiceNow Table API instead.
Pre-mapping means every new assignment group is a config change on both sides, and in a large ServiceNow instance those groups change constantly. Our solution engineers do a GET against the group table during the sync and fetch the ID for the group name that came across. The same pattern works for any reference field.
One insurance company we worked with routes assignment group resolution this way across their whole connection, and their integration config hasn't needed touching as groups shifted underneath it.
This is also the reason the Table API matters more than the front-end scripting layer. Table API calls go to the backend, so client-side scripts and UI policies don't interfere with what your integration writes.
How do you keep PII or PHI out of the sync?
Filter at the field level on the sending side, before the payload leaves the system.
The common pattern is a public-facing service desk in ServiceNow and internal engineering in Jira, which means customer data sits in the ServiceNow description field and has no business being in a Jira issue. A regex filter on the outgoing side catches things like social security numbers, addresses, and account references and strips or blocks them.
We did this for a Canadian provincial health authority syncing between ServiceNow and Jira, and it passed a fairly brutal security review. The architectural point that made it work: the sync layer only ever handles metadata about which record maps to which record. It doesn't warehouse the ticket content.
If you're in healthcare, insurance, or finance, ask any vendor in this space exactly what their system stores and for how long. It's a short question, and the answer tells you a lot.
Should you just build this yourself?
Depends on what you're syncing, and the honest answer is that a one-directional escalation flow is worth building yourself.
ServiceNow's IntegrationHub Jira Spoke handles that case. It needs an IntegrationHub subscription on commercial instances, and ServiceNow owns the flow logic, so your Jira admins have no independent control over what crosses. For a simple "create a Jira issue when this incident is P1" rule, that's fine.
It stops being fine when you need 2-way updates with different workflows on each side. A European telco we spoke with abandoned their ServiceNow webhook build after concluding the maintenance cost was too high.
A ServiceNow consultant described the effort involved in doing this properly through the Jira Spoke as insane. Another user scoped an in-house REST API build at under 20,000 EUR, which is credible for version 1 and says nothing about year 3.
The costs that get missed are API version changes, attachment handling, rich text conversion between ServiceNow HTML and Jira's ADF, timezone handling, and error recovery when one side is down. Every one of those is boring, and none of them are optional.
Who should own the integration logic?
Both sides, independently. This is the part I care most about, and it's where I think the whole category gets it wrong.
Most integration tooling puts one platform in the driving seat. Somebody's admin owns the mapping, and from that point the other team's workflow is a downstream dependency. That works while both teams sit in the same org chart. It falls apart the moment the ServiceNow instance belongs to a customer, a supplier, or a company you just acquired.
We see this constantly: an airfield services company whose contract obliges them to log critical issues in the customer's ServiceNow, a cybersecurity firm syncing alerts into a client's instance, service desks feeding 20 different vendor systems. In all of those, neither side will accept the other defining what data leaves their system.
So the question worth asking during evaluation isn't just whether the tool syncs the fields you need. Ask what happens when the other team changes their workflow without telling you, and whether your side of the config keeps running.
Quick summary
- Field mapping, identity, and permissions cause most JSM ServiceNow integration failures, not connectivity.
- Match users on email because accountId and sys_id will never line up.
- Decide upfront whether closed ServiceNow records get filtered or throw visible errors.
- Resolve assignment groups at runtime through the Table API rather than pre-mapping them. Filter PII on the sending side before it crosses.
- Build it yourself if the flow is one-directional and simple, and buy if both sides need independent control over their own configuration.
If you want to look at the Exalate side of this, the app is on the Atlassian Marketplace: Exalate Connector for Jira.
Curious what's broken in your setup. If you're running JSM against ServiceNow today, what's the mapping that keeps biting you? I'll answer in the comments.