# 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.

- **Status:** Available
- **Audience:** both, developer
- **In the app:** #/account
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/glossary/tenant/

## 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 |

> **Note** The three are not interchangeable in every sentence. *Workspace* is the record; *tenant* is what that workspace is to the platform; *customer* is who is behind it. A sentence about rows wants workspace; a sentence about billing wants customer.

## What being a tenant changes in practice

A tenant session takes a different path through the application than an [Owner](/docs/glossary/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](/research/closed-by-default-facade/) 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](/docs/glossary/person/), [Companies](/docs/glossary/company/) and [Relationships](/docs/glossary/relationship/) inside your workspace, and they have no tenancy of their own.
**A workspace** — Almost the same, not quite: every tenant is a [workspace](/docs/glossary/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](/developers/entity-ids/) and [the public data model](/developers/data-model-public/) 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.

## Related

- [Workspace](https://connectbyjbrh.com/docs/glossary/workspace/)
- [Owner](https://connectbyjbrh.com/docs/glossary/owner/)
- [Customer-safe](https://connectbyjbrh.com/docs/glossary/customer-safe/)
- [Security and isolation](https://connectbyjbrh.com/docs/security/)
- [A tenant facade that fails closed](https://connectbyjbrh.com/research/closed-by-default-facade/)

## What this page is based on

- docs-source/sources/GENERAL.md §1 — tenantAdapt, customer_safe and ALIASES
- docs-source/sources/GENERAL.md §2 — how a request flows
- `docs-source/facts.py` — AUDIENCES