Most Jira and ServiceNow integration problems I see come down to 4 things: outdated records, failures that go unnoticed, missing ticket context, or unclear ownership.
The setup might work when it goes live. Then someone changes a workflow, renames a field, or leaves the team, and the sync needs attention.
I run support and services at Exalate, which builds integration software, including a Jira ServiceNow sync app. These observations come from the customer environments my team and I work with almost every week.
Sync Room: Episode 6
Jira and ServiceNow were the focus of episode 6 of Sync Room, our short webinar series on integration problems. My co-host Manoosh and I compared 5 common setups, discussed a customer’s experience, and demonstrated a live sync.
The discussion covered the problems admins, project managers, and QA and BA teams deal with once an integration is running.
Where ServiceNow IntegrationHub fits
IntegrationHub lets you build workflows inside ServiceNow that create and update Jira work items through spokes.
For ongoing two-way sync, you also need to account for updates coming back from Jira, conflicting changes, and failed deliveries. The amount of work depends on the behavior your teams need.
Ownership matters here too. When the integration logic lives in ServiceNow, Jira admins need a clear way to request changes and investigate problems with the team that maintains it.
What are the 5 ways teams connect Jira and ServiceNow?
1. Manual copy-paste
Your support agent updates an incident in ServiceNow, copies it manually into Jira, and brings the response back.
This can work at low volumes. It becomes difficult to maintain when the person handling the updates is away, or the number of tickets grows.
Their replacement may not know which comments to share, how priorities translate, or which tickets need immediate attention. A few hours of copying can gradually become a full-time responsibility.
2. Email
Teams often settle into email handoffs as they grow. One team sends an update, and someone on the other side reads it and changes the ticket.
Each update depends on someone reading the email, gathering the relevant content, and entering it correctly. Miss a thread, and Jira and ServiceNow can show different statuses for the same work.
Email preserves the conversation, but your team still has to work out which message reflects the current situation.
3. Automation platforms
Tools such as Zapier and Power Automate can move data when a trigger fires. Scripted automations can do the same.
Problems appear when the workflow doesn’t handle what happens after a failed update. An error may be logged without reaching anyone responsible for fixing it, leaving the receiving team waiting.
Check how your setup handles retries, alerts, and confirmation that the destination accepted the change. Those behaviors need to be configured and tested.
4. Custom integrations, including AI-assisted builds
AI tools can reduce the time it takes to write an initial integration. Your team still needs to test and maintain the code.
That includes handling API changes, expired credentials, duplicate updates, and recovery after an outage. Retries and alerting need the same attention as field mappings.
A custom build becomes difficult to support when the person who understands it leaves, or when maintenance keeps getting postponed.
5. Off-the-shelf integration apps
A dedicated integration app can reduce the work your team takes on, provided it supports your requirements.
Check the details before choosing one. Your teams may need specific comment visibility rules, custom fields, ticket relationships, or separate control over what each side shares.
If the app can’t support those requirements, you’ll spend time maintaining workarounds.
The 3 technical checks that matter
Every setup needs maintenance as Jira and ServiceNow change. These checks help you see where yours needs attention.
Current ticket state
Your team needs to trust the status, priority, and shared information in its own system.
Decide how quickly updates need to arrive and how you’ll identify delayed syncs. A support agent should be able to see whether development has started without asking someone to check Jira.
Recovery after failure
A failed update needs a clear recovery process.
Temporary failures should retry automatically where appropriate. Persistent failures should reach someone who has enough information to investigate, including the affected ticket and the reason the update failed.
Test what happens after access is restored or a mapping is corrected. You need to know whether pending updates resume and whether any require manual action.
Ticket relationships and context
A Jira work item may belong to an epic and reference a release or version. Those relationships can affect how the receiving team understands and prioritizes the work.
Define which context needs to cross between systems. Copying the description and status may leave out information the other team needs to act.
Someone needs to own the integration
Give someone responsibility for the integration after launch, including failures, configuration changes, and ongoing maintenance.
In postmortems, I’ve seen customer-facing teams escalate a P1 and wait days for progress because nobody was responsible for checking the handoff. Each team completed its local steps, while the request remained stuck between systems.
A field mapping can often be corrected once someone investigates it. Unclear ownership lets the failure continue because nobody knows who should investigate.
Your teams should know who receives an alert, who can change the configuration, and who checks that the affected tickets have recovered.
How LF Logistics connected ServiceNow and Jira
LF Logistics, now part of Maersk, used ServiceNow for its customer-facing service desk and Jira for delivery.
A person transferred information between the systems. When customers asked for updates, the service desk had to chase the delivery team to find out what was happening.
Both teams had established workflows. Moving everyone to one platform during an acquisition would have added cost and disruption, so they chose two-way sync.
Requests in ServiceNow reached Jira automatically. Statuses and selected comments synced according to the sharing rules, and each team controlled which information stayed internal.
When the delivery team resolved a Jira work item, ServiceNow updated so the service desk could respond to the customer.
Both teams kept their existing tools, and the person handling manual transfers could move on to other work.
What the live sync showed
For the demo, I used a ServiceNow incident about an expired certificate on a production server. The incident belonged to the Database assignment group.
I configured this flow in Exalate:
- Incidents assigned to Database synced to Jira automatically.
- Jira created a work item and returned its key and link to ServiceNow.
- A developer assigned the work item, moved it to In Progress, and commented, “We are checking the cert.” ServiceNow reflected the status and comment.
- I added an internal work note and a public comment in ServiceNow. The sharing rule sent only the public comment to Jira.
- I changed the ServiceNow priority to Critical. Jira updated to Highest within seconds.
- A custom customer sentiment field synced to its matching field.
- When the Jira work item moved to Done, the ServiceNow incident moved to Resolved.
The comment rule deserves attention. Your teams need to agree on which information they can share and test that internal notes stay where intended.
Define status mappings explicitly
Status mapping is a common early source of problems. Each team has its own workflow, so the receiving side needs to know how to interpret an incoming status.
In the demo, the ServiceNow incoming sync script handled the mapping. This simplified example shows the logic:
// ServiceNow incoming sync: map Jira statuses to incident states
def statusMap = [
"To Do" : "New",
"In Progress": "In Progress",
"Done" : "Resolved"
]
def remoteStatus = replica.status?.name
entity.state = statusMap[remoteStatus] ?: entity.state
If the incoming Jira status isn’t listed, the fallback preserves the current ServiceNow state. You’ll still need to review new statuses and decide how they should map.
The Exalate documentation for Jira and ServiceNow integration provides more detail on configuration and field sync.
Start with one flow
Identify how your teams exchange updates today and estimate the time they spend copying information, checking progress, and correcting missed handoffs. Include maintenance when you compare that cost with another setup.
Choose one flow to implement first, such as P1 incidents from a single assignment group. Agree on the fields and comments to share, define the status mappings, and name the person responsible for failures.
Test a failed update as well as a successful one. Check that the right person receives the alert and that the ticket recovers after the problem is fixed.
We phase customer implementations for this reason. Teams need time to verify the results and trust the sync before they stop checking through email and Slack.
You can find Exalate on the Atlassian Marketplace.
I’ll also be at Atlassian Team ’26 Europe in Amsterdam this October, at booth 403. Feel free to bring your Jira and ServiceNow setup, including the handoff that keeps causing problems.
