Multi-tenancy in Connect
Everything is shared except the data. One codebase, one engine, one set of screens and one deployment serve every business; business records belong to exactly one workspace and are filtered on every read. A small, named set of records sits outside all workspaces by design — identity, sessions, billing, platform audit — because they are about running the service rather than about any one customer.
Where the line is drawn#
The data model makes this explicit rather than implicit. workspaces is the root; nearly every table carries a workspace column and is filtered automatically. The exceptions are enumerated in one place, so that a table belonging to neither list is a visible mistake rather than an invisible one.
| What | Which side | Why |
|---|---|---|
| Conversations, people, companies, calls | One workspace | This is the business's own record of its own customers |
| Memory, knowledge, facts, standing instructions | One workspace | What Connect knows about a business is that business's |
| Files and the data sheets | One workspace | Uploaded and edited by the workspace, for the workspace |
| Prospect intelligence gathered by research | One workspace | What a workspace has learned — and paid for — about a business is exactly the kind of record another must never see |
| Platform identity, sessions, memberships, billing | Shared control plane | They describe who may sign in and what they are entitled to, which is not any one workspace's business data |
| Platform audit | Shared control plane | One platform action can touch three workspaces; an auditor has to see all three rows |
| Enquiries sent to JBRH's own website | Shared control plane | They are addressed to the operator, and belong inside no customer's workspace |
One implementation, two audiences#
The operator and a customer are served by the same code over the same records. New behaviour lives in a module that both surfaces call; the difference between them is which door is used, never a second implementation behind it. A capability that exists for one audience and not the other is treated as a defect and is caught by an enumerated parity check rather than by assertion — the list of remaining gaps may shrink and is not allowed to grow.
The genuine difference is commercial. A customer's use is bounded by their plan's allowances; the operator has no plan. Two capabilities are deliberately operator-only, and both are about running the platform rather than using Connect: verifying customer payments, and JBRH's own pricing. Owner and customer sets out the split in full.
What tenancy does not mean here#
- Not a database each
- One database, with the boundary enforced in the object layer and again by the database's own row filtering. Separation is by policy and by construction rather than by having a hundred copies of a schema to keep in step.
- Not a model trained on your data
- Connect does not train a model on customer data. Model providers are called as services; what a workspace holds is not turned into anyone else's capability.
- Not shared memory
- Two workspaces that both deal with the same company hold their own separate records of it. Nothing learned in one appears in the other.
- Not a shared reputation
- Suppression, unsubscribe and do-not-contact are per workspace, because they record what a particular business was told by a particular person.
How this is kept honest#
- The scoped and control-plane lists are code, not documentation, and the hardening step reads the same list.
- Parity between the two audiences is enumerated from the running application rather than asserted, with named exceptions carrying reasons.
- Cross-workspace access exists as one explicit, reason-carrying mechanism instead of being scattered, so it is greppable and reviewable.
- Refusals are recorded, so an unexplained silence and a policy-explained one are distinguishable afterwards.
The layer-by-layer view of the same boundary is Workspace isolation; the database half of it is Row-level security.
Questions#
Is my data in the same database as other businesses?
Yes, and it is filtered on every read by the object layer and again by the database itself, with the active workspace taken from your session rather than from anything a browser can send. Separate databases would replace two enforced filters with a hundred schemas to keep aligned.
Does Connect learn from one business to help another?
No. Connect does not train a model on customer data, and the research a workspace pays for stays in that workspace. Two customers dealing with the same company each hold their own record of it.
Why do some records belong to no workspace at all?
Because they are about the service rather than about a customer: who may sign in, which sessions exist, what a workspace is entitled to, and platform-level audit. They are enumerated deliberately, so that a record in neither category is a visible fault.