Permissions

Permissions define what operations a role can perform on which resource groups. They are the primary mechanism for controlling day-to-day access, determining whether a user can view, create, edit, or delete records in a given business area. The permission system distinguishes between ALL_RECORDS scope (access to every record in the tenant) and OWN_RECORDS scope (access only to records the user owns or that have been shared with them).

Permission definitions

Each permission has the following key attributes:

Field	Description
target_resource_group	A three-letter business area code (e.g. CRM, HRM, FAR, BIL)
target_resource_name	The specific resource within the business area
operation	The operation this permission governs (e.g. SELECT, INSERT, UPDATE)
permission_name	A human-readable name for the permission
permission_code	A unique machine-readable code, unique per tenant
permission_description	A free-text explanation of what the permission allows

Permissions are data-driven — they are stored as configurable records, not hard-coded. This allows tenants to define custom permissions for new business areas or adjust existing ones without code changes.

Role–permission assignments

Permissions are linked to roles through role-permission assignments. Each assignment connects:

• A role
• A permission
• A scope that determines how broadly the permission applies

This means the same permission can be assigned to different roles with different scopes. For example, a "CRM Administrator" might receive a CRM SELECT permission with ALL_RECORDS scope, while an "External User" receives the same permission with OWN_RECORDS scope.

Scope: ALL_RECORDS vs OWN_RECORDS

The scope column on the role–permission assignment is the key mechanism for distinguishing between internal and external access:

ALL_RECORDS

Users with ALL_RECORDS scope can access every record of the target resource type within their tenant. This is the default scope for internal roles (those inheriting from "Tenant Staff"). It means:

• Read operations return all matching records in the tenant
• INSERT, UPDATE, DELETE operate without ownership restrictions
• The user sees the full dataset for that business area

OWN_RECORDS

Users with OWN_RECORDS scope can only access records they own or that have been explicitly shared with them. This is the default scope for external roles (those inheriting from "External User"). It means:

• Read operations return only records where the user is the owner or a shared recipient
• INSERT creates records owned by the user
• UPDATE and DELETE are restricted to owned records
• The user sees a filtered view of the dataset

How scope is enforced

Scope is enforced whenever a user attempts to access a protected resource:

1. The platform identifies the user's current roles.
2. It finds the matching permission for the target resource and operation.
3. If the scope is ALL_RECORDS, access can apply across the tenant.
4. If the scope is OWN_RECORDS, access is limited to records the user owns or that have been explicitly shared with them.

Domain-level permissions

Permissions are organised by resource group. A typical business area has permissions for the core operations:

Operation	Meaning
SELECT	Read/view records
INSERT	Create new records
UPDATE	Modify existing records

Some domains also define resource-specific permission overrides for cases where the default domain-level permission is too broad. For example, a role might have general read access to CRM records but a specific restriction on a sensitive resource.

Permission inheritance through roles

Because permissions are attached to roles, and roles form a hierarchy, permissions effectively cascade through the role hierarchy:

• A "CRM Viewer" role with SELECT permission on CRM resources passes that permission to "CRM User" (which inherits from CRM Viewer) and "CRM Administrator" (which inherits from CRM User).
• Higher roles in the hierarchy accumulate permissions from all their ancestors.
• This means administrators only need to define permissions at the lowest appropriate level in the hierarchy — they automatically flow upward.

note

Permission inheritance follows the role hierarchy, not the permission definitions themselves. A permission is simply a record; it only becomes active when assigned to a role that a user holds (directly or through inheritance).

Relationship to other access control layers

• Authorization policies provide targeted PERMIT/FORBID overrides for specific principals and resources. See Authorization Policies.
• Relationship-based access handles ownership, sharing, and group membership. See ReBAC Authorization.
• Role menus control UI visibility but do not enforce data access. See Role Menus.