Roles and permissions
How Roles grant entity actions, supporting Read access, and approval authority.
A remoteEaze Role answers three questions:
- Can the user open Dashboard, Workbench, or both?
- Which actions can the user perform on each entity?
- Which maker-checker stages can the user authorize?
Configure Roles under Access Control → Roles & Permissions. Creating or editing a Role requires the corresponding Role permission.
Entity and action permissions
Permissions combine an entity with an action. Common actions include Create, Read, Update, Delete, and Export. Some entities add special actions that reflect the work performed in their screens.
Examples include:
- Transaction: Reverse and Override FX Rate
- Activity Log: Decrypt
- Notification Configuration: Publish
- Customer Application, Loan Application, Loan Variation, and Fixed Deposit Application: Assign, Process Workflow, and Waive
- License: Update Config and Update Contract
System-generated records and records managed through a parent show only the actions that can be performed directly. For example, Transaction Line changes are controlled through the Transaction. Workflow stages, transitions, requirements, actions, and action rules are controlled through the parent Workflow Definition permission.
Operational workflow permissions
| Permission | What it allows |
|---|---|
| Create, Read, Update, Delete | Maintains the application record. Update also covers capturing or recapturing workflow requirements and supporting information where the screen provides those actions. |
| Assign | Assigns the current workflow stage, claims an unassigned stage, or accepts a routed assignment. |
| Process Workflow | Records an ordinary workflow decision and performs a valid transition. The current stage, assignment, requirements, and configured workflow still control which action is available. |
| Waive | Records an exception only where the relevant requirement or rule is explicitly configured as waivable. A reason is required. |
Process Workflow cannot bypass a workflow. Waive does not grant normal workflow decisions, and Update does not grant waiver authority.
Permission names, not job titles
A Role name describes how a Company intends to use that Role. The name itself does not grant access. Always check the Role's permission matrix.
For this reason, the guide says requires Create Account instead of saying that only a particular job title can create an Account.
The standard tenant-administrator Role starts with broad Company permissions. Custom Roles can be narrower or can use that Role as a template. The reserved System Administrator Role is not available as a template.
Supporting Read permissions
Some actions need supporting data. remoteEaze adds missing Read permissions required by the selected forms and detail pages.
When a permission change needs supporting access, the Review Implied Permissions dialog shows the entities that will also receive Read access. Creating an entity also implies Read access to that entity. Where a detail page uses external IDs, its Read permission can also imply access to the required third-party mapping data.
Supporting Read access does not grant Create, Update, Delete, approval authority, or broader data scope. Removing the permission that introduced the Read access does not currently remove that Read access automatically. Review the complete Role after reducing its access.
Required approvals and approval authority
For a maker-checker entity, an allowed action can be set to Auto-approve, 1 Approval, 2 Approvals, or 3 Approvals. This setting determines how many sequential checker decisions the submitted change needs.
The separate Approval Authority controls whether the Role can act at L1, L2, or L3. Requiring two approvals does not make the maker's Role an approver. See L1, L2, and L3 authorization.
Entities that do not use maker-checker display No approval required. Their changes take effect without a staged approval status lifecycle. Use Approval model by entity to identify which visible permission entities use maker-checker.