Account Hierarchy for Multi-Tenant SaaS: Design, Permissions and Examples

What is an account hierarchy in B2B SaaS?

An account hierarchy is a parent-child structure connecting customer accounts inside a B2B SaaS product. It lets an enterprise, reseller, agency or managed service provider organize regional offices, departments, brands or customers beneath a main account while controlling who can view and manage each branch.

For example, a reseller might have one parent account, separate sub-accounts for each customer, and additional child accounts for customer regions. The hierarchy represents relationships between those accounts; it does not replace the tenant boundary or the application’s own data-isolation controls.

Account hierarchy versus multitenancy

Multitenancy and account hierarchy answer different questions.

A SaaS product can use multitenancy without nested accounts. It needs account hierarchy when a customer must manage several related accounts from one controlled structure.

When do SaaS products need account hierarchies?

Account hierarchies are especially useful when:

• a reseller or MSP manages separate customer accounts;
• an enterprise needs regional or departmental administration;
• a franchise operator manages locations independently;
• an agency manages several brands while keeping brand teams separated;
• administrators need access to an entire branch without receiving unrelated access;
• reporting or billing must roll up from child accounts to a parent.

Do not add hierarchy merely because the product is multi-tenant. A flat organization model is easier to reason about and secure when customers do not need nested administration.

Model the hierarchy as accounts, memberships and permissions

The account tree should remain separate from user membership and authorization.

1. Accounts form the parent-child structure.
2. Memberships connect users to accounts.
3. Roles and permissions define what a membership can do.
4. Inherited branch access expands which descendant accounts a user may reach.
5. Application data controls still enforce the selected account on every resource operation.

Moving an account, changing a role and granting access to a branch are different security events. Combining them into one implicit rule makes access difficult to audit and revoke.

Design parent and sub-account permissions explicitly

Avoid a single broad “hierarchy admin” permission. Separate at least these operations:

• view sub-accounts;
• create or update a sub-account;
• delete an empty sub-account;
• grant or revoke user access to sub-accounts;
• enable sub-account management for a child account;
• switch into an accessible account;
• view hierarchy-wide reports or billing.

Frontegg documents separate permissions for reading, creating/updating and deleting sub-accounts, as well as granting users access to sub-accounts. Decomposing structural administration into auditable actions avoids one all-powerful hierarchy capability.

Treat inherited access as a security decision

Granting access at a parent can simplify administration by extending access to current and future descendants. It can also enlarge a user’s effective scope after a new child account is created.

Before enabling inherited branch access, decide:

• whether it applies to current descendants, future descendants or both;
• whether child administrators can override inherited access;
• which role or permissions apply at descendants;
• how revocation propagates;
• how the effective-access set is calculated and audited;
• whether sensitive child accounts can block inheritance.

Test the negative path: a valid user who can access one branch must still be denied access to siblings and unrelated accounts.

Build account switching from effective access, not assumptions

An account switcher should display the accounts the user can actually access, including access obtained through a hierarchy rule. It should not assume that every accessible descendant is listed directly in one token or user-state object.

Frontegg’s current hierarchy documentation makes this boundary explicit: accounts available through sub-account access are not automatically listed in the user’s JWT or user state. Applications implementing a switcher need to resolve the accessible account set through the relevant APIs before presenting the list.

After a switch, the application must enforce the newly selected account consistently in authorization checks, database queries, cache keys, object paths, background jobs, search indexes and audit events.

Example: an agency managing several brands

Consider an agency that manages three brands:

Agency parent
├── Brand A
│   ├── US
│   └── EU
├── Brand B
└── Brand C

Agency administrators may need access to the entire tree. Brand A administrators should manage Brand A, US and EU but not Brand B or Brand C. A regional operator for Brand A US should remain restricted to that account.

Use explicit memberships with narrowly defined branch access. Every request still carries or resolves one active account context, and the application scopes its resources to that context.

Account-hierarchy lifecycle rules

Hierarchy changes deserve the same rigor as role changes.

• Prevent cycles: a child cannot become its own ancestor.
• Define whether an account can have more than one parent.
• Block deletion while child accounts remain, or require an explicit migration plan.
• Decide what happens to memberships, invitations, SSO connections and data when an account moves.
• Record who created, moved, detached or deleted an account.
• Recalculate cached effective access after structural changes.
• Test whether future-child access behaves as administrators expect.

Frontegg currently documents that sub-accounts can be deleted only when they have no associated children. This prevents a parent deletion from silently orphaning a branch.

How Frontegg account hierarchies work

Frontegg supports parent accounts with nested sub-accounts for enterprise, reseller and other multi-level structures. Authorized users can manage the hierarchy through the All Accounts area, view it as a table or graph, create child accounts and grant users access to sub-accounts.

The documented permission set includes:

Because SDK requirements and behavior can change, implementation teams should use the current Frontegg hierarchy documentation and permissions table as the technical source of truth.

Account-hierarchy checklist

Before shipping a hierarchy feature, verify that:

• the parent-child model cannot form cycles;
• permissions for viewing, editing, deleting and granting access are separate;
• parent access does not accidentally expose sibling branches;
• future-child inheritance is intentional and visible to administrators;
• the account switcher uses the effective accessible-account set;
• every data and background-processing path is scoped to the active account;
• hierarchy changes invalidate cached access decisions;
• deletion and account moves have explicit constraints;
• audit events capture structural and access changes;
• tests attempt cross-branch reads and writes with valid identities.

Frequently asked questions

Is account hierarchy the same as multitenancy?

No. Multitenancy isolates customer organizations that share an application. Account hierarchy organizes related parent and child accounts and defines how they may be administered.

Does a parent role automatically belong in every child account?

That depends on the product’s access model. If branch inheritance is enabled, document whether the role itself, its permissions or only account access propagates. In Frontegg, sub-account access can extend across a branch, and roles assigned at a parent may apply to its sub-accounts under the documented hierarchy behavior.

Can an account switcher rely only on the JWT?

Not always. Frontegg documents that accounts available through hierarchy-based sub-account access are not automatically listed in the user’s JWT or user state, so the application must resolve accessible accounts through APIs.

Can a parent account be deleted while it has children?

Deletion rules vary by platform. Frontegg documents that a sub-account can be deleted only when it has no associated children.

How deep should an account hierarchy be?

Use the shallowest structure that represents the customer’s real administrative boundaries. Frontegg’s public documentation does not state a universal maximum depth, so confirm current product constraints before promising a specific number of levels.