Tenant
A tenant is a customer workspace — one business's account, isolated from every other. The word is engineering vocabulary: it appears in route names, isolation code and this manual's technical pages, while the same thing is called a *customer* in prose written for the business using it. Both name the identical record.
One thing, two registers#
Multi-tenancy is the architecture: many independent businesses on one running application, each seeing only its own rows. *Tenant* is that architecture's word for a participant, and it is the right word when the subject is isolation, routing or the shape of a request. It is the wrong word on a screen a shopkeeper reads, where the business in question is simply you.
| Context | The word used | Example |
|---|---|---|
| Isolation and routing | tenant | The customer facade rewrites a path for a tenant session |
| Commercial and product prose | customer | A customer's use is bounded by their plan's allowance |
| The data model | workspace | Every record carries one workspace identifier |
What being a tenant changes in practice#
A tenant session takes a different path through the application than an Owner one, and this is where most "it works for them and not for me" reports come from. Customer requests go through a facade that rewrites the path; anything the facade does not recognise becomes a blocked call and answers 403 rather than falling through to the direct route. Separately, an allowlist in the middleware refuses any API path a customer session is not permitted to call.
Both behaviours fail closed on purpose, which is the correct trade for tenant isolation and an awkward one for diagnosis: a missing rewrite and a genuinely forbidden call look the same from the browser. A tenant facade that fails closed covers the reasoning and the symptom.
What being a tenant does *not* change is the feature set. A tenant reaches every capability the operator reaches, over the same implementation; the surface renames a couple of things — a customer's *people* are the same records the operator screens call *relationships* — and a parity check enumerates the two surfaces to prove nothing has quietly become one-sided.
Commonly confused with#
- A customer of yours
- The most expensive confusion in this glossary. *You* are the tenant. The businesses and people you deal with are People, Companies and Relationships inside your workspace, and they have no tenancy of their own.
- A workspace
- Almost the same, not quite: every tenant is a workspace, but the Owner workspace is not a tenant. Reach for *workspace* whenever the sentence is about records.
- A user
- A tenant is a business. Several people can sign in to one, and none of them *is* the tenant.
- A sub-account or a department
- There is no nesting. Separating two parts of a business means either mailbox roles inside one workspace or two unconnected workspaces, with no shared memory between them.
For developers#
Integrations never choose a tenant. A key or a session resolves to exactly one workspace and every read and write is scoped to it by the kernel and by row-level security — there is no parameter that widens the scope, and a request for another workspace's identifier returns nothing rather than a permission error. Stable identifiers and the public data model describe what a client actually sees.
Questions#
Should I use the word tenant when I write to support?
Say what you mean plainly — "my workspace" or "my account" is unambiguous. Tenant is useful when the question is about isolation or about an API path behaving differently for you than for a demonstration.
Do tenants share anything at all?
The running application and the database, and nothing readable. Records are filtered by the allowlist, the workspace kernel and row-level security independently, so a query written without a scope returns nothing rather than someone else's rows.
Are my customers tenants of Connect?
No. They are records inside your workspace. Nothing about them is exposed to another workspace, and they have no sign-in of their own.