Tenant Hierarchies
A tenant can name a parent, so customers can be modelled as a structure rather than a flat list.
Where to find it
Architect Panel → Configuration:
- Multitenancy — the tenants themselves
- Custom Tenant Information Fields — your own fields on a tenant
- Instance Configuration Fields — settings held per tenant
What it is for
- A group with subsidiaries, where the parent needs a view across them.
- A franchise, where branches operate independently under one brand.
- A reseller, whose customers are tenants of yours but belong to them.
- Regions or divisions within one large customer.
Model the real relationship
The hierarchy should reflect how the organisations actually relate, not how you would like your reporting to work. A structure invented for convenience becomes wrong the first time a subsidiary is sold.
It is not automatically an access grant
The important caution. A parent tenant does not, by existing, see its children’s data — nor should it be assumed to. Whether a group can see a subsidiary’s records is a decision about permissions and record sharing, made explicitly.
Treating the hierarchy as an access model is how a subsidiary’s confidential data reaches its parent company’s staff without anybody deciding that should happen.
Ask the customer
Whether a parent should see a child’s data is frequently contentious inside the customer’s own business. Subsidiaries often have good reasons for separation — a pending sale, a regulated activity, a works council.
Get it in writing rather than inferring it from the org chart.
Keep it shallow
Two levels covers nearly every real case. Deeper hierarchies are usually modelling an internal structure that changes annually, and every change means restructuring tenants.
Restructuring happens
Companies are bought, sold and merged. Know what moving a tenant from one parent to another does — to reporting, to sharing, to anybody who had access because of the old position.
Billing usually follows the parent
But not always. Decide explicitly whether the subscription sits with the group or with each subsidiary, because it determines who gets suspended when a payment fails.
Worked example
A platform models a customer group as a parent tenant with four subsidiary tenants. The parent sees consolidated reporting through explicitly shared records, not through the hierarchy itself — which mattered when one subsidiary was sold and the sharing was simply revoked.
Recommendations
- Never treat the hierarchy as an access grant.
- Get parent visibility agreed in writing.
- Two levels is usually enough.
- Decide where billing sits before onboarding.