This guide walks both organisations through setting up a Support Fusion connection, from creating accounts to running a first test sync.

Note: The exact names of boards, queues, groups, and status values vary by platform. Where this guide uses those terms, use the equivalent in your own system.

Both sides register and get their platform ready before pairing, so the connection has everything it needs when you create it.

The source organisation (where tickets originate, often the client) needs API credentials for its ITSM/PSA platform, agreement on which ticket types will sync, and a default closure status or resolution code for tickets the partner closes. The target organisation (where tickets are received, often the IT partner) needs API credentials with access to the relevant boards or queues and company records, a board or queue for the client, and the client's company record created in its system.

The two organisations pair so they can sync. Either side can start; these steps assume the target (IT partner) leads.

Once accepted, the connection appears on both Settings pages.

Note: Source and target set the default direction of ticket flow, but you can enable bi-directional sync during integration configuration, so tickets originating on either side can sync to the other.

Each side configures its own settings independently from Integration configuration, after selecting the connection in the relationship selector.

The source chooses the group, queue, or team whose tickets sync, the ticket types to include, a default closure status, and which notes, comments, and attachments to share. If tickets can also originate from the partner side, enable bi-directional flow and select the incoming ticket type. The target chooses the board or queue incoming tickets are created on, the company record to assign them to, and the default values for new tickets (status, priority, source, or the equivalents on your platform). Save on each side.

Field mappings translate data between the two platforms. Set up a basic set before testing, then expand later. On the Field mappings page, select the connection and use Create field mapping for each pair: choose the ticket type, the source and target fields, and the direction. For picklist fields like status or priority, use value mapping to pair the values on each side.

A good starting set:

Note: For ServiceNow, incidents and tasks keep separate mappings, so configure the same set for each ticket type you sync.

Once configuration is in place, run an end-to-end test before relying on the connection.

After each run, the Sync page shows the results and any errors returned by the platform. If a ticket fails, the error usually points to the cause, such as a permission issue or an unrecognised value. If there's no error but data hasn't come through as expected, check the ticket directly on the platform, since some systems accept a request without applying every change.

Important: Sync runs manually until you enable automatic sync, and automatic sync requires billing to be set up on the account.

With the basic flow working, both sides can map the rest of the ticket data, such as impact and urgency, priority, assigned technician or contact, and attachments. Map one representative ticket from each category and test it before adding more, so you don't build out a full mapping that then needs reworking.

Note: When a requestor or caller maps to a contact on the target, Support Fusion matches by email to an existing contact. If there's no match, the name and email are written to the display fields (where supported) but no new contact is created, and tickets still flow. Pre-loading key contacts on the target before go-live improves contact quality on incoming tickets.

When your test sync looks right, move on to Testing your sync for a fuller check, then Going live to turn on automatic sync.