Org hierarchy
Multi-tenancy, workspaces and parent-child accounts
What it is
Most products start with flat workspaces: one account, one set of users. A large company is a hierarchy instead, with a parent organisation, subsidiaries and business units that want their own data and admins under one contract. Supporting that means your data model can express parents, children and settings that pass down between them.
The biggest customers buy once and roll out many times. If each business unit needs its own separate account, you lose central admin and consolidated billing, and often the deal.
What it takes
About 6–12 engineer-weeks to build in-house.
Answer these first
- Product: Does a child org inherit settings from its parent, and can it override them?
- Product: Is billing consolidated at the parent, or per business unit?
- Engineering: How many places in the code assume a user belongs to exactly one workspace?
- Engineering: What does tenant isolation mean for us: rows, schemas or databases?
- Security: Can a parent-org admin see data inside child orgs?
- Sales: Which prospect has the hierarchy, and what does it actually look like?
This page works best with JavaScript on. Every answer also has its own address, like /what/scim.