Note: This is a general overview. The specific names of objects, fields, and configuration options will vary depending on the platforms in use on each side. Where this guide refers to boards, queues, groups, or status values, use the equivalent terminology for your platform.
Step 1: Create Your Accounts
Both sides need to register before the setup session.
IT partner (ticket destination)
A Support Fusion account created at app.suppfusion.com/register
API credentials configured in your support platform with access to the relevant boards/queues and company records
A dedicated board or queue set up for the client organisation
The client company record created in your platform's system
Client organisation (ticket source)
A Support Fusion account created at app.suppfusion.com/register
API credentials configured in your ITSM platform following the setup instructions provided by Support Fusion
Confirmation of which ticket types will sync (incidents, tasks, or both)
A default resolution code or status agreed for tickets closed from the partner side
Step 2: Create the Connection
Once both accounts are set up and API credentials are in place, the two organisations pair with each other. Either side can initiate - these steps assume the IT partner is leading.
The IT partner opens the Settings page and clicks Create Connection.
Select Source or Destination as the role, depending on whether tickets will flow to or from your platform.
Enter a name for the connection - this is a free-text label used as an identifier. Click Create.
Copy the connection code that is generated and share it with the client organisation.
The client organisation opens their Settings page and clicks Create Connection.
Select Accept Connection, enter the code, and click Accept.
Once accepted, both sides will see the connection listed on their Settings page.
Note: The Source and Destination roles describe the default direction of ticket flow, but bi-directional ticket creation can be enabled during integration configuration. This means tickets originating on either side can sync across to the other, regardless of which role each organisation holds.
Step 3: Configure the Integration
With the connection established, each side configures their integration settings independently.
Client organisation (source)
Open Settings and navigate to Configure Integration.
Select the connection from the relationship selector.
Choose the queue, group, or team whose tickets should sync.
Select the ticket types to include (incidents, tasks, or both).
Set a default resolution code or closure status. This is applied when the partner side closes a ticket and no specific value is provided via field mapping.
Select whether to share internal notes, comments, and/or attachments with the partner.
If tickets can also originate from the partner side (bi-directional flow), enable that option and select the appropriate incoming ticket type.
Save settings.
IT partner (destination)
Open Settings and navigate to Configure Integration.
Select the connection from the relationship selector.
Select the board or queue that incoming tickets should be created on.
Select the company record that tickets will be assigned to.
Set default values for incoming tickets (status, priority, source, or equivalent fields in your platform).
Save settings.
Step 4: Set Up Field Mapping
Field mappings define how data is translated between the two platforms. A basic set of mappings is needed before testing. Additional mappings can be added iteratively once the initial flow is confirmed.
Adding a mapping
Open the Field Mappings tab and select the connection.
Click Add New Mapping.
Select the ticket type. Field mappings are configured separately for each type (e.g. incidents vs. tasks).
Select the source field and the target field.
Set the sync direction: source to target only, or bi-directional.
For pick list fields (such as status or priority), change the mapping type to Value Mapping and configure the corresponding values on each side.
Click Create.
Recommended starting mappings
Source field | Destination field | Type | Direction |
Ticket title / summary | Ticket title / summary | Direct | Source to target |
Description | Description | Direct | Source to target |
Status / state | Status | Value mapping | Bi-directional |
Requestor / caller | Contact | Direct | Source to target |
Note: Configure the same mappings for each ticket type you are syncing, since incidents and tasks maintain separate mapping configurations.
Step 5: Run an Initial Test
Once configuration is in place, run a basic end-to-end test.
The client organisation creates a test ticket, assigned to the configured group or queue.
On the Sync page, click Start Initial Sync. The time selector defaults to 30 minutes back, which is fine for a fresh test.
Confirm the ticket appears on the partner's board or queue with the correct status, title, and description.
Add a comment or internal note from the client side and run another sync. Confirm it appears on the partner side.
Add a comment from the partner side and confirm it appears in the client's ITSM.
Change the ticket status on one side and confirm it updates on the other.
Note: Sync must be triggered manually until automatic sync is enabled. Automatic sync requires a payment method on the account.
Reviewing sync results
After each sync, the Sync page shows the results of that cycle, including any errors returned from the API. If a ticket fails to sync, the error response should indicate the cause - for example, a permission issue or an unrecognised field value. If you see no error but data hasn't come through as expected, check the ITSM side directly. Some platforms will silently accept a request without applying all the changes, so it's worth verifying the actual ticket state rather than relying on a successful sync status alone.
Step 6: Expand Field Mapping
Once the basic test is working, both sides can expand field mapping to cover the full scope of ticket data.
A practical approach is to map one representative ticket from each category and test it before adding more. This avoids building out a full mapping that then needs to be revised.
Common additional fields to consider:
Impact and urgency
Priority
Assigned technician or contact
Attachments
A note about contact matching
When a requestor or caller field is mapped to a contact field on the partner side, Support Fusion will attempt to match by email address to an existing contact record. If no match is found, the name and email are written into the relevant display fields but no new contact is created. Tickets will still flow correctly. Pre-loading key contacts into the partner's system ahead of go-live will improve contact data quality on incoming tickets.