How should an enterprise software startup design organization hierarchy: parent accounts, subsidiaries and multiple workspaces?
A guide for founders and product leads on when one workspace stops fitting and how to design parent accounts, child workspaces, admin roles, inherited settings, moves, billing and audit, with an invented entity map.
An enterprise software startup should keep one workspace until a buyer’s business units need different identity providers, data regions, budgets or administrators, and only then add a parent level above the workspaces. The parent holds the security floor, the billing view and the audit trail; each child holds its own admin, data boundary and local settings. Anything that crosses a boundary, such as moving data, searching or reporting, should be a visible choice with a log entry. Humbleteam designs enterprise and banking products for clients including Raiffeisen, Bank of America, Société Générale and Logitech. It designed the UX/UI of the Synthesia platform (valued at $4B in its January 2026 Series E) and redesigned the Afternoon app, where activation rose 32%.
Humbleteam, a digital product design agency, publishes this guide. It covers when one workspace stops fitting, four structure models, who administers what, what children inherit, people in several workspaces, moving data and users, billing, search and audit, an invented entity map and the failure cases. Sources are described as of November 13, 2026.
When does one workspace stop fitting?
Linear recommends that an organization stay within a single workspace, and its separate workspaces have distinct member lists and separate billing plans. Slack’s Enterprise Grid design module says to create the minimum number of workspaces that meet users’ needs, because more workspaces mean more admin overhead. Add a level only when one of these signals is true.
| Signal | What the docs show |
|---|---|
| A unit needs its own identity provider | Notion allows up to 25 SAML configurations per organization, for business units, regional IT teams or acquired companies. GitHub says to configure SAML per organization when some groups must use different providers |
| A unit must keep data in one region or legal entity | Atlassian warns that merging organizations can give users of one legal entity access to sites in another region. Linear fixes a workspace’s data residency at creation |
| A unit pays its own bill | GitHub offers cost centers for business units; Figma offers billing groups |
| A unit wants its own admin | Figma has workspace admins, Atlassian has unit admins, both below the organization admin |
| A company was acquired | It arrives with its own users and identity provider, a case Notion names for several SAML setups |
Which structure models exist?
| Model | Documented example | Fits when | Main cost |
|---|---|---|---|
| One workspace, many teams | Linear keeps teams and sub-teams in one workspace; team owners of a parent team own its sub-teams | One legal entity, one identity provider | One admin pool, one bill |
| Organization with workspaces | Figma Enterprise workspaces group teams, people and resources, and a person belongs to one. Slack’s organization is a network of two or more workspaces, each with its own member directory, channels and files | Several units, one parent company | Two admin scopes; people need a switcher |
| Parent with child organizations | A GitHub enterprise account contains organizations, each with its own audit log, policies and teams | The buyer is a group of entities with their own admins | Two admin layers, inheritance rules |
| Separate tenants with a trust link | In Microsoft Entra, a multitenant organization draws a boundary around tenants, and each tenant admin stays in control | Merged companies that stay independent | No shared admin; users sync into each tenant |
Our view: most startups need the first or second row. Build the second when a real buyer asks, and tag every object with an entity ID from day one so the third stays possible.
Who administers what?
| Product | Top level keeps | Child level cannot |
|---|---|---|
| Slack | Org Owners configure single sign-on; Org Owners and Admins create workspaces and set mandatory two-factor authentication | Workspace Admins cannot open the Billing page |
| Figma | Organization admins manage SAML SSO, SCIM, billing and workspace lifecycle | Workspace admins cannot manage organization-wide resources or settings |
| Atlassian | Organization admins create units and own organization-level settings | Unit admins cannot manage billing, global security policies such as SSO and SCIM, or organization-wide audit logs, and cannot see other units (the role was in beta when read) |
| GitHub | Enterprise owners enforce policy across organizations and manage billing | Organization owners keep organization settings; enterprise owners get no access to them or to content by default |
| Notion | Organization owners manage all workspaces; admin roles split compliance, people, IT, analytics and billing | Admin roles do not change what someone can see or edit in pages |
Our suggestions: a parent admin sees structure, settings and logs, not child content. GitHub works that way, Notion’s admin roles do not change what someone can see in pages, and a Figma admin who cannot open a file uses Get admin access, which emails the owner. Security and billing stay at the top unless the entity runs its own identity provider or pays its own bill. Split the top role so one person can do one job, as Notion does; its custom roles, in beta when read, can limit analytics, audit log, content search and billing permissions to chosen workspaces. Our guide to roles and permissions UX for B2B SaaS covers the role model inside one workspace.
What should children inherit?
Four patterns appear in the docs. Slack says an organization’s settings override individual workspace settings, and workspace owners can approve apps only where the organization has not decided. GitHub’s enterprise SAML configuration overrides organization configurations, and organizations cannot override it. Notion lets each security setting be workspace managed, enabled for everyone or disabled for everyone. Google Admin marks each setting Inherited or Overridden.
| State | What the child admin sees | Use it for |
|---|---|---|
| Enforced by parent | Locked, with the owner named | SSO, mandatory two-factor authentication, IP allowlists, audit retention floor |
| Default from parent | The inherited value; an override is marked | Sharing defaults, naming, language |
| Set by child | Editable; the parent can read it | Workspace access, templates, local channels |
Slack shows a lock icon on locked preferences, and Notion tells workspace owners a setting is managed by the organization. Both cues are worth copying.
Our view: a child may tighten an enforced setting but never loosen it. Avoid the pattern in Notion’s docs where the most granular setting wins: a teamspace can publish Sites and forms to the web even when the organization disables publishing. Before saving a parent change, list the children that hold overrides, because Google keeps custom settings unchanged when a parent changes. Policy design is in our guide to admin security policies; SSO setup is in the one on SSO and SCIM.
How do people in several workspaces sign in and switch?
Slack gives an organization user the same identity and profile across workspaces, and its design module suggests members spend 80% or more of their time in a home workspace. Figma assigns each person to one workspace, yet people can still join teams outside it and browse libraries in other workspaces. Linear treats each workspace as separate, with its own members and a switcher; a second email address adds a second account. Notion warns that someone in two workspaces requiring different providers may be asked to sign in to each.
Our view: one identity across entities, a home entity set at invitation, and a switcher that names the entity and shows which policy applies. Treat a copy across a boundary as a decision; Notion has an organization setting for who can duplicate pages to other workspaces.
How do you move people and data between workspaces?
| Move | What the docs say | Lesson |
|---|---|---|
| Slack, workspace into an organization | History, files and apps carry; DMs across workspaces merge; custom profile fields do not carry into an existing organization; the Workspace Primary Owner role goes to the Org Primary Owner | Show conflicts first; Slack has a checklist for conflicting accounts and settings |
| Figma, people between workspaces | Workspace admins move people only between workspaces they manage and claim from Unassigned | Keep an unassigned pool |
| GitHub, organization into an enterprise | Usage is billed to the enterprise, enterprise SAML overrides the organization, and if the enterprise requires 2FA, members without it are locked out until they set it up | Preview the effects |
| Atlassian, two organizations merged | Same-name groups are renamed, the source admin group loses admin rights, the identity provider can provision users into all sites, and the merge cannot be split back | Rehearse a one-way move; Atlassian requires written approval of a dry run |
| Linear, new data region | Residency cannot change; create a new workspace and import | Tell buyers which attributes are permanent |
Our view: a move needs a preview of the users, groups, settings and billing that change, a named approver on each side (Slack requires a Workspace Owner or Admin on both sides to move a channel), a log entry, and a plain line when it cannot be reversed.
Should billing follow the admin tree?
| Pattern | Documented example | Design need |
|---|---|---|
| Plan per workspace | Linear bills unsuspended users in one workspace; the plan covers that workspace only | One invoice per entity |
| Parent pays | GitHub bills the usage of added organizations to the enterprise. Slack’s admin dashboard shows a billing summary and a billable members report | A seat report by entity |
| Parent pays, children charged back | GitHub cost centers define billing structure independently of organizations. Figma billing groups sort people by budget source | Chargeback tags apart from the admin tree |
| One count across workspaces | Notion’s People tab dedupes members and guests across workspaces to show billing impact | A stated rule for people in two entities |
Our suggestion: decide whether a person in two entities costs one seat or two, and print the answer on the seat screen and the invoice. Give billing its own role, as GitHub and Notion do. Seat true-ups inside one entity are in our guide to billing and plan changes.
How do search, reports and audit work across entities?
Notion filters its organization search, audit log and analytics by workspace, and keeps audit history for up to 365 days. GitHub’s enterprise audit log lists events from the last 180 days and names the enterprise or organization where each action happened; Git events are kept seven days. In Atlassian, unit admins see logs only inside their unit. In Entra, people search stays within each tenant unless users are provisioned into every tenant.
Our view: label every view and export with its scope (this workspace, selected workspaces, whole organization), let the role decide which scopes appear, and put the entity on every audit row. Report design inside one entity is in our guide to usage reports for admins.
What does an entity map look like?
Fill one row per entity before anyone builds. Everything below is invented. A startup, Tallyhaven, sells claims-review software. Its buyer, Norland Group, has a parent, two subsidiaries in different regions and a recent acquisition.
| Entity | Administered by | Inherits | Set locally | Billing | Data boundary | Report scope |
|---|---|---|---|---|---|---|
| Norland Group (parent) | Two group IT owners; a billing role | Sets the floor | Audit export | Pays one invoice | Holds no claim data | Counts only |
| Norland Nordics (EU subsidiary) | A local admin | SSO, two-factor authentication, IP allowlist | Workspace access, templates | Charged back by seat | EU region | Own claims; group sees counts |
| Norland Marine (acquired) | A local admin | Two-factor authentication floor only | Own SSO setup | Own invoice for 12 months | Own workspace | Own claims |
Three events test it. A claims lead works for both subsidiaries: one login, a home entity, a switcher that names the other, and a logged reason for any copy between them. The parent shortens the idle timeout: the preview lists Marine as holding an override, which keeps its own value until its admin accepts the new one. Norland sells Marine: the group admin starts a split, and the preview lists the users, data and invoices that leave, an export of the group’s audit trail and the date the buyer’s identity provider stops provisioning. Atlassian says its merge cannot be undone, so design the split before you need it.
Where does this go wrong?
- Overrides outlive parent changes. Show the admin how many children a parent edit actually reaches.
- The lowest setting wins. Decide in writing whether a child may loosen what the parent set.
- A merge grants access nobody planned. Atlassian warns that groups synced through SCIM can carry users across legal entities.
- Lockout at two levels. In Notion, when SAML is managed at the organization level, only organization owners can bypass SSO. Keep a break-glass login at each level.
- Weak evidence. The vendors above document features, not outcomes, and several are plan-gated: Figma workspaces and Notion organization controls need Enterprise plans. No source here shows that one model lowers onboarding time or support load, so measure your own.
What can you produce now?
- An entity map for your three largest buyers.
- A list of every setting, marked enforced, default or local.
- An admin role table with parent and child columns.
- A move preview sketch for a merge and a split.
- A billing rule for people who belong to two entities.
- Test cases: a two-entity user, a parent change with an override, a divestiture and a lost identity provider.
- A plan for choosing a design partner; our page on design agencies for startups building enterprise software explains what to look for.
Then take your largest buyer, fill one row per subsidiary and see which cells you cannot answer yet.
