Five platforms, four of them shipping and one not built yet. Start here to find your platform, see how the connectors actually differ, and work out what to do if yours is not on the list.
Routing
Comparison
The differences that change how you design, operate and support an integration — not feature checkboxes.
| Salesforce | Dynamics | Zendesk | Fin / Intercom | ServiceNow | |
|---|---|---|---|---|---|
| Class | In-tenant | In-tenant | Partial | Gateway | Undecided |
| Status | GA | GA | GA | Early access | Not built |
| Operated by | You | You | You | TSANet | — |
| Agent surface | LWC on the Case record page | HTML + JS web resources on the Case form | ZAF sidebar app + nav-bar screen | Canvas Kit panel in the Help Desk | — |
| Where state lives | Custom objects | Dataverse tables | Ticket fields and tags | The gateway's own durable store | — |
| Inbound delivery | Apex REST on a public Site | Scheduled poll by default; optional webhook to Power Automate | ZIS generic inbound webhook | TSANet push to the adapter | — |
| Reconciliation | Scheduled job, 15 min default | Scheduled flow, 15 min default | ZAF background poller, 60 s | Reconciliation poller | — |
| Extension point | Clonable Flow library | Case Mapping configuration table | Zendesk triggers and ZIS flows | Server-side, by TSANet | — |
| Auto-accept | Asset-match flow, rejects on no match | Auto-routing by case number, then customer name | Built-in setting, or a scoped trigger | Deliberately manual | — |
| Distribution | Managed package | Managed solution / AppSource | App upload + ZIS bundle | A connected Intercom app plus a hosted service | — |
| Shipping a fix | Members upgrade | Members upgrade | Members upgrade | Central, nothing to do | — |
| Connector faults | Isolated | Isolated | Isolated | Shared — one hosted service | — |
| Platform outage | Affects every member in every class — the Connect API is the shared floor | ||||
Two rows are worth pausing on. Reconciliation tells you what happens when a push is missed — and the Zendesk poller runs in a browser page, so it only catches up while an agent has a tab open. The two failure rows belong together: every class depends on the Connect API, so a platform outage reaches everyone regardless of where connector code runs. What the gateway changes is that connector faults become correlated rather than independent — a design input for the gateway (the reference deployment runs a single replica today, so its resilience is durability and recovery rather than replication), and the reason deployment discipline matters more there. On Dynamics, note, there may be no push at all: the scheduled poll is the default and the webhook is opt-in. The connector classes topic works the trade through.
Auto-accept is the row where the connectors disagree most sharply — from a Zendesk setting that accepts everything to a Salesforce flow that will reject a request it cannot verify, and a Fin/Intercom guardrail that keeps the commitment with a person. Accepting stops the SLA clock and tells a partner an engineer is engaged, so which posture you pick is a real decision: deciding what to accept automatically.
No connector for your platform
TSANet supplies the engine, the contract and a conformance harness that certifies the seam; you write only the half that talks to your own platform — and never touch the Connect API or its errors. The repository is private; adapter authors get access at onboarding.
Design & adapter guide → v2.0.0 · JavaA Java client over the Connect API with typed facades, validation and both auth modes. The shortest path on the JVM that is not hand-rolled HTTP.
Library reference → PatternThe translation-service pattern: your platform's events in, Connect API calls out, updatedAfter polling back. Read the behaviour guide before you design.
Which platform your team runs on is the single most useful thing you can say to us — it is what decides which connector gets built next.
Community →