Create and manage roles

Open Organization → Access Control → Roles & Permissions.

Access

• Read Role shows the role list and role details.
• Create Role permits role creation.
• Update Role permits role metadata changes.
• Delete Role permits deletion when the role is not assigned to a user.
• Read Permission Matrix shows permissions; Update Permission Matrix is required to save matrix changes.

Roles themselves do not use maker-checker. Changes to role capability flags or activation revoke the sessions of users assigned to that role so their next session uses the new access rules.

Create a role

1. Select Create Role.
2. Enter a unique Role Name and optional description.
3. At L0, select a company or System Scope.
4. Configure Field Agent Role and Dashboard Access.
5. Optionally select a Permissions Template from another role in the same tenant.
6. Select Create Role.

remoteEaze generates the internal role slug from the name. A permissions template copies the starting matrix; later changes to the source role do not automatically change the new role. The reserved System Administrator role cannot be used as a template.

Dashboard and Workbench access

Enable Field Agent Role for roles that can use the offline-capable Workbench. Turning it on initially turns Dashboard Access off, but you can turn Dashboard access back on for a hybrid role that needs both surfaces.

A non-agent role cannot be given Workbench access merely by assigning entity permissions. See Dashboard and Workbench access.

Configure the permission matrix

Open the role and use Permission Matrix. For each entity, enable only the supported actions the role needs. Depending on the entity, these can include Create, Read, Update, Delete, Export, or a purpose-specific action such as Decrypt, Reverse, Assign, Process Workflow, or Waive.

For a maker-checker action, choose Auto-approve, 1 Approval, 2 Approvals, or 3 Approvals. This defines the number of checker decisions created when the action is submitted. It does not grant the role authority to perform those approvals.

Use the separate Approval Authority controls to grant L1, L2, or L3. The runtime sequence is L1, then L2, then L3, and finally Authorized. Entities that do not use maker-checker show No approval required and do not expose approval settings.

Select Save Changes for the entity being edited. If selected actions need supporting Read access, Review Implied Permissions lists the Read permissions that will be added. Implied permissions do not add write access, approval authority, or broader data scope, and removing the original action does not automatically remove an implied Read already saved.

See Roles and permissions and L1, L2, and L3 authorization for the complete model.

Review role policies and information

The role detail has three tabs:

• Permission Matrix for actions and authorization authority;
• Access Policies for role-specific conditional transaction-family rules;
• Role Information for role metadata and audit details.

The reserved System Administrator role is protected. Its metadata, permission matrix, and policies are read-only in the interface, and it cannot be deleted or copied as a template.

Before assigning the role, verify its Dashboard and Workbench flags, permission matrix, approval authority, and access policies together. The user's data-access scope remains a separate restriction.