If your team runs more than one ticketing system, you already know the problem. A ticket gets raised in ServiceNow by the enterprise client. Your engineers are working in ConnectWise. Someone has to manually copy the update across. Or they forget to. Or they copy it wrong. By the time the ticket closes, nobody's sure which system has the accurate record.
This is one of the most common operational headaches for MSPs managing enterprise accounts, and for internal IT teams that sit between a corporate ITSM platform and their own service desk. The systems don't talk to each other, so your people become the connector — which is expensive, error-prone, and hard to scale.
Ticket synchronisation solves this. Here's how it works, what it actually involves, and what to look for when you're evaluating your options.
Ticket synchronisation means that a ticket created or updated in one platform is automatically reflected in another. Changes flow in both directions — not just from A to B, but from B back to A as well. When an engineer updates the status in ConnectWise, that update appears in ServiceNow. When the client adds a note in Jira, it comes through to Halo PSA.
This is distinct from a one-way integration or a webhook that pushes data in a single direction. True bi-directional sync means both systems stay current throughout the life of the ticket, regardless of which side is being worked on.
It also means the two systems don't need to share the same data structure. A "priority" field in ServiceNow might map to "urgency" in ConnectWise. A status called "In Progress" on one platform might correspond to "Work Started" on the other. Good ticket sync handles this field mapping so that the data stays meaningful on both sides, rather than just copying raw values that mean nothing in the target system.
Enterprise clients increasingly have their own ITSM platforms — ServiceNow is the most common, but Jira Service Management, Freshservice, and ManageEngine Service Desk Plus all appear regularly. These clients want all their IT work tracked inside their own system. They're not going to use your PSA.
At the same time, your delivery team lives in their PSA — ConnectWise, Autotask, Halo PSA, Syncro. That's where time gets logged, SLAs get tracked, and billing gets generated. You're not moving off it either.
So you need both systems to reflect the same reality, without your engineers working in two places or your account managers manually reconciling records. Ticket sync is what makes that possible.
The same issue comes up for enterprise IT teams that use a corporate ITSM for end-user requests but manage infrastructure or development work in Jira. Or teams that acquired a company running a different platform and need both systems to interoperate during a transition.
There are a few moving parts to a ticket sync configuration. Understanding these helps you evaluate whether a given tool will actually handle your environment.
Each platform needs to be connected via its API. Most modern ITSM and PSA tools expose REST APIs, but the authentication methods vary — API keys, OAuth, basic auth with tokens. A sync platform needs to support the specific auth method for each of your platforms and maintain that connection reliably over time, including handling token refresh and credential rotation.
This is where most of the configuration work happens. You need to define which field in Platform A corresponds to which field in Platform B, and how the values translate. Status mappings are almost always required — "New" in one system might be "Open" in another. Priority levels often differ. Some platforms have fields that simply don't exist on the other side, and you need to decide what to do with that data.
Custom fields add another layer of complexity. If your client uses a custom field in ServiceNow to track their internal reference number, and you need that number visible in ConnectWise, your sync configuration needs to handle that explicitly.
Not every field needs to sync in both directions. You might want ticket status to flow from your PSA to the client's ITSM, but not the reverse. You might want notes to sync bi-directionally, but only if they're marked as external-facing. A well-configured sync gives you control over what triggers an update and which direction it flows.
If a field is updated on both sides before the sync runs, you need a rule for which value wins. Timestamp-based logic (most recent update takes precedence) is common, but some scenarios call for platform-specific precedence — for example, status changes from the client's ITSM always win, because that's their system of record for SLA purposes.
Syncing structured fields is one thing. Syncing attachments and notes is harder, because these often aren't part of a platform's core ticketing API or carry different metadata. Whether attachments sync, and in which direction, is worth confirming specifically rather than assuming.
If you're evaluating tools, here are the questions worth asking.
Does it support your specific platforms? Not all integration tools cover the same set of ITSM and PSA platforms. If you need ConnectWise to ServiceNow, confirm both are supported natively — not via a generic webhook adapter that you'd have to configure yourself.
Is it truly bi-directional? Some tools sync in one direction only, or require a separate configuration for each direction. Make sure bi-directional sync is a first-class feature, not an afterthought.
Can it handle your field mapping complexity? If you have custom fields, non-standard statuses, or platform-specific data structures, you need a tool that supports flexible field mapping — not just a fixed template for common fields.
How are errors surfaced? Sync failures happen. An API goes down, a field value doesn't match the expected format, a permission changes. You need visibility into what failed and why, so you can fix it without relying on a support ticket to the vendor.
What's the latency? Near-real-time sync (under a minute) matters for SLA-sensitive environments. Batch sync that runs every few hours is fine for some use cases but can create problems when clients are checking their portal for updates.
How is it priced? Many integration platforms charge per connection, per ticket volume, or per user. If you're managing multiple client relationships, per-relationship pricing with volume tiers tends to be easier to forecast than per-ticket models.
An MSP using ConnectWise Manage takes on an enterprise client whose internal IT runs ServiceNow. The client's service desk team raises incidents in ServiceNow for anything the MSP needs to handle. The MSP's engineers work exclusively in ConnectWise.
With ticket sync in place, when the client raises an incident in ServiceNow, a corresponding ticket is created automatically in ConnectWise — including the description, priority, and any custom reference fields the client uses. When the engineer updates the status or adds a note in ConnectWise, that update flows back to ServiceNow, visible to the client's team in their own portal. When the ticket is resolved in ConnectWise, it closes in ServiceNow.
Neither team changes how they work. The sync runs in the background, keeping both records current. SLAs are tracked correctly because the client's ServiceNow record reflects real-time status. Time logging and billing happen in ConnectWise as normal.
If you're running two platforms today and managing the gap manually, the first step is mapping out what data actually needs to move. Not every field matters. Start with the ones that drive SLA compliance and client visibility — status, priority, and notes — then layer in additional fields once the core sync is working.
Support Fusion is built specifically for this. It connects MSP PSA platforms with enterprise ITSM systems bi-directionally, with configurable field mapping and real-time sync. Supported platforms include ConnectWise, ServiceNow, Jira, Halo PSA, Autotask, Freshservice, Syncro, ManageEngine Service Desk Plus, and Zendesk.
If you're evaluating options or want to understand what a sync configuration would look like for your specific platforms, get in touch with the Support Fusion team.