L1, L2, and L3 authorization
How required approval counts differ from the authority to act at each level.
remoteEaze separates the number of approvals an action requires from the authority a checker has.
Required approvals
In Access Control → Roles & Permissions, each supported operational action on a maker-checker entity can use one of these settings:
| Setting | Result on submission |
|---|---|
| Auto-approve | Goes directly to Authorized. |
| 1 Approval | Starts at Pending Auth L1. |
| 2 Approvals | Starts at Pending Auth L2, then proceeds to L1. |
| 3 Approvals | Starts at Pending Auth L3, then proceeds to L2 and L1. |
The setting belongs to the operational action. For example, a role may be allowed to create a record with two required approvals while a different action has one or zero.
Approval authority
The role's separate Approval Authority controls whether the user may take a decision at each stage:
- L3 Approver can act while the record is Pending Auth L3.
- L2 Approver can act while the record is Pending Auth L2.
- L1 Approver can act while the record is Pending Auth L1.
Authority is exact, not automatically hierarchical. L3 authority alone does not grant L2 or L1 authority. Grant every level at which the role is expected to act.
What a checker needs
At the current stage, all of the following must be true:
- the entity supports maker-checker;
- the user has the exact L1, L2, or L3 permission for that entity;
- the record is within the user's data-access scope;
- the user is not blocked by maker-checker separation of duties;
- any applicable validation or conditional access policy allows the action.
The same current-stage authority governs approve and reject. Deny is available from a pending stage and can also be available from Rejected; from Rejected it uses L1 authority.
Example
A transaction submitted with 3 Approvals first waits at L3. A permitted L3 checker approves it, after which it waits at L2. The L2 checker must have the transaction's L2 authority; L3 authority does not substitute. After L2, an L1 checker performs the final authorization.
For a Branch-scoped checker, each decision also evaluates the transaction's header booking branch. The branches of individual lines do not create extra approval-scope requirements.