TENANCY FEATURE
Per-Tenant Configuration
One resolved tenant config reshapes branding, locale, commerce defaults, and feature flags across the same product surface.
Feature Guide
A quick orientation block that answers the essential questions: what this feature does, how it works, why it matters, and the key concepts behind it.
What this does
Tenancy is not only row isolation: the active tenant also changes branding, locale defaults, pricing conventions, and which features are visible.
How it works
One tenant config is resolved once, then reused by rendering, component behavior, and downstream services.
Why it matters
The important platform promise is this: the same codebase can produce multiple product surfaces without sprinkling tenant-specific if/else logic everywhere.
This page is about product-shaping tenancy, not database partitioning. One tenant decision changes what the product feels like to the user.
Switch between tenants and compare what really moves: branding, locale defaults, pricing conventions, rating behavior, and capability flags. The same handler and template tree stay intact.
acmeglobexinitechHow the resolution flow works
Think about this page as a three-step pipeline rather than a styling demo:
- Select the tenant once. This demo chooses the active tenant from the query parameter and resolves a single tenant config object.
- Build the tenant-facing layers. Theme, locale defaults, rating style, and feature flags are derived from that config instead of being scattered across controllers or templates.
- Let handlers and views consume capabilities. Downstream code asks for the active layer or capability and renders the correct experience without comparing tenant IDs manually.
If you had to write if ($tenantId === 'globex') inside a template, the architecture would already be losing. The demo should teach the opposite habit: resolve tenant context once, then let the rest of the stack read structured configuration.