Access overview
How remoteEaze combines roles, permissions, data scope, application access, policies, and record state.
remoteEaze does not decide access from a job title alone. A user can perform an action only when every applicable access control allows it.
For example, a user may need Create Transaction, access to the Transaction's booking branch, and permission to use the selected Accounts. If the Transaction must be approved, the checker also needs the correct approval authority.
The access controls
| Control | What it decides |
|---|---|
| Platform and Company boundary | Whether the user can work across Companies or only within their own Company. |
| Dashboard and Workbench access | Which application surface the Role can open. |
| Entity and action permission | Whether the Role can perform an action such as Create, Read, Update, Export, Reverse, or Decrypt on an entity. |
| Data-access scope | Which records the user can work with under System, Organization, Branch, or Self scope. |
| Record state | Whether the action is valid for the record's current status. |
| Maker-checker | Whether the record must be submitted and approved before it becomes Authorized. |
| Approval authority | Whether the user can act at the exact L1, L2, or L3 stage currently waiting. |
| Conditional access policy | Whether a matching condition changes an approval requirement, changes an allowed outcome, or blocks the action. |
| Workflow assignment | Whether the user is assigned to the current stage of an operational workflow. |
How the checks work together
These controls are cumulative. Passing one check does not replace another. For a permission decision, remoteEaze applies the following order:
- The reserved L0 System Administrator bypass is checked.
- The Company and data-access scope are checked.
- The Role's entity and action permission is checked.
- Any matching validation block is applied.
- The first matching conditional access policy can refine the allowed outcome or required approval count.
- If no conditional policy matches, the Role's ordinary permission result is used.
The business journey can then apply additional checks such as record status, maker-checker separation, approval level, workflow assignment, and entity specific rules. The interface uses the resolved access to decide which sidebar items, tabs, buttons, and workflow actions to show, but the server performs the final authorization check.
This is why a user can be able to read a Transaction but not authorize it, or have L1 authority but be unable to authorize a Transaction outside their booking-branch scope.
Where access is configured
- Access Control → Roles & Permissions defines application access, entity and action permissions, required approvals, and approval authority.
- Access Control → Access Policies defines the currently supported transaction-family conditions and Company-wide validation blocks.
- The user form defines Data Access Scope, the primary branch, and any additional Accessible Branches.
- The user form can also restrict working hours, weekends, and holidays.
Continue with Platform, Company, and user boundaries, then Roles and permissions and Data-access scope.