Maker-checker
How supported records are captured, submitted, checked, corrected, and authorized.
Maker-checker separates the user who prepares a change from the user who authorizes it. remoteEaze uses this lifecycle only for entities explicitly configured for maker-checker, normally records that carry a Record Status.
Not every entity is a maker-checker entity. Lookup or system-managed data may take effect immediately and is marked No approval required in the role permission editor.
Use Approval model by entity to see which names in the Roles & Permissions screen currently use maker-checker and which take effect without that lifecycle.
Record statuses
| Status | Meaning and available path |
|---|---|
| Captured | Editable draft that has not been submitted. |
| Pending Auth L3 | Waiting for an L3 decision; used when three approvals are required. |
| Pending Auth L2 | Waiting for an L2 decision. |
| Pending Auth L1 | Waiting for the final L1 decision. |
| Authorized | Final approved state. The initial record is no longer edited as a draft. |
| Rejected | Returned for correction. It can be edited and resubmitted. |
| Denied | Final refusal. It cannot be corrected or resubmitted. |
The approval sequence counts down: L3 → L2 → L1 → Authorized. A record that requires two approvals starts at L2; a record that requires one starts at L1. A zero-level action is authorized directly when submitted.
Actions
Submit
Submission is available from Captured or Rejected when the user has the operational permission that created or changes the record. The permission result determines how many approvals are required. A matching conditional access policy can change that number for the transaction family.
Approve
Approval moves the record to the next level, or to Authorized after L1. The checker needs the exact authority for the current pending status and must also pass data scope and applicable policy checks.
Reject
Rejection returns a pending record to Rejected for correction and resubmission. The current-stage approver permission is required. A rejection reason is requested where the workflow requires one.
Deny
Denial moves a pending or rejected record to the terminal Denied state. It is used when the proposal must not continue through correction. A denial reason is requested where the workflow requires one.
Separation of duties
By default, the creator or last modifier cannot approve, reject, or deny their own work. An approval updates the workflow record, so the user who completed a previous approval step cannot immediately perform the next checker step on that same record.
The original maker uses the action's Create permission to correct their own Captured or Rejected draft. A different user requires Update to modify that draft.
Authorized records and amendments
Authorized is terminal for the initial draft lifecycle. Where remoteEaze supports later controlled changes, the authorized record stays live and a separate amendment passes through maker-checker. See Amendments.