Tenant & Organization Model¶
Status: FROZEN — Foundation v1.0
Organization relationships¶
flowchart TB
T[Tenant] --> B[Brands 0..N]
T --> L[Locations 0..N]
T --> BU[Business Units 0..N during provisioning]
T --> S[Sites 0..N]
T --> C[Customers 0..N]
BU --> PV[Exactly 1 Primary Vertical Preset]
BU --> AC[Additional Capabilities 0..N]
BU --> O[Offerings]
BU --> R[Resources]
BU <--> L
S --> B
S --> BU
An active operating tenant normally has at least one Business Unit; a newly provisioned tenant may temporarily have none.
Business Unit / Location relationship¶
Business Units and Locations are many-to-many.
Examples:
- one resort location may contain Hotel, Spa and Restaurant Business Units;
- one Vehicle Rental Business Unit may operate from several pickup/return Locations;
- one Excursions Business Unit may serve several departure Locations.
Tenant-wide customer identity¶
Customer identity is tenant-wide.
A customer who books a Hotel Business Unit and later a Spa Business Unit owned by the same Tenant remains the same tenant Customer record.
Authorization may still restrict a staff member to only the customer interactions, bookings or data they are permitted to view for assigned Business Units.
This rule does not create a cross-tenant customer record. The same real-world person may have separate Customer records with different Tenants.
Isolation invariant¶
Tenant-owned state must be isolated by a trusted server-side Tenant Context. The concrete persistence/database mechanism is intentionally deferred to the technology decision gate.
Every implementation must preserve these isolation properties:
- tenant identity is derived/validated server-side rather than trusted from arbitrary client payloads;
- repositories/data access cannot silently cross tenant boundaries;
- caches and asynchronous work retain tenant scope;
- media/object storage remains tenant scoped;
- audit records carry tenant identity;
- external integration/payment/advertising credentials are tenant scoped;
- support impersonation/delegated access is explicit and auditable.
User membership¶
A platform user account is not permanently attached to one Tenant.
User
└── TenantMembership(s)
├── Tenant A -> OWNER
└── Tenant B -> MANAGER
Platform staff identity/permissions remain separate from tenant membership.
Commercial boundary¶
The Tenant is the subscription/billing boundary.
Business Units and additional capabilities can affect effective entitlements and billing, but they remain inside the Tenant subscription/contract rather than becoming separate tenants.