Every integration decision downstream — who operates it, where credentials live, what happens when it breaks, how members upgrade — is decided by one question about your platform. Ask it first, because the answer is not yours to choose.
The question
That is the whole taxonomy. Not which CRM it is, not how good the API is, not whether it has webhooks — whether the platform will host and execute integration code on the member's behalf, inside their instance.
It sounds like an implementation detail and it is the opposite. It determines who is on call when the integration breaks, whose infrastructure holds the member's case data in transit, whether connector faults are independent or correlated across members, and whether shipping a fix means asking every member to upgrade something. Get it wrong at scoping time and you discover it during the build, when the cost of changing course is highest.
The three classes
The platform runs real code in the member's own instance. Apex classes, plugin assemblies, declarative automation — all executing under the member's governance.
Client-side apps in a sandbox and platform-hosted declarative flows, but nowhere to put arbitrary server code. Some logic has a home in-tenant; not all of it.
The platform hosts no third-party code at all. Panels are pages served from elsewhere and framed in; there is no installed package — the member connects an app in their workspace (for Fin / Intercom, a connected Intercom app) and TSANet hosts the rest. The shared machinery this class runs on is the Connect Gateway.
What follows
| In-tenant | Gateway | |
|---|---|---|
| Reconciliation | Scheduled jobs the platform runs for you | A poller you build, operate and monitor |
| Durable state | Platform objects — reportable, governed by their sharing model | A store you run, back up and keep consistent with the platform |
| Inbound delivery | An endpoint inside the tenant, or the platform's own event machinery | Your endpoint, your signature verification, your dedupe |
| Deployment | A package a member installs and later upgrades | A service you deploy; members connect an app and install little else |
| Data residency | Case content never leaves the member's tenant | Case content transits infrastructure TSANet operates |
| Connector faults | Independent — one member's misconfiguration cannot affect another | Correlated across members on the gateway — one shared service, which is what its durability and rollout design exists to manage |
| Platform outage | Affects everyone, in every class — the Connect API is a shared dependency regardless of where connector code runs | |
| Release cadence | Gated by member upgrade appetite and any store review | As fast as you can deploy safely |
The row that most often gets under-weighted at scoping time is data residency, because it is a procurement question rather than an engineering one. A member whose policy says case content stays on their infrastructure has effectively ruled out the gateway class before the first design meeting — and will say so late, after review, unless someone asks early.
The two failure rows are the ones most often reasoned about badly, including by us — an earlier version of this page got them wrong, so it is worth being precise.
Every class already shares a dependency. The Connect API is the shared floor: a platform outage stops collaboration for every member regardless of where their connector code runs. An in-tenant Salesforce package does not keep working when the platform is down. So "in-tenant means one member is affected" is only ever true of faults in the connector itself, and stating it without that qualifier flatters the in-tenant column.
What the gateway changes is correlation, not fragility. It adds one more component shared by the members on it, so a fault there is correlated rather than independent. That is a design input, not a verdict: correlation is what durability, recovery and staged rollout exist to manage, and a gateway built that way targets availability in the same range members expect from the platform itself. The honest comparison is that in-tenant distributes connector faults across members while a gateway concentrates them into something engineered — and operated — to a higher standard than any individual member's install.
Where that genuinely bites is not uptime but change. A bad release to the gateway still reaches everyone on it at once, which is why deployment discipline matters more there than in a world where each member upgrades on their own schedule.
Two consequences of the class are worked through on their own pages: what it means for accepting cases automatically, and for receiving files.
Deciding
Four questions, in this order. The first "no" usually settles it.
| Platform | Class | Why |
|---|---|---|
| Salesforce | In-tenant | Apex is real server-side code running under the member's governance |
| Dynamics | In-tenant | Plugin assembly plus Power Automate, all in the member's environment |
| Zendesk | Partial | Sandboxed client app and hosted declarative flows, but no arbitrary server code |
| Fin / Intercom | Gateway | No third-party code hosting and no native webhooks, so the service must be elsewhere |
| ServiceNow | Undecided | Answers both ways: it runs installed code, but hosts no UI and has no native webhooks |
The awkward case
Two of the five platforms above do not answer cleanly, and they are instructive in different ways.
Code installs and runs — but the app is a browser sandbox with no storage and no server, and the flow engine is declarative. So background work lives in a page that exists only while an agent has a tab open, and anything the flow language cannot express has nowhere to go. The class question resolves to Partial — in-tenant, within limits — and the limits are the design.
Installed scoped applications are the native extension model, so code can certainly run in the member's instance. But the platform hosts no UI surface for you and provides no native webhooks — so something must be installed and something must be served from elsewhere. The remaining decision is not "app or no app"; it is how much of the connector lives inside that app, and therefore how often members have to upgrade it.