A support team recently came to us with a setup that looked simple on paper. They had one Freshdesk service desk, used by their end customers, and two separate Freshservice environments behind it, run by teams in two different countries.
They wanted to use Freshdesk's native connector, but it supports only one Freshservice instance at a time. So every ticket meant for the other region got forwarded manually, with no history attached and no easy way to tell whether anyone had picked it up.
This is a common problem faced by a lot of teams with large service desks and ticket volumes. You start with one tool talking to another tool. Then a second team, a second region, or a second vendor shows up on the other end, and the clean one-to-one connector struggles to cover the scope.
Why Native Connectors Don’t Always Work
Most native integrations, and a lot of low-code connector tools, assume a single source and a single destination. That works until an organization needs to split traffic: US tickets to one backend, EU tickets to another, or engineering tickets to Jira while billing tickets go to a separate ServiceNow queue.
When the native option fails, the fallback is usually manual forwarding or a small, custom script written by the in-house engineering team.
At the same time, forwarded tickets lose their history, which forces the receiving side to hunt around for the original resolution to close the loop. And when volume is low (a few tickets a week isn't unusual in these setups), the coordination overhead ends up bigger than the ticket volume itself.
Teams also look for alternatives once a native connector turns out to be too rigid or too expensive, and once an internal script becomes a maintenance headache.
How Exalate Handles One-to-Many Routing
Exalate is a bidirectional integration solution that allows users to connect two systems in order to share data in real time.
A Freshdesk instance can hold 2, 3, or more separate connections at the same time, each one pointed at a different destination system and each with its own sync rules.
This is the same underlying mechanism that lets a single Jira instance stay connected to multiple Jira instances at once. It just works the same way when the destinations are Freshservice, ServiceNow, or Azure DevOps instead.
Within the Exalate console, you can configure complex configuration scenarios to sync statuses, comments, inline images, custom fields, and more with the help of a Groovy scripting engine. You can also use Aida AI to generate the scripts from a natural language prompt.
Exalate also supports script versioning, test runs, and AI-enabled troubleshooting for those who want closer control over how the sync connection works.
With Exalate, each connection can also be controlled by a trigger, which is the condition that decides whether a given ticket or field should be escalated.
Triggers use the source platform's own search or filter syntax, so a Freshdesk trigger might look for a specific tag, and a ServiceNow trigger might filter on a category field. Each connection only picks up tickets that match its own filter, so nothing has to guess where a ticket belongs.
The Sync Panel Chrome extension helps you unlink and view sync errors right from your browser. You can also visit the dashboard for a consolidated view of all active syncs within your ecosystem.
Step 1: Create a Separate Connection for Each Destination
After signing into your account, or signing up with social sign-in, set up a connection between the two systems: Freshdesk to the US Freshservice instance, and the same Freshdesk instance to the EU Freshservice instance.
A few things worth deciding upfront for each connection:
- Which issue types are in scope. (tickets = Incidents and Service Requests).
- Which fields sync in both directions: ticket summary, status, comments, attachments, assignee, and whatever custom fields the receiving team actually uses.
- Whether attachments need to flow both ways or just one way, since some teams only need the destination system to see files, not send them back.
- How the statuses are mapped for each system.
Step 2: Map Fields and Keep Comments in the Right Lane
Use the Aida AI assistant in the scripting console to dictate how standard and custom fields in the tickets should interact.
Comments are usually the trickiest part. A public reply from a Freshservice agent needs to land back in Freshdesk as something the end customer can see, while internal notes stay internal. That distinction has to be set explicitly in the sync rule, since the two platforms don't share the same idea of "internal" by default.
Custom fields need the same attention. A field that exists in Jira but not in ServiceNow (or the other way around) either needs a matching field created on both sides or a fallback that flattens it into a plain text value.
Step 3: Add a Trigger So Each Connection Only Picks Up Its Own Tickets
On the US connection, the trigger filters for a tag or field value that marks a ticket as US-owned. On the EU connection, it filters for the EU equivalent. A ticket tagged for the EU team never gets picked up by the US side, even though both connections are watching the same Freshdesk desk.
Exalate triggers in Freshservice and Freshdesk both rely on field-based filter queries with logical operators. You can delineate both ticket categories with a condition like tags:eu-team for the EU connection and tags:us-team for the US one.
Step 4: Test the Connection Before You Turn On Live Sync
Use Exalate’s Test Run functionality to figure out if the sync rules you’ve just configured have been implemented correctly.
Run each connection against a handful of real tickets before it goes live. Tag a few existing tickets for both, then check that each connection only ever picks up its own set.
What This Solves
Giving each destination its own connection, its own trigger, and its own rules keeps the routing logic visible, so each side only ever sees the tickets it should.
It also means the two connections can drift apart over time without breaking each other. The EU team can add a custom field or change how they tag priority without touching whatever the US connection is doing. Compare that to a single script trying to branch for both regions in one place, where a change meant for one side has a real chance of quietly affecting the other.
For a support desk splitting traffic across regions, or any setup where one system feeds several backends, that's the difference between a solution that someone has to maintain and a connection that runs automatically.
If your team is stuck forwarding tickets between systems, we're happy to walk through what a setup like this looks like for your stack.
Top comments (0)