Role Groups and Inheritance

Role groups are the mechanism by which the role hierarchy is represented for relationship-based access. Each role becomes a group, and parent-child relationships between roles become parent relationships between groups. The authorization model resolves these transitively, so a user assigned to a single role automatically inherits access from every ancestor in the hierarchy.

From roles to groups

When roles are created or modified, the platform translates the organisational model into relationship-based access:

Concept	Relationship representation
Role "CRM Administrator"	Group group:crm_administrator
User Alice assigned to role	user:alice → member → group:crm_administrator
CRM Administrator inherits from CRM User	group:crm_administrator → parent → group:crm_user

This translation happens automatically. Administrators work with roles, and the corresponding group structure is kept current for access checks.

The inheritance graph

The default tenant configuration seeds parent–child edges for the standard role hierarchy. A simplified example looks like this:

Key observations:

• Internal roles commonly inherit from "Tenant Staff" — this is the base group for internal users, ensuring internal users have a minimum set of access.
• "Tenant Admin" commonly inherits from domain administrator roles — giving the tenant administrator broad access across business areas.
• "System Admin" inherits from "Tenant Admin" — the highest-privilege role.
• "External User" is a separate tree — external users do not inherit from "Tenant Staff" and have an independent, more restricted hierarchy.

Transitive resolution

The authorization model resolves group membership transitively. This means that when checking whether a user has access, it follows the full chain of parent relationships:

1. Alice is a member of group:crm_administrator
2. group:crm_administrator has parent → group:crm_user
3. group:crm_user has parent → group:crm_viewer
4. group:crm_viewer has parent → group:tenant_staff

The platform resolves the complete set of groups a user belongs to. In this case, Alice would be in: crm_administrator, crm_user, crm_viewer, and tenant_staff.

Any permission, menu, or access rule attached to any of these groups applies to Alice.

Seeding the hierarchy

The role group hierarchy is created during tenant initialisation. The default hierarchy commonly includes:

• Domain-specific chains (Administrator → User → Viewer → Tenant Staff)
• Cross-domain inheritance for the Tenant Admin role
• Backward-compatibility edges (e.g. "Admin" group inheriting from "Tenant administrator")
• The separate External User hierarchy

Tenants can customise the hierarchy after initialisation by adding or removing parent-child relationships.

How inheritance affects access

When any access check runs, the system resolves the user's full group set and evaluates all applicable rules:

Check type	How groups are used
Relationship check	Parent relationships are followed to find indirect memberships
Permission check	User roles and inherited roles are resolved to find matching permissions
Menu resolution	Menus are collected from all roles in the user's group set
Policy evaluation	Role policy assignments apply to all users who hold the role or inherit from it

This means a single role assignment can cascade through the entire hierarchy, granting the user access defined at multiple levels. Conversely, removing a parent–child edge immediately restricts all roles below that point from inheriting the parent's access.

Customising the hierarchy

Tenants can modify the role group hierarchy by:

• Adding new roles — creating a new role in HRM and assigning it parent roles
• Changing parent relationships — adding or removing parent–child edges
• Creating domain-specific branches — extending the hierarchy for custom business areas

Each change is reflected automatically, so access checks always use the current hierarchy.

note

Modifying the role hierarchy affects all users who hold roles in the modified branch. Changes should be made carefully, as removing a parent relationship immediately revokes inherited access for all affected users.

Relationship to other concepts

• User roles define the organisational structure that becomes the group hierarchy. See User Roles and Role Hierarchy.
• Relationship-based access represents group relationships. See ReBAC Authorization.
• Permissions attached to roles cascade through the hierarchy. See Permissions.
• Menus assigned to roles propagate to all inheriting roles. See Role Menus.