One platform serving many isolated workspaces, each with its own subdomain, branding, and strictly separated data.
A single deployment hosts many customers — called tenants — on shared infrastructure, while each tenant sees only its own queue, contacts, and settings. The opposite is single-tenant, where every customer gets a dedicated instance. Multi-tenant is the standard model for SaaS because it keeps one codebase to maintain and patch.
Why it matters
Isolation is the whole point: a bug or query in one workspace must never expose another tenant’s data. Done right, isolation fails closed — the default is no access, and every read is scoped to the current tenant — and that boundary is verified by tests, not assumed. It is also what lets a vendor brand each workspace separately with its own subdomain and look while running one shared system underneath, which is why the model is cost-effective enough to offer support tooling at per-agent pricing rather than per-server.
How it works
- Row-level scoping — every record carries a tenant ID, and every query filters on it so data can’t leak across tenants.
- Separate subdomains — each workspace gets its own address and branding, while requests resolve to the right tenant.
- Role boundaries — access inside a tenant is still governed by RBAC, so multi-tenancy and per-role permissions work together.
The classic failure mode is a query that forgets its tenant filter and quietly returns rows from everyone — invisible until the day it isn’t. Shared caches and background jobs are easy to overlook too: a cached result or a queued task that isn’t scoped can leak across tenants even when the main request path is clean. The defense is to make tenant scoping the default everywhere, not an extra step a developer has to remember.
A concrete example
An agency handling support for a dozen clients keeps each client in its own workspace — separate inboxes, separate saved views, separate reporting — so an agent staffed on one account never sees another’s tickets, and each client sees only its own branding. It’s the foundation for agencies running many clients; see the agencies solution.
How Cherryrise handles it
Cherryrise is multi-tenant with strict per-workspace isolation, and it’s also self-hostable if you’d rather run your own single-tenant instance. Either way, tenant separation and role-based access are enforced server-side. See security for the data-handling details.