How can multiple companies share one system while seeing only authorized data?
Combine tenant isolation with role- and attribute-based authorization, but do not assume every company should share one database. A shared application and tables with mandatory tenant identifiers suit many ordinary workloads. Organizations needing separate keys, recovery, region, performance, or stronger regulatory boundaries should use a separate database or instance.
Tenancy separates Company A from Company B. Authorization determines what sales, managers, finance, and auditors may do inside Company A. Menu permissions cannot replace server-side tenant filters, and a tenant ID alone cannot limit an employee to personal customers or a manager to one department.
When decomposing features, data, and acceptance scenarios, also compare What data does reliable shipment tracking need, and how should it integrate with carriers?; the linked guidance adds context that should be considered in the same decision.
| Isolation model | Data location | Characteristic | Better fit | Recommendation |
|---|---|---|---|---|
| Shared database and tables | Every row has tenant_id | Lowest cost and unified upgrades; application must preserve the boundary everywhere | Many similar tenants with ordinary business data | Default candidate with automated isolation tests |
| Shared service, database per tenant | Application selects separate databases | Independent backup and deletion; more connections and migrations | Fewer B2B clients needing tenant recovery or retention | Prefer for medium/high isolation |
| Separate instance or deployment | Compute, database, and network can be isolated | Strongest control and highest operating cost | Separate keys, region, regulation, or performance guarantee | Use for an explicit contractual need |
| Hybrid | Standard tenants share; premium tenants isolate | Tiered cost and control | Material differences among clients | Requires consistent versions and tenant routing |
Microsoft's multitenant storage guidance explains that no single model fits all and identifies separate encryption, backup/restore, locality, and noisy-neighbour concerns. Wavesteam determines the model from each organization's export, deletion, recovery, encryption, and performance needs, not company count alone.
In shared tables, tenant identity comes from a verified token and server session, never a freely supplied org_id. Business rows, attachments, cache keys, search indexes, message topics, exports, and object paths carry the boundary. Scheduled jobs and administrator scripts follow it too. Database row-level security, such as PostgreSQL RLS, can add defence in depth but cannot repair a wrong identity mapping, and bypass roles remain tightly restricted.
Within a tenant, RBAC defines role actions while attributes consider owner, department, region, state, and delegation period. A group auditor receives a named set of companies, read-only fields, expiry, and approval reason rather than global administrator status. NIST's ABAC guidance provides the subject/object/action/environment model.
Fields remain minimal: warehouse users may need recipient and items but not margin; a tenant administrator manages members without automatically reading compensation; platform operations handles performance without default content access. Export, bulk query, cross-company aggregation, and impersonation are separate audited permissions. Group reports should aggregate in a controlled analysis layer rather than remove tenant filters from every API.
Tests actively attack the boundary: use Company A's token for a known Company B ID, alter tenant parameters, reuse old export URLs, guess attachment paths, inspect caches and search, reuse tokens after delegation expires, and simulate a background job with the wrong tenant. Every new API runs denial tests, not only UI checks.
Operations tracks storage, requests, errors, and slow queries per tenant and proves a tenant restore cannot overwrite another. Deactivation must locate rows, files, indexes, caches, and backup-retention rules. Wavesteam begins multi-organization work with an organization model, permission matrix, and isolation-test inventory, informed by the public smart park case.