Tenant-Level Isolation for Senior Housing & Care Software | Multi-Tenant tenant isolation, RBAC, Audit
Tenant-level isolation means every operator using SeniorCRE® runs in a fully separate environment: its own residents, charts, eMAR history, leases, AR/AP, employees, vendors, branding, workflows, and resource quotas. No global query, dashboard, or report path can return another tenant's data. Isolation is enforced as a default-deny contract at the API boundary , with defense-in-depth policies in the database — never as an application-layer convention that a future bug could undo.
On this page
Each operator runs in a fully isolated environment — own data, branding, workflows, quotas, and users — with tenant and role gates enforced at the API layer (Fastify + tRPC on AWS) and defense-in-depth policies in PostgreSQL.
Concretely: every request runs through Fastify + tRPC on AWS with a WorkOS-authenticated session bound to a single active tenant. Tenant and role gates run before any query executes , and PostgreSQL enforces the same boundary as a second layer. Cross-tenant scenarios — regional VPs, holding companies, REIT rollups — are handled by the hardened C1 cross-tenant access layer with session-bound elevations rather than by relaxing isolation.
Per-tenant customization is extensive: branding and theming, custom fields and forms, feature toggles, workflow rules, document templates, and resource quotas. Combined with white-label subdomain + authentication branding, the tenant feels — to its residents, families, and staff — like the operator's own software.
Key points
- Each operator tenant runs in a fully isolated environment: its own data, configurations, users, branding, workflows, and resource quotas. Every read and write is gated at the API layer (Fastify + tRPC) by the authenticated session\
- Multi-tenant operator management lets a senior housing & care organization run multiple properties — and even multiple legal entities — under separate tenant environments inside one platform. Each tenant has custom configurations, branding, workflows, and resource quotas, while a Corporate → Regional → Property hierarchy provides cross-tenant rollups for executives without breaking isolation.
- Yes. PHI is encrypted at rest (AES-256) and in transit (TLS 1.2+), tenant and role gates run on every API call via WorkOS-authenticated sessions, mandatory phone MFA gates every login, and an immutable, append-only audit log captures every read and write. Tenant isolation is enforced as a default-deny policy — access must be explicitly granted for the active tenant — which is why the standard sat…
- No. By default, residents, staff, leases, eMAR records, and financial data never cross tenant boundaries. Cross-tenant scenarios — like a regional VP overseeing 12 communities or a holding company rolling up NOI — are handled by the hardened cross-tenant access layer (C1), which uses session-bound elevations rather than disabling tenant isolation.
- Branding (logo, primary/secondary colors, theme), custom fields and forms, feature toggles, workflow rules, UI customization, document templates, and resource quotas. White-label deployment extends per-tenant customization to subdomain, authentication branding, and family/staff portal identity.
- A "multi-tenant database" usually means shared tables with a tenant_id column — and one bad query can leak data across tenants. SeniorCRE enforces isolation as a default-deny contract at the API boundary and again in PostgreSQL: every request is bound to the authenticated tenant, and cross-tenant reads require an audited, session-bound elevation. That is the difference between "trusts the app" an…
- Tenant is created with its own configuration, branding, feature toggles, quotas, and admin user. White-label subdomain and auth branding are bound to the tenant.
- User signs in through WorkOS AuthKit with mandatory phone MFA. The session is bound to a single active tenant server-side.
https://seniorcre.com/tenant-level-isolation-senior-living