How do you keep JSM, ServiceNow and Freshservice in sync without copy-pasting tickets across systems

[Syed Majid Hassan -Exalate-]

I'm Majid, Support and Services Head at Exalate. This is a pattern I see almost every week in conversations with Jira admins: you're running 3 ITSM tools at once, and the integration between them is manual, fragile, or both.

JSM for your internal engineering and platform teams. ServiceNow for enterprise IT and CAB approvals. Freshservice for an acquired business unit or an MSP partner managing field office endpoints. All 3 legitimate. All 3 in use at the same time.

Here's what that looks like in practice before anyone fixes it.

Can one Jira admin manage connections to ServiceNow and Freshservice without admin access to those systems?

Yes. This is the part that matters most for JSM admins in this situation.

Exalate runs each side of a connection independently. Whoever owns the JSM side decides what leaves JSM and what comes in. Whoever owns the ServiceNow side controls their end. Same for Freshservice. No system hands credentials to another team. No one gets access they shouldn't have.

For the setup I'll describe below, the Jira admin logged into exalate.app to manage all 3 connections from one console. They never needed ServiceNow admin rights or Freshservice credentials. Each team kept governance of its own tool.

The setup: three ITSM tools, one very tired admin

The team I'll talk about runs a global IT operation. Roughly 300 support agents, a mix of internal IT and external MSP partners. Here's how the tools broke down:

• JSM (Jira Service Management): Used by the in-house dev and platform engineering teams. Incident management, service requests, and change management workflows all live here.
• ServiceNow: The enterprise IT system of record. Change Advisory Board (CAB) approvals, problem management, and the CMDB.
• Freshservice: Used by a recently acquired business unit and a couple of MSP partners managing endpoints for the field offices.

Before Exalate, the workflow looked something like this:

1. End user logs a ticket in Freshservice with the MSP.
2. MSP agent figures out it's a platform issue, not an endpoint.
3. Someone manually opens a ServiceNow incident and copies and pastes the context.
4. ServiceNow team escalates to the dev team by creating a JSM work item, again with copy-paste.
5. Updates from JSM never make it back. The end user calls again. Everyone loses a Tuesday afternoon.

What they actually needed

Pretty simple on paper:

• Incidents from Freshservice should escalate to ServiceNow when they need ITIL change management.
• ServiceNow incidents that turn out to be bugs or platform issues should land in JSM as work items.
• Comments, attachments, statuses, and SLA info should flow in real time across all three.
• The Jira admin (who didn't have ServiceNow or Freshservice admin access) should be able to see what's syncing and tweak the rules without raising a ticket with another team.

Important detail: each system needed to keep its own governance. The ServiceNow team wasn't going to give JSM admins full ServiceNow access, and the MSP wasn't going to hand over Freshservice credentials. Whatever the integration was, it had to respect that.

Why Exalate fit

Exalate handles each side of the connection. Whoever owns the Jira side decides what leaves Jira. Whoever owns the ServiceNow side decides what gets in. Same for Freshservice. Nobody has to give up their tool's credentials to the other team.

A few specific things that mattered for this case:

• Unified management. One console (logged in via exalate.app) to oversee all three connections. The Jira admin could see the JSM ↔ ServiceNow, JSM ↔ Freshservice, and ServiceNow ↔ Freshservice connections side by side.
• Aida (AI-assisted configuration) and troubleshooting. Aida generates the sync scripts from plain-English prompts like "map ServiceNow urgency 1 to JSM Highest priority." Plus, it also helps diagnose errors in plain language. 
• Test run. Let's you validate a sync against real data before publishing to production. Nobody wants their first sync to flood JSM with multiple incidents from last quarter.
• Script versioning. Every publish creates a new version, with a full audit trail and rollback. The compliance team liked this.

How do you set up a 3-way ITSM integration with Exalate?

The flow is the same as the standard Exalate ramp-up: 

1. Sign up for Exalate.
2. Connect each system using the following authentication methods: JSM (OAuth), ServiceNow (username and password), Freshservice (API token). 
3. Build three connections:
   • JSM ↔ ServiceNow (for dev escalations and CAB-tracked changes)
   • JSM ↔ Freshservice (for the acquired business unit's bug reports)
   • ServiceNow ↔ Freshservice (for MSP-escalated incidents that need ITIL)
4. You can set different sync rules and automation logic per connection. I have seen this work very well for MSPs who want to scale their operations for multiple clients. 
5. Use Aida, the built-in AI assistant, to draft your initial sync scripts. You describe what you want in plain English, for example, "Map Freshservice ticket priority to ServiceNow urgency, and only sync tickets with the label 'platform'." Aida generates the Groovy script. You can edit it or publish it as-is.
6. Run a test run on each connection to confirm nothing leaked or got mis-mapped.
7. Add triggers (JQL on the JSM side, advanced search syntax on ServiceNow, ticket filters on Freshservice) so only the right tickets start syncing.
8. Publish for tickets to start flowing.

Each connection has independent sync rules. A ticket labeled "platform" in Freshservice goes to ServiceNow. A ServiceNow incident escalated to the dev team lands in JSM. Comments, attachments, statuses, and SLA fields all sync in real time across whichever connections you configure them on.

For the full step-by-step on workspaces and connection setup, the Jira ServiceNow integration guide covers the approach in detail. The Freshservice flow is identical, just swap the system and use an API token instead.

Where ITSM integration paid off with Exalate 

A few real outcomes from the first few months after going live:

• Incident escalation time dropped. A Freshservice ticket that previously took 2-3 days to make it into JSM (with full context) was landing in under a minute. The MSP team kept working in Freshservice. The platform team kept working in JSM, and nobody learned a new tool.
• Compliance got its audit trail. Every script change, every connection update, every sync action was logged. When the ServiceNow team asked, "Who changed the priority mapping rule last time?" there was an answer.
• No more PII leaks. The team configured the Freshservice side to strip customer email addresses before sending tickets to JSM. JSM never saw end-user PII, which kept the security team happy.
• The Jira admin stopped being the bottleneck. Before, every cross-tool ticket required a manual handoff. After, the admin spent maybe an hour a week tweaking sync rules, mostly adding new triggers as new request types came online.

This kind of setup also scales well for MSPs managing multiple clients: the same star-topology approach works when you have one hub system and many external systems routing to it based on a field value or label. I've seen this covered in more detail in the MSP scaling post from earlier this year.

Is this the right approach if you're already using Jira automations?

Worth clarifying, because this comes up. Jira automations handle logic inside a single Jira instance. They don't sync data to ServiceNow or Freshservice. If your escalation path crosses systems, automation rules won't cover it. The Jira Admin's Integration Toolkit post has a solid decision framework for when native automations are enough and when you need a dedicated integration layer.

For 3-system ITSM stacks, a dedicated integration layer is usually the right call.

Before you try this

A quick summary of what to check before you start:

You need at minimum: JSM admin access, a ServiceNow account with ITIL roles (not full admin), and a Freshservice API token. You don't need admin access to systems your team doesn't own.

Decide your sync scope before you build. Know which ticket types trigger a cross-system sync, which fields travel with them, and which fields stay private. Aida can help you draft the logic, but the business rules need to come from you.

Test before you publish. The Test Run feature exists for a reason; use it on every connection before going live.

You can find Exalate on the Atlassian Marketplace.

Happy to answer questions if you're working through a similar multi-system setup.