Helpdesk integration is the first thing you set up. Until Horizon can read tickets from your PSA and write back to it, nothing else matters — triage has nothing to triage, assignment has nothing to assign, scheduled todos have no tickets to attach to. This lesson walks through the integration pages and the order you set them up in.
Problem: Horizon adds a layer on top of your helpdesk — todos, scheduling, assignment, automation. That layer needs the underlying tickets, contacts, companies, statuses, and users from the helpdesk to attach itself to. Without the connection, the rest of Horizon is configuring rules against an empty dataset.
Horizon's answer: A bidirectional integration with your PSA. Horizon pulls tickets and reference data in, and pushes notes, status changes, time entries, and other updates back out. Once the integration is live, every other Horizon feature has something to operate on.
Supported helpdesks:
You pick one per account. Most teams stay on a single PSA — Horizon does too.
Open the admin panel and navigate to Integrations → Helpdesk. You'll find the following pages:
| Page | What it does |
|---|---|
| Helpdesk Configuration | the connection itself — credentials, sync settings |
| Helpdesk User Mapping | maps each helpdesk user to a Horizon user |
| Picklist Database | local cache of helpdesk picklists (statuses, types, priorities, queues) used throughout Horizon |
| Helpdesk Callback Status | live view of inbound webhook health from the helpdesk |
| Helpdesk Widget Status | health check for the dashboard and ticket widgets embedded in the helpdesk |
| Sync Run logs | audit trail of every sync operation Horizon has run |
| Callback Log | record of every inbound webhook the helpdesk has fired |
The recommended setup order is: configuration → user mapping → picklist database → widgets → callbacks → verify with sync run logs.
This is where Horizon learns how to talk to your PSA.
The form changes based on which helpdesk you pick:
Exact credential setup per PSA is in the per-helpdesk KB articles — this lesson covers the page itself, not the auth dance for each PSA.
Once credentials are saved, the page also exposes sync settings:
Tip: Start with a conservative ingest window (e.g. 30 days). You can backfill more later. Pulling years of historical tickets on day one slows down the first-sync experience and almost never pays off.
Problem: Horizon has its own user records. Your helpdesk has its own user records. They're not the same records. Without a map, Horizon doesn't know that "Bob Smith" in ConnectWise is the same person as "bob.smith@msp.com" in Horizon.
Horizon's answer: The User Mapping page lists every active helpdesk user and lets you bind each one to a Horizon user. After mapping:
Mapping is bi-directional: if you create a new agent in Horizon, you can come back here and link them to a helpdesk user later. New helpdesk users surface here automatically after the next sync.
Tip: Map every active helpdesk user, even ones you don't think will use Horizon. The cost is zero, and unmapped users cause weird gaps in reporting later.
Problem: Triage rules, routing rules, ticket filters, scheduled todo conditions — all of these need to reference helpdesk picklist values: ticket statuses, types, priorities, queues, departments. Hardcoding those values into rules is a maintenance nightmare. Querying the helpdesk every time is slow.
Horizon's answer: A local mirror of every picklist Horizon cares about. The Picklist Database page shows every picklist Horizon has discovered, with values and current selections.
The picklist database refreshes automatically on a schedule, and you can force a manual refresh on this page if you've added new statuses or queues in your helpdesk and need them visible in Horizon right away.
If you build a triage rule and a status you expect doesn't appear in the dropdown, this is the page to check first.
Problem: The dashboard widget and ticket widget are how 90% of agent-side activity actually happens. If they're broken or misconfigured, agents can't see Horizon and they stop using it.
Horizon's answer: The Widget Status page shows whether the widgets are loading correctly inside your helpdesk, the last successful render, and any errors.
You'll also find widget setup instructions here — the URL or embed code to paste into your helpdesk's customization area, and any per-PSA gotchas. Exact embed steps are different for each helpdesk and live in their own KB article. Confirm widgets render before going live with the team, because nothing kills adoption faster than agents loading the dashboard and seeing a broken iframe.
Problem: Horizon depends on inbound webhooks (callbacks) from the helpdesk to know when a ticket changes — new ticket created, status changed, note added. If callbacks stop firing, Horizon's view goes stale and triage / assignment never run.
Horizon's answer: The Callback Status page shows live callback health: when the last callback fired, how many fired in the last hour, whether any are failing, and what the helpdesk's webhook config looks like from Horizon's perspective.
If the page is red or showing zero recent callbacks, the polling fallback in helpdesk configuration is what keeps Horizon mostly current, but you should fix the callback issue rather than rely on polling. Polling is a safety net, not a primary mechanism.
Problem: Something didn't sync. You don't know why.
Horizon's answer: Two audit trails, both browsable from the Helpdesk cluster.
When an agent says "this ticket isn't in Horizon", your sequence is: check sync run logs for the most recent ingest, check callback logs for any callback related to that ticket's external ID, and if nothing matches in either, force a manual sync.
You know helpdesk integration is working when:
If any of those break, the relevant audit page tells you why before you have to open a support ticket.
Tip: After every credential change, every webhook reconfiguration, and every PSA-side update, do a smoke test: create a test ticket in the helpdesk, watch it land in Horizon, change its status in Horizon, watch it propagate back. Two minutes of verification beats two hours of debugging later.