Multi-tenancy isn't just a deployment shape. It's a design decision that sets the economic model of the platform — who pays for what, how many customers one team can serve, whether a new customer can be stood up in minutes or months — and the engineering decision that determines whether each customer's data really stays where it belongs. A platform built for multi-tenancy from the start can serve many customers with a single operational footprint, ship improvements to everyone at once, and tune individual tenants without forking the codebase. A platform that bolts multi-tenancy on after the fact always leaks somewhere — costs sprawl, data isolation turns out to have edge cases, operator visibility is an afterthought, a customer request for per-tenant tuning becomes an engineering project. We've treated multi-tenancy as architectural foundation, and the shape of every feature reflects that.
The tenant is the primary boundary. Every piece of data in the platform — every record, every user, every configuration, every automation, every file — belongs to a specific tenant. The platform's data access layer enforces that boundary automatically: a query issued within tenant A's context cannot return data from tenant B, regardless of the shape of the query. That enforcement is at the infrastructure level, not bolted on by individual feature code, which means feature developers don't have to remember to add "WHERE tenant = ?" to their logic — the boundary is enforced before their code even runs.
Per-tenant configuration makes each tenant a genuinely independent implementation. The types a tenant uses, the properties those types have, the views configured on them, the automations that run against them, the roles that define access — all of these are tenant-scoped. One tenant can have an elaborate customer relationship model; another tenant on the same platform can have an equipment maintenance model; a third tenant can have a nonprofit donor management model. The same platform serves all three, because the configuration that makes each one useful lives inside the tenant rather than in the platform code.
Shared code, independent data is the operating principle. There's one codebase, one deployment, one operational footprint — and as many independent customer implementations running on it as the operator chooses to provision. When a platform improvement ships, it lands in every tenant at once, because there's only one code to deploy. When a customer wants a divergent configuration, it's implemented as tenant-level configuration rather than as a code fork, because code forks are the thing multi-tenant architecture exists to prevent. The aggregate effect is that the operations team serves many customers with the effort that a single-tenant shop would spend on one.
Operator console and tenant admin are two distinct layers of administration. A tenant admin manages their own tenant — users, roles, configuration, data. A platform operator manages the fleet of tenants — provisioning, deprovisioning, monitoring, setting per-tenant limits, responding to cross-tenant support. The two layers are separate: a tenant admin has full authority inside their tenant and zero visibility outside it; a platform operator has oversight across tenants but doesn't routinely touch tenant data. That separation of authority matters both for security — tenant admins can't accidentally affect each other — and for scale — the operator console lets a small operations team understand the whole fleet at a glance.
The operator console provides that central view. Tenants are listed with their current state — size, activity level, health, configured limits, last operator action. Issues that affect multiple tenants are surfaced centrally rather than having to be hunted down per-tenant. Actions that apply across tenants — a global configuration change, a deployment announcement, a fleet-wide audit — are issued from one place. For the operational reality of running many tenants at once, that centralized view is what keeps the operation tractable.
Per-tenant limits let operators tune resource consumption on a tenant-by-tenant basis. Storage quotas, API rate limits, user-count ceilings, background-job concurrency — all of these can be set per tenant, so a large enterprise customer gets higher limits than a small startup, and a tenant that's behaving badly can have its limits tightened without affecting anyone else. The limits are declarative; the platform enforces them uniformly; tenants see their configured limits reflected in the platform's behavior without any surprise.
Tenant-aware background jobs run with the correct tenant context automatically. Scheduled automations, scheduled reports, scheduled maintenance — all of it runs per tenant, with the tenant's configuration, the tenant's data, the tenant's schedule. A background job triggered by tenant A never touches tenant B's data, because the job knows which tenant it's running for and the data access layer enforces the boundary accordingly. That's how scheduled work scales across a multi-tenant fleet without any per-tenant scheduling infrastructure to maintain.
Tenant provisioning is the lifecycle operation for adding a new customer. The operator creates a new tenant, selects an initial configuration — often by re-importing a data-model export from a template tenant — provisions an initial admin user, and hands the tenant off. What previously might have been a month of engineering work per new customer becomes a minutes-long operational task, because the template model export and the shared platform deployment handle all the pieces that would otherwise need custom setup.
Tenant deprovisioning handles the other end of the lifecycle cleanly. When a customer departs, their tenant can be archived — preserving data for whatever retention period the contract specifies — or fully purged, removing all trace of the tenant's data from the platform. Either path is a controlled operation that respects the isolation boundary: no data from the deprovisioned tenant leaks to any other, and no data from any other tenant is touched in the process.
Per-tenant branding and customization sit on top of this foundation. Each tenant's users see their own organization's logo, colors, fonts, and domain; the tenant customizations article covers that layer in detail. For tenant-level implementation divergence beyond branding — additional types, customized views, tenant-specific automations — the same customizations article and the data-import-and-model-export article together describe how that works in practice.
For platform operators evaluating whether the platform can carry their customer base, multi-tenancy is the foundational property that determines whether the answer scales. For enterprise architects looking at whether their organization can host multiple departments or subsidiaries on a single deployment, the same properties apply. For the adjacent topics, the tenant customizations article covers per-tenant configuration in more depth, the roles and permissions article covers the authorization layer within each tenant, the event log article covers the audit trail that runs per tenant, and the data import and model export article covers how configuration moves between tenants. Multi-tenancy is the property that lets the platform be economically viable at any meaningful fleet size; the isolation story is what lets every customer trust that their own data stays their own.