Getting started with account hierarchies

An account hierarchy is a system representing relationships between entities in an organization, including parent-child structures or multiple nested layers. This structure helps manage complex setups, improving communication, efficiency, and accountability.

With Hierarchies (Sub-account Management), you can create parent accounts with nested sub-accounts. Users can belong to any tenant or to a tenant and its subtenants.

While both hierarchies and multitenancy manage multiple entities, they have distinct purposes. Multitenancy serves multiple tenants from a single software instance, each with isolated data and configurations. Hierarchies, on the other hand, manage relationships and dependencies within a single tenant, providing granular control and resource allocation.

In Frontegg, users main parent account can create and manage sub-accounts within a hierarchy, offering more control over their account structure—ideal for complex setups or reselling scenarios. This is provided from All Accounts section under Frontegg's self-service portal.

Sub-accounts management

Step:1 Enabling sub-account management on an account

Management → Accounts → [ACCOUNT] → Settings → Sub-account management toggle.

Step 2: Assigning permissions

To access the All Accounts tab in the self-service portal, users must be assigned specific roles with corresponding [Permissions]:

1. Read access to sub-accounts:
   To view the "All Accounts" tab, users must have the role that grants them the "Read sub-accounts" permission: fe.account-hierarchy.read.subAccount. This permission allows them to view sub-account information.

2. Create or update sub-accounts:
   If users need to create or update sub-accounts, they should be assigned a role with the "Create or update sub account" permission: fe.account-hierarchy.write.subAccount. This permission enables users to add new sub-accounts or modify existing ones.

3. Delete sub-accounts:
   To delete sub-accounts, users must have a role with the "Delete sub-accounts" permission: fe.account-hierarchy.delete.subAccount. With this permission, users can remove unwanted sub-accounts from the system.

4. Grant access to sub-accounts:
   If users need to provide access to sub-accounts within the account hierarchy, they should be assigned a role with the "Give access to sub-accounts" permission: fe.account-hierarchy.write.subAccountAccess. This permission allows users to assign access rights to other users for specific sub-accounts.

By ensuring users have the appropriate roles and permissions, you can control their access levels and actions within the self-service portal effectively.

Once the toggle for sub-account management is enabled and the relevant admin roles are assigned with the above permissions - an All Accounts section will appear in the end user's self-service menu.

Sub-accounts self-service

The self-service portal allows end users to self-manage tenant access, create sub-accounts, manage roles, and more. Once sub-account management is enabled, users can access a dedicated Managed section within their All Accounts menu.

When viewing All Accounts, users can see their account hierarchy in 2 views: Table and Graph.

In the table view, your main account is listed at the top, followed by all sub-accounts. The layout includes key details like account names, user counts, and creation dates, making it easy to track and manage accounts at a glance.

Switching to the graph view gives you a better representation of how your account tree looks

Creating sub-accounts

To create sub-accounts, users with the necessary permissions can go to the All Accounts section and click Create New Account. They just need to specify an account name and choose a parent account.

If a an account has sub-account management enabled and the user holds the fe.account-hierarchy.write.sub-account-management permission, they can enable or disable sub-account management for child accounts. When enabled, the child account can access the All Accounts page.

Managing individual sub-accounts

To access specific sub-account details, click on the account name in either the table or graph view. There, you'll see a summary, including the account name, its hierarchy, user count, and sub-account total.

To delete a sub-account, navigate to the sub-accounts section in your master account and choose the sub-account you want to remove. Then, proceed to delete the sub-account, which will promptly remove it from the hierarchy. Please note that sub-accounts can only be deleted if they have no associated children.

Inviting users to sub-accounts

Users can be invited to sub-accounts through two methods: explicit invitations or by granting access through a parent account.

Explicitly inviting users to accounts

You can invite users directly to accounts by clicking the Invite Users button. When you do so, they will receive an activation or an invitation by email.

Giving access to sub-accounts

To grant user access to a specific branch of the hierarchy without inviting them to each account individually, you can assign access from the parent account, extending it to all current and future sub-accounts. The user will have full access to all the sub-accounts on that branch and will be able to switch to these account if the functionality was implemented. The role assigned at the parent account will apply to all sub-accounts within that branch.

Sub-account access can be set during the invitation process or adjusted later, providing flexibility and control over user access within the hierarchy.

Sub-account access settings

To allow users set default sub-accounts access, make sure they have fe.account-hierarchy.write.subAccountAccess permission. Then, under All Accounts tab in your application's self-service under the three dots at the top right corner of the account page, find the settings. End users can select the default state for new users that will be invited to the application.

The Default off setting prevents users from accessing sub-accounts upon invitation. You can change this default on demand.

Default on gives users sub-account access by default. You can change this default on demand.

Always on affects all account users (current and future) and cannot be revoked. If you change it later to Default on or Default off, the users who were invited to the account previously will still have access. The settings will only affect future users.