Many teams say they have four-eyes control (also called maker-checker, or two-person review) when what they actually have is a forwarded email.
Someone assembles the case. Someone else replies "approved." A third step happens in another system. Later, the organisation tells itself the workflow was controlled because more than one person touched it.
That is not a durable control model. It is a coordination habit.
The problem is not email. The problem is that the workflow now depends on:
- fragmented context
- unclear role boundaries
- missing denied paths
- weak execution proof
- manual reconstruction later
Four-eyes control only works when the review boundary and the action boundary stay visible in the same operating record.
Inbox Approvals Fail Because the Record Splits
1. Context Drifts Before the Reviewer Acts
The reviewer sees a summary, not the issue. Attachments get lost. The amount changes. The real reason sits in an earlier thread.
2. Authority Gets Blurred by the Inbox
The email shows who replied. It does not show whether that person held the correct role. It does not show whether another role was blocked. It does not show whether the control path changed midstream.
3. Denied Attempts Disappear from View
The inbox chain rarely shows a block in the application. The reviewer sees the final path, not the operating truth.
4. Execution Proof Lives in Another System
The approval sits in email. The action happens in another system. The case record gets a summary later, if anyone remembers.
That makes the workflow harder to trust under pressure.
Case First, Action Second Keeps the Record Whole
The stronger pattern makes the case the centre of the workflow. That means:
- assemble the full context on one work item
- attach the evidence there
- expose the sensitive action in that same context
- restrict execution to the right roles and permissions
- keep denied attempts and final results on the record
Four-eyes discipline becomes operational instead of ceremonial.
The reviewer no longer has to guess what the request meant. The operator no longer has to prove the right path was followed. The case carries the evidence as the work happens.
A Visible Workflow Boundary Ends Verbal Coordination
A case-first control model does not need to show a theatrical approval queue to be useful.
What it needs is a clear execution boundary:
- Who can see the action?
- Who can execute it?
- Which policy check mattered?
- Was the action denied or unavailable?
- What happened when it ran?
Four-eyes control stops depending on verbal coordination once that boundary is visible.
That is the practical shift. Teams move from "tell someone to check it" to "the workflow preserves how the case moved and who could act."
Denials Belong in the Control Story
Inbox approval patterns flatten history.
A sensitive workflow might include:
- one blocked attempt by the wrong role
- a note clarifying missing evidence
- a second attempt after the case is corrected
- the final successful execution
In an inbox chain, most of that disappears or becomes hard to correlate.
In a stronger workflow, the sequence stays visible. Blocked actions prove the control worked. They show the system was not merely permissive.
Execution Must Return to the Case Record
A four-eyes workflow is incomplete if the final action disappears into another system.
The case should preserve the downstream result:
- success or failure, with timing
- any retry or timeout
- the action target
- the resulting case change
Otherwise the team faces a split narrative:
- The review evidence is in one place.
- The operational outcome is in another.
That split is where auditability usually breaks down.
Where Latch Fits, the Case Keeps the Control Record
Latch keeps the workflow closer to the case.
It gives teams:
- one case record for notes, evidence, and issue context
- plugins for case-aware downstream actions
- approved roles plus permission policy around execution
- denied-attempt visibility when someone cannot run the action
- execution history when the action does run
- audit logs that keep the action trail on the case
That does not mean Latch claims to be a one-size-fits-all approval engine. It means the platform gives teams a more dependable control surface than inbox forwarding and after-the-fact summaries.
For finance exception paths, that matters a lot. The organisation can keep request context, role boundary, denial history, and final outcome closer together.
A Practical Rollout Pattern Starts with One Case
Do not start with the broadest workflow. Start with one action that already causes investigation pain later.
Good first candidates:
- a high-risk reversal
- a write-off or adjustment path
- a reprocessing action
- a sensitive escalation to another system
Then tighten the workflow in order:
- make the case the source of truth
- attach the evidence there
- expose the action in context
- limit execution to approved roles and permission policy
- preserve denials, retries, and results
That gives the team a cleaner operating record before it tries to govern everything else.
The Operating Standard Is a Reconstructable Record
Four-eyes control is not about counting people. It is about preserving an independent boundary and a reconstructable record around a sensitive action.
Email-only boundaries make the workflow weaker than the policy text suggests.
The control becomes easier to trust when the case preserves the context, the execution boundary, the denied attempts, and the final result.
That is the standard worth building towards.