Connected systems
Four systems have working adapters. Twenty-two do not, and here they are.
The connection vocabulary describes twenty-six business systems across six categories. Four of them have an adapter that can actually answer a question today. This page is the whole catalogue rather than the working part of it, because the number that decides whether this is useful to you is not four, it is whether your system is one of the four.
The catalogue
All twenty-six, in the order the code declares them.
A tool asks for a category rather than a product. It calls crm_read, never hubspot_read, which is what lets a second adapter in the same category answer the same tools with nothing downstream changing. That is why this list is worth publishing before most of it exists: the shape of the work is already fixed, and the tools that would serve each category already have names.
| System | Adapter | How a read signs in |
|---|---|---|
| ActerysPlanning, over SQL | live | one shared credential |
| HubSpotCRM | live | one shared credential |
| SalesforceCRM | modelled | each person's own token |
| Microsoft Dynamics 365 SalesCRM | modelled | as the signed-in person |
| PipedriveCRM | modelled | each person's own token |
| Zoho CRMCRM | modelled | each person's own token |
| ClickUpTasks | live | each person's own token |
| JiraTasks | modelled | each person's own token |
| Azure DevOpsTasks | modelled | as the signed-in person |
| AsanaTasks | modelled | each person's own token |
| monday.comTasks | modelled | each person's own token |
| LinearTasks | modelled | each person's own token |
| SharePointDocuments | live | as the signed-in person |
| ConfluenceDocuments | modelled | each person's own token |
| Google DriveDocuments | modelled | each person's own token |
| BoxDocuments | modelled | each person's own token |
| DropboxDocuments | modelled | each person's own token |
| NotionDocuments | modelled | each person's own token |
| XeroFinance | modelled | one shared credential |
| QuickBooks OnlineFinance | modelled | one shared credential |
| Microsoft Dynamics 365 Business CentralFinance | modelled | as the signed-in person |
| NetSuiteFinance | modelled | one shared credential |
| SAP S/4HANAFinance | modelled | one shared credential |
| Sage IntacctFinance | modelled | one shared credential |
| ZendeskService | modelled | each person's own token |
| ServiceNowService | modelled | one shared credential |
For the four that are live, the sign-in column is enforced. For the other twenty-two it is an expectation. The platform deliberately does not refuse a different arrangement on the strength of a guess: a client whose Salesforce is genuinely operated through one integration account would otherwise be told their own setup is impossible by a product that has not written a line of Salesforce code. A kind with no adapter is not pre-judged, and a test holds that open.
The column that matters
Three ways a read signs in, and only one of them stores nothing.
That third column is not an implementation note. It decides whether your own system applies your own permissions, or whether our grants are the only thing standing between a person and the data. Two questions produce every row of it, and neither answer is ours to choose: can the far system exchange our caller's identity for its own, and does its API then enforce that person's permissions?
As the signed-in person
The person's own sign-in is exchanged for access to the far system, and nothing is stored here at all. The far system then enforces its own permissions per item, so a document they cannot open is a document they do not get, regardless of anything we decide. This is the mode worth wanting, and four systems support it.
Each person's own token
The system enforces per user but offers no way to exchange an identity, so each person supplies their own credential. Real per-person visibility, bought with a custody problem fourteen times larger than one secret: it is one stored credential per person, revocable on its own, usable by nobody else. Better than shared, worse than storing nothing.
One shared credential
The system offers nothing better, so every caller reads through the same identity and the system cannot tell them apart. Our grants, the tool list and your own row rules are then the entire access control. We say so on the screen where somebody decides whether that is acceptable, rather than in a footnote afterwards.
One change unlocks the largest block of this catalogue, and it is not an adapter.
Every system that can read as the signed-in person sits behind Microsoft Entra: SharePoint, Azure DevOps, Dynamics 365 Sales, Business Central. They all come off one on-behalf-of exchange. So the sequencing fact worth more than any individual connector is that a single change to the sign-in broker makes four systems possible at once, in the only mode that stores nothing.
What modelled means
A declared system is a shape, not a date.
Being in this catalogue means the category, the expected sign-in and whose rules would apply are already decided, and that a connection row naming it can be saved. It does not mean the read works. Opening a connection whose adapter does not exist is refused readably rather than handed to a reader that would misread it.
What a listing gives you
- The category is fixed, so the tool names that would serve it already exist.
- The sign-in mode is worked out, which is the part that takes the argument.
- Whose narrowing applies is stated before anybody commits to the arrangement.
- The console tells your admin which is which, rather than accepting a connection that would fail the first time somebody used it.
What it does not give you
- No date. None of the twenty-two has one, here or anywhere else.
- No working read. A modelled system answers nothing today.
- No promise about the mode. For an unbuilt system it is what we expect, and building it may prove us wrong.
- No queue position. What gets built next is what a client is paying for, which is usually not the most popular system.
One boundary in this list is permanent rather than unfinished. Every Finance adapter is read-only for good, and not by a switch somebody can flip. A mistaken write to a ledger is a different class of harm from a mistaken write anywhere else, so a legitimate future need to draft an invoice has to become a code change. That is the correct amount of friction. The rest of the limits are on what it cannot do.
Is your system one of the four, or one of the twenty-two?
Worth five minutes on a call rather than a guess from this page. If it is one of the twenty-two we will say what building it would actually involve, including when the answer is that you should not wait for us.