Someone prepares a refund. A reviewer replies “approved” by email. The refund runs in another system. Later, an operator has to piece together what was requested, who reviewed it, and what actually happened.
Four-eyes control, also called maker-checker, requires independent review. The record should preserve that separation from the request through to the result.
The record splits before the action runs
A forwarded email can show who replied. It does not establish whether the reviewer had the right role, which request details they reviewed, or whether the final action matched the request.
If the amount changes, evidence is missing, or execution fails, the team needs more than the approval thread to explain the outcome.
Keep the request and the action on one case
For a refund, start with the original request and its supporting evidence. Give the reviewer the amount, the target transaction, and the reason for the action in the same place.
Latch keeps case notes, evidence, plugin actions, and execution history together. The payment system still processes the refund. The plugin returns the outcome to the case so the operator can see what happened.
Keep what was requested, who reviewed it, and what ran in one record.
See how the workflow works in Latch →
Make the review boundary explicit
Define who can prepare the action and who can approve it. The requester should not provide the independent review of their own request. Enforce that separation in the workflow.
If the amount or target changes after review, define when the changed request needs another review before execution.
Keep denied attempts visible too. A blocked action explains where a permission or approval check stopped the workflow.
Bring the result back to the case
An approval does not prove that the refund succeeded. The case should preserve:
- The requested action, target transaction, and supporting evidence.
- The reviewer, the decision, and its timestamp.
- Any blocked attempt and the reason it was denied.
- The downstream status, reference, and execution time.
- Any failure, timeout, or retry that needs follow-up.
A timeout needs investigation. Preserve the returned status so the next operator knows what still needs checking.
Start with one action you need to explain
Choose a refund path that regularly needs review. Put the evidence on the case, define the reviewer, connect the plugin action, and inspect the record after it runs.
Walk through a denial and a failed execution as well as a successful refund. Expand the pattern once all three leave a record another person can follow.