The integrations TSANet has already built: four shipping connectors and one platform assessment. Start here if your platform is one of them, to find it and see how the connectors actually differ — or, if you are building your own, to read them as worked examples of the routes on Build a New Integration.
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, or you if self-hosted | — |
| 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 My Domain, via an External Client App | 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 template; asks for information 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 service, TSANet-hosted or self-hosted | — |
| Shipping a fix | Members upgrade | Members upgrade | Members upgrade | Central when TSANet-hosted; you deploy each release when self-hosted | — |
| Connector faults | Isolated | Isolated | Isolated | Shared on a TSANet-hosted service; yours alone if self-hosted | — |
| 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 template that accepts only what matches an asset, 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
There are four routes, in order of effort: build on the Connect Gateway, use the SDK, build against the API directly, or tell us the platform. One question decides between them — whether the platform will run your code inside the member's own tenant — and the tools you will use are the same on every route.
Build a New Integration →