Designing Tenant Boundaries with QQQ 4.0
Choose explicit isolation and verify cross-tenant access across all application paths.
Updated for the QQQ 4.0 release review on September 10, 2026.
Choose the boundary
A multi-tenant application must define how data, identity, configuration, and operations are separated. Separate deployments, databases, schemas, or record-level security rules offer different tradeoffs. QQQ 4.0 does not supply a universal tenant configuration switch, self-service tenant provisioning, or billing service.
Map identity to authorization
Configure the authentication provider and session security keys for the host. Test direct record access, queries, writes, exports, reports, process selection, and custom endpoints with users from different tenants. UI visibility is not an authorization boundary.
Treat variants and branding separately
Backend variants can select backend settings. They do not, on their own, prove tenant isolation. Per-tenant branding, feature selection, caches, scheduled jobs, and integration credentials need their own names and access rules.
See the tenant pattern and testing guide. Build a small denial-focused test fixture before expanding a SaaS application.
