Maker-checker review before sensitive actions run
A maker submits a sensitive action request from the ticket. A checker reviews its saved inputs and supporting evidence. Latch blocks the requester from approving, rejecting, or executing that same request.
The checker may run the approved action afterward if they remain eligible. The ticket keeps the request, decision, and execution record together.
Define independence at the action request
A ticket can pass through several operators before anyone proposes a sensitive action. The person who created it is not necessarily the person asking to run that action. Latch records the action requester and uses that identity for the maker-checker rule.
The reviewer needs the configured role and action permission, along with access to the ticket. Two people can hold the same eligible role and still be independent for this request. See the wider ticketing workflow with approvals for the full operating path.
Four-eyes is a review principle
The four-eyes principle calls for independent review of consequential work. Maker-checker gives that review an operational form: one person submits, another checks. Segregation of duties goes further, separating incompatible powers across the organisation.
A gate on one action is one part of that broader control design. Read the four-eyes and segregation-of-duties definitions when specifying the rule your team needs.
A second person checks what will be submitted
Maya submits a transaction reprocess request from a fictional service desk ticket. Daniel reviews the saved transaction reference and retry reason beside the supporting evidence. He can approve or reject, and may include a rejection reason. The example demonstrates the interface with synthetic data, rather than a live financial operation.
Maya cannot clear her own review
The requester cannot approve, reject, or execute the same request. She can cancel it while it is pending. If its inputs need correction, a new request creates a fresh review point with its own submitted values.
Daniel can approve and later execute
Approval leaves the request ready to run. Daniel can execute if he is still eligible; another eligible operator other than Maya can also execute. Latch checks authority and action availability again at that step.
The saved form inputs are used for execution with current ticket context. A configured lifetime limits the request's validity, and ticket-change invalidation can require review again when the case changes. The approval lifecycle covers those settings and the feature guide shows the pending, review, and approved-ready screens.
Put the gate around your connected action
Administrators set maker-checker as a plugin default or an override for a named action. An amount threshold, transaction check, or vendor-validation rule belongs in the connected action logic. The current gate supplies a second eligible person's review, rather than a general approval routing canvas.
For a customer-built vendor-record action, the plugin supplies the ERP update and required inputs. For a transaction reprocess, it supplies that operation's checks. Explore plugin actions and finance workflow examples when mapping the connection.
Preserve the decision and inspect the result
The ticket retains the request and reviewer decision, while the execution record captures the result reported by the plugin. An uncertain outcome needs investigation in the connected system before another operation is authorized.
Independent review still depends on the checker's judgment and the quality of the evidence. The audit history helps a later reviewer follow the work; it does not guarantee that the decision was correct.
Operate the workflow within your requirements
A customer-deployed installation puts the application and its records on infrastructure your team operates. Its identity configuration, backups, integrations, and model connections are part of the operating design. Source-code access is available on Enterprise under the agreed commercial licence.
Use self-hosted ticketing to evaluate what you can run and adapt, and the security and deployment guide to inspect the dependencies and responsibilities.
Choose the deployment and control detail you need
Start with self-hosted ticketing or the complete approval workflow. The feature pages explain how independent review, action records and deployment controls fit together.
Evaluate your infrastructure, operating responsibilities and customization path.
Keep the incoming ticket, independent review and external result together.
See configured action gates, request states and separate execution checks.
Review decision and execution records alongside the controls needed for independent retention.
Inspect identity, storage, integration traffic and operational responsibilities.
Bring email, forms and API requests into one ticket queue.
Apply ticket records, checklist reviews and configured approval actions to claims work.
Questions about independent action review
Specify the requester, reviewer, and execution boundary before choosing a control.
Who is the maker?
The person who submits the plugin action request. That person may be different from the ticket creator. Latch applies independence to the saved action request, rather than assuming that everyone who prepared the ticket must be excluded from review.
Can the requester approve their own action?
No. The requester cannot approve, reject, or execute that same maker-checker request. The server checks this identity boundary. Another eligible operator must review it.
Must the checker have a different role?
The checker must be a different eligible person. They need ticket access, an approved plugin role, and the required action permission. The current control does not require the requester and checker to have different named roles.
Can the checker execute after approving?
Yes, if they remain eligible. Approval and execution are separate steps, but the same checker may perform both. A third person is not required. Latch checks the request state, expiry, roles, permissions, and action availability again before execution.
What happens after rejection?
The decision stays in the request history, with an optional rejection reason saved on the request. Corrected submitted values require a new request. The requester can also cancel their own pending request before review is completed.
Does maker-checker provide a multi-stage approval chain?
The current gate provides one independent review of an action request. A sequential chain, parallel review groups, or a quorum is a separate workflow requirement. Define the exact reviewer pattern before selecting the control.
How does this relate to segregation of duties?
Maker-checker applies independent review to an action. Segregation of duties is the wider discipline of separating incompatible powers across roles and processes. A two-person action gate is one control within that design, rather than proof of complete segregation across the organisation.
Inspect one maker-checker request from start to finish
See the saved fields, the independent reviewer decision, and the separate execution step using synthetic product examples.