Skip to main content

Role Menus

Role menus control what users see in the Raytio UI. Each role is assigned one or more menus, and the menu entries within those menus determine which navigation items, actions, and features are visible. This ensures that users only see parts of the interface that are relevant to their role and that they are authorised to use.

How role menus work

The menu system has three layers:

  1. Menus — top-level groupings (e.g. "CRM", "Billing", "Administration", "My Dashboard")
  2. Menu entries — individual items within a menu (e.g. "Contacts", "Invoices", "Create Quote"), each linked to a schema, permission resource group, and available actions
  3. Role–menu assignments — the link between a role and the menus it can access

When a user logs in, the platform resolves the user's roles, including inherited roles from the hierarchy, collects all menus assigned to those roles, and returns the combined set of menu entries the user should see.

The platform provides menus for major product and administration areas. The exact set of menus is reference data and may change as modules are added, renamed, or configured for a tenant.

Internal menu examples

Internal menus are assigned to roles that inherit from "Tenant Staff". Examples include:

  • CRM menus for customer relationship management
  • Billing, pricing, and accounts receivable menus for commercial operations
  • Data sharing and verification menus for identity and data workflows
  • Administration, security, and platform menus for tenant management
  • Project menus for project portfolio management

External menu examples

External users, meaning users who inherit from "External User", may see a smaller self-service menu set. For example:

  • A personal dashboard menu with entry visibility controlled by the user's permission resource group

These examples describe the pattern rather than the authoritative menu catalogue. The maintained list of available menus should live in reference data or a dedicated reference page.

Each menu entry defines:

  • Schema — the data schema the entry relates to
  • Permission resource group — the business area code used to check whether the user has permission to see this entry
  • Actions — the operations available from this entry (e.g. create, edit, delete)

The actions shown on each menu entry are filtered by the user's permissions. A user with only SELECT permission on a resource group will see the menu entry but will not see create, edit, or delete actions.

Menu entry overrides

Menu entry overrides allow specific menu entries to be hidden or modified for particular roles. This provides fine-grained control over UI visibility without changing the underlying permission structure.

For example, a "Billing Viewer" role might be assigned the Billing menu but have the "Create Invoice" entry overridden to hidden, since viewers should not see creation actions even though the menu as a whole is relevant to them.

Inheritance and menus

Menu assignments follow the role hierarchy:

  • If a "CRM User" role is assigned the CRM menu, then "CRM Administrator" (which inherits from CRM User) also has access to that menu.
  • Higher roles in the hierarchy accumulate menus from all their ancestors.
  • A high-level administrator role, such as "Tenant Admin", commonly inherits from domain administrator roles and therefore accumulates the menus assigned through those branches.

This means menu assignments only need to be defined at the lowest appropriate level in the hierarchy — they propagate upward automatically.

It is important to understand that menus control visibility, not access:

  • A user who can see a menu entry is not necessarily allowed to perform the action — permissions and authorization policies are still evaluated when the user attempts the operation.
  • A user who cannot see a menu entry might still have access to the underlying data through other means (e.g. API calls, shared records).
  • Menus provide a usability layer that ensures the UI is clean and relevant, while permissions and policies provide the security layer that enforces actual access control.
note

Menus should always be consistent with permissions — a user should not see actions they cannot perform. The platform cross-references menu entry actions with the user's permission set.