Account Hierarchy for Multi-Tenant SaaS: Definition, Benefits & Examples

What Is Account Hierarchy in B2B SaaS? 

In B2B SaaS, an account hierarchy is a structured system that represents the relationships between organizations, sub-accounts, and users within a multi-tenant platform. It defines parent-child relationships between accounts — for example, an enterprise customer’s headquarters account and its regional or departmental sub-accounts — so permissions, billing, and data can be scoped correctly across the hierarchy. This structure can involve simple parent-and-child relationships, or extend across multiple nested layers depending on how complex the organization is.

Note: this is different from the CRM/sales sense of “account hierarchy” — such as Salesforce’s structure for customer account relationships. See the Salesforce example further down this page for that context.

Account hierarchy is not limited to people and positions in an organization. It can also represent the relationships between different departments, projects, or even different companies under the umbrella of a larger corporation. It is a versatile concept that can be adapted to fit the specific needs and structure of many use cases.

Account hierarchies are often used in software solutions to manage the use of software within an organization, or to enable sales or support activity for other organizations. For example:

• Cloud computing platforms allow organizations to define multiple cloud accounts with a hierarchical structure. This makes it possible, for example, to define certain policies at a top-level account and have those policies apply to all the accounts within it.
• SaaS solutions intended for the use of organizations often allow an organization to define multiple user accounts with a hierarchical relationship between them. This allows for more granular access controls and personalization of product features.
• Customer Relationship Management (CRM) and support tools allow organizations to define organizational units and roles within their customer or prospect organizations to manage their communication more effectively.

This is part of a series of articles about identity and access management.

Account Hierarchy vs. Multi-Tenancy vs. Organizational Hierarchy

Source: Frontegg’s own documentation distinguishes hierarchies (“managing relationships and dependencies within a single tenant”) from multi-tenancy (“serving multiple tenants… with isolated data and configurations”). See Frontegg’s account hierarchy documentation for details.

Why Account Hierarchy Matters for Multi-Tenant SaaS 

In a B2B SaaS platform, account hierarchy matters because customers rarely map to a single flat account. Enterprise customers, resellers, and managed service providers often need to model their own internal structure — regional offices, business units, or franchise locations — inside your product. Account hierarchy gives the platform a way to represent that structure natively, rather than forcing every customer into one undifferentiated account.

Without it, delegated administration becomes difficult: a reseller or enterprise customer has no way to manage their own sub-accounts, assign scoped permissions, or control which users can access which parts of the structure. Authorization scope, SSO configuration, and data access all need a structural boundary to attach to — account hierarchy is what provides that boundary.

Account hierarchy also matters for billing and reporting: it lets a platform track usage, seats, or costs at the level that makes sense for the customer — per business unit, per region, or rolled up to the parent account — instead of a single undifferentiated number.

Key Benefits of a Well-Structured Account Hierarchy 

Here some of the primary benefits of using an account hierarchy in an organization or within a software tool:

• Clarity: Provides a clear picture of the organization’s structure, who reports to whom, and how the decision-making process works. This makes it easier to understand respective roles and responsibilities.
• Operational efficiency: When roles and responsibilities are clearly defined, tasks can be accomplished more efficiently. There is less confusion about who is responsible for what, and there is a clear path for the flow of information and decisions.
• Risk management: Account hierarchies allow managers, salespeople and support staff to identify potential risks and issues at an early stage, and take appropriate measures to mitigate them. It enables managers to have a bird’s eye view of the organization and take proactive measures to meet business goals.

Example: How to Build a Salesforce Account Hierarchy (CRM Context) 

Salesforce is a popular SaaS-based customer relationship management (CRM) platform, which offers an account hierarchy feature. Building a Salesforce Account Hierarchy involves creating relationships between Account records to illustrate the structure of parent companies and their subsidiaries. This feature is critical for visualizing organizational structures within Salesforce.

Note: this example illustrates account hierarchy in the CRM/sales sense — how Salesforce structures relationships between customer accounts. If you’re building multi-tenant account structures for a SaaS product, the sections above and below cover that context instead.

Steps to Implement Salesforce Account Hierarchy:

1. Access Account Hierarchy Feature: In Salesforce Lightning, access the Account Hierarchy feature, also available in Salesforce Classic for organizations not migrated to Lightning.
2. Set Up Parent/Child Relationships: Use the Parent Account field to establish a hierarchical relationship between accounts. This field links subsidiary accounts to their parent companies.
3. Customize the Account Site field: This field defines the nature of accounts, such as branches or headquarters. It provides a 80-character text field for flexible categorization.
4. Configure user permissions:
   1. Read Access: Ensure users have read access to the Account object and the Parent Account field.
   2. Write Access: Grant write access to the Parent Account field for users who need to update the hierarchy.
   3. Hierarchy Viewing: Assign the Account Hierarchy action or button to user layouts for viewing the hierarchy. Note that users can only view accounts they have permission to access.
5. Implement Dynamic Actions: Use Dynamic Actions for fine-tuned control over action visibility on the Account Record page. For example, hide the Account Hierarchy action from the Support team if unnecessary.
6. Populate the Hierarchy:
   1. Start by adding Parent Account and Account Site details to each account.
   2. Gradually build the hierarchy by repeating these steps for multiple accounts.
   3. Use data import tools like the Data Import Wizard or Data Loader for bulk updates.

Best Practices for Managing Account Hierarchy 

Managing an account hierarchy effectively involves a series of strategic steps to oversee and maintain the structure of user or organizational accounts within a system or platform. Here are the best practices to manage an account hierarchy:

• Access control policies: Establish access control policies for each part of the account hierarchy. These policies should define user roles, responsibilities, and permissions within the hierarchy, specifying what each role can and cannot do.
  • Security measures: If the account hierarchy provides access to sensitive data, it is important to implement robust security measures such as strong password policies, multi-factor authentication (MFA), and monitoring of user activity for unusual behavior to protect user accounts from threats.
  • Monitoring and alerts: To avoid unauthorized access to sensitive data, if applicable in your use case, set up monitoring systems capable of detecting and alerting to suspicious or unauthorized activities within the account hierarchy.
• User onboarding and offboarding: Ensure proper onboarding of new users or entities, and promptly update account status when users leave the organization or change roles. 
• Parent / child classification checks: Regularly review the parent and child account structures. Ensure they accurately reflect the actual relationships and dependencies between groups within the organization.
• Regular audits: Conduct periodic audits of user accounts and permissions to confirm alignment with organizational requirements. Address any discrepancies, like excessive permissions or outdated accounts.
• Change management: Implement a change management process for modifications to the account hierarchy. Ensure that changes are well-documented, tested, and communicated to all relevant stakeholders prior to implementation.
• Access requests and approvals: Establish a systematic process for users to request additional access or changes in their permissions. Such requests should undergo an approval process to prevent unauthorized access.

Managing Account Hierarchies with Frontegg

In Frontegg’s model, role assignments propagate one way — a role granted at a parent account automatically applies to every sub-account beneath it. Sub-accounts form a single-parent tree structure and can only be removed from the hierarchy once they have no child accounts of their own. Frontegg documents this model as well suited to reselling and other complex multi-level account structures. (See Frontegg’s account hierarchy documentation for full technical detail.)

How Account Hierarchy Affects Authorization and Account Switching

Suppose an admin is granted the Admin role at a parent account called North America, which has two sub-accounts, US and Canada. Because Frontegg propagates roles downward through the hierarchy, that Admin role automatically applies to both US and Canada as well — the admin does not need to be granted access separately in each sub-account.

There’s a non-obvious catch for account switchers: this inherited access is not automatically listed in the user’s access token (JWT) or their user state. Frontegg’s documentation states that “the accounts where they are allowed will not appear on the user’s access token (JWT) or the user’s state” and that an application implementing an account switcher will “need to calculate behind the scenes which accounts the user should have access to via APIs.” In practice, this means an application can’t just read the JWT to build an account-switcher UI — it needs to resolve the full set of accessible accounts, including inherited sub-accounts, via the API before rendering that list. (See Frontegg’s account hierarchy documentation.)

Frontegg is a leading customer identity and access management (CIAM) platform, which provides a comprehensive account hierarchies feature. This gives vendors the ability to create and manage sub-accounts within a hierarchical structure, particularly important for managing complex account structures or when allowing customers to manage or resell a product.

Within the Frontegg Admin Portal, users can oversee all associated accounts under their control. The presentation of accounts is available in two views: 

• Table view: Listing the main account at the top, followed by all sub-accounts with essential details like account names, user counts, and creation dates. 
• Graph view: Offers a visual representation of the account tree, enhancing the understanding of the account structure.

Creating sub-accounts is a streamlined process. Users simply provide a name for the new account and select an appropriate parent account, facilitating the hassle-free addition of sub-accounts to the hierarchy. 

FAQ

Is this the same as a Salesforce/CRM account hierarchy?

No. This guide is primarily about account hierarchy in B2B SaaS multi-tenant platforms — parent and sub-accounts used to structure a platform’s own customers. Salesforce’s account hierarchy (covered in the example above) is a related but separate CRM concept for organizing sales and customer records.

What’s the difference between an account and a tenant?

This varies by platform, so check your specific vendor’s docs — in Frontegg specifically, a tenant and an account are the same concept. An account hierarchy describes how a parent account can have nested sub-accounts (a third layer and beyond) within that tenant, which is different from multi-tenancy itself, which isolates separate tenants’ data from one another.

What’s the difference between account hierarchy and multi-tenancy?

Multi-tenancy isolates separate customers’ data and configuration from one another, while account hierarchy manages relationships and dependencies within a single tenant — this is the distinction Frontegg’s own documentation draws. See the comparison table above for a full breakdown.

How does role inheritance work across sub-accounts?

In Frontegg’s model, role assignments propagate downward: a role granted at a parent account automatically applies to every sub-account beneath it.

Is there a limit to how many levels an account hierarchy can have?

This varies by platform. Frontegg’s documentation does not specify a maximum nesting depth for account hierarchies.

Learn more about Frontegg enterprise readiness