Multi-tenant SaaS requirements should define how customer organisations are identified, how their records and actions are isolated and how shared operations behave. Tenancy affects more than a database column: invitations, exports, background jobs, search, support access, billing and recovery must respect the same customer boundary.
Let’s plan your SaaS tenant boundaries.
Bring your requirements and the decisions you need to make. We’ll help you clarify the scope, explore the trade-offs and plan the next step.
Define the tenant before choosing infrastructure
Decide whether a tenant represents a company, workspace, operating entity or another business boundary. A user may belong to several tenants with different responsibilities. Document how the active context is selected and verified for each operation.
Compare shared and separated infrastructure approaches against the actual isolation, scale, customisation and operating requirements. Do not choose a tenancy model merely because a framework provides a convenient default.
Map the boundary across product capabilities
| Capability | Requirement to define | Test to request |
|---|---|---|
| Membership | Who may join and invite others? | Invitation cannot grant unintended access |
| Records | Which tenant owns the object? | Another tenant's identifier is refused |
| Search | Which sources are eligible? | Results and counts respect scope |
| Background work | How is tenant context retained? | Queued work runs in the intended boundary |
| Export | Which population is included? | File contains only permitted records |
| Support | Who may inspect customer information? | Scoped, attributable support session |
| Recovery | What can be restored independently? | Restore procedure and limitations explained |
The table is a requirements worksheet, not proof that a chosen architecture provides isolation. Engineering review and testing must establish the implementation's actual behaviour.
Test a user with two memberships
Use a hypothetical user who manages workspace A but has read-only access to workspace B. Ask the product to switch context, open a saved link and execute a queued export.
The role in A must not silently determine authority in B. A cached search result, notification link or downloaded file can expose information even when the main record screen checks membership correctly.
Test removal of membership while a session or background task remains active. Define what should stop immediately, what requires revalidation and how previously delivered information is handled under the product's policies.
Define tenant administration explicitly
Specify owner transfer, duplicate invitations, tenant closure, data export and billing responsibility. Include the case where the last administrator leaves or loses access.
Distinguish business administration from technical support. A platform operator may need to investigate a failed job without receiving unrestricted authority to edit every customer's data. Record the approved support and emergency-access arrangements.
Plan shared-service failures
Consider how one tenant's heavy workload affects others. Define relevant quotas, queues, monitoring and escalation. Describe the customer-facing behaviour when a limit is reached.
Recovery needs particular attention. If backups contain several tenants, explain how one customer's restoration can be investigated or performed without overwriting unrelated current records. A generic backup statement does not answer this requirement.
Questions founders ask
Does multi-tenancy require one shared database?
No single storage arrangement defines every product. Choose and verify an architecture against the agreed isolation and operating requirements.
Can tenant owners see every user record?
Specify the product's role and information model. Ownership of a workspace does not remove the need for deliberate access rules.
Prepare the architecture review
Bring tenant definitions, membership cases and recovery expectations. Combine this with the private-data AI questionnaire where AI features are included, and discuss SaaS development around the complete boundary.
