Every multi-tenant SaaS platform answers the same question — how is one tenant's data kept apart from another's, on a single shared codebase? — but the right answer depends on the platform's risk profile. Two platforms, Omnitech CRM and IMFlow360, answer it differently, and both answers are correct for what each platform needs.
01Reading the work
Two isolation strategies, broadly
Multi-tenant platforms generally isolate tenants at one of a few layers: a separate database per tenant, a separate schema per tenant, or shared tables scoped by a tenant identifier at the application layer. Each has a different cost and a different failure mode; AWS's SaaS tenant-isolation guidance is a useful public reference for the tradeoffs between these strategies (cited below). Omnitech CRM and IMFlow360 both use shared-table, application-enforced isolation — but enforce it differently.
02Reading the work
Omnitech CRM: fail-closed at the model and query layers
Omnitech CRM enforces tenant isolation at the model and query layers, including queued background work, on a fail-closed basis: if a query is missing its tenant scope, the request fails rather than risking a cross-tenant leak. A central permission registry — 126 permissions across 22 business modules — is kept deliberately separate from that isolation layer, so permissions can be broadened or narrowed for a role without ever touching the code path responsible for keeping tenants apart.
03Reading the work
IMFlow360: row-based tenancy differentiated by business type
IMFlow360 takes a related but distinct approach: row-based multi-tenancy scopes every record by business and branch, while a business_type field — not a forked codebase — differentiates catalog, order, and workflow behavior for retail, restaurant, beauty/salon/spa, and appointment-based businesses. All four sectors run on one shared schema of roughly 146 tables. The isolation boundary is the same shared-table pattern as Omnitech CRM; the difference is that IMFlow360 also uses that same scoping mechanism to differentiate business behavior, not just to separate tenant data.
04Reading the work
The actual lesson
Isolation strategy is a foundational decision made once, early, for the platform's risk profile — and it is a separate decision from the permission system layered on top of it. Both platforms enforce isolation in the application layer against shared tables; the difference between fail-closed enforcement scoped strictly to tenant boundaries, and row-scoping that also carries per-tenant behavior differentiation, comes down to what each platform needed the scoping mechanism to do beyond isolation itself.
