Write-ups that cut across connectors rather than belonging to one. Each is grounded in what the shipped integrations actually do — which is also why there are only four of them.
Published
One question about your platform — will it run your code inside the member's tenant? — decides who operates the integration, where credentials live, whether connector faults are independent or correlated, and whether shipping a fix means asking every member to upgrade. The taxonomy behind every connector on this hub, plus a four-question procedure for a platform that is not on it yet.
Three of the four shipped connectors can accept inbound cases without an agent, the fourth refuses to, and they disagree completely about when that is wise. Accepting stops the SLA clock and tells a partner an engineer is engaged — so a false acceptance is worse for them than an honest breach. Four shipping postures, and how to build a rule that asserts something actually true.
A file attached to a collaboration case is delivered into the receiving member's own file store — not parked on a portal. The sender never learns how the receiver stores files, which is exactly what makes the system extensible. How sending works, what the normalized receiving contract requires, the five decisions every receiving member makes, and the sharp edges around one-attempt delivery.
Working on Connect with an AI agent rather than by hand, whichever provider's agent it is. The four skills TSANet ships and how any assistant loads them, the assistant embedded in this hub and the recipe for the Copilot Studio agent behind it, what every provider's framework needs from the API — and the auth gap that separates hosted builders from code-first ones — plus a documented-only assessment of Copilot Studio with Claude.
Not written yet
These appear as headings elsewhere on the hub. They are not written because nothing has been assessed behind them, and a topic page that summarises nothing would be worse than an empty slot.
| Candidate | What is missing |
|---|---|
| AI-native support platforms Pylon · DevRev · Wolken · Agentforce · Zendesk AI · Now Assist | No platform assessment exists for any of them. Fin / Intercom is the only one that has been probed, and it has a connector page rather than a topic. |
| Email-to-case patterns | No connector implements one, so there is nothing to compare. |
| Swarming & case ownership | Ownership changes propagate on two connectors, but nothing has been written down about how teams actually use it. |
| SLA & escalation design | Partly covered already — the acknowledgment-only SLA and the responded flag are in the API guidance and the acceptance topic. A standalone page needs more than that. |
Contributing
The most useful proposals come from someone who has hit the same problem on two platforms and found the answers differ. If you have run into that, it is very likely worth a page — and you already have most of the material.
Ideas and Wish List are the categories for this. Say what you hit, on which platforms, and how the answers differed.
Community → AdjacentIf the subject is platform-wide behaviour with a specification behind it rather than a comparison, it belongs in the numbered library instead.
Design docs → SourceThe comparison matrix is where most topic ideas start — a row where the connectors disagree is usually a topic waiting to be written.
All connectors →