Why Human Approval Belongs in Important Automated Workflows

There is a quiet assumption in most automation projects that the finished state is nobody touching anything. It is worth challenging, because in the workflows that matter most, the version with a person in it is usually better — faster to build, cheaper to run, and far easier to trust.

The skill is not deciding whether to include a human. It is deciding where.

What an approval step actually buys you

A place to catch the expensive error. Automations fail in ways their authors did not imagine: a vendor changes a field name, a customer record has an unusual character in it, a date is parsed as American when it was European. A person glancing at the output catches the class of error that no test anticipated, because a person notices when something looks odd rather than when a rule is violated.

Accountability that survives a complaint. When a customer asks why something happened, "our system did it automatically" is a bad answer that gets worse the more expensive the mistake was. "Our operations manager reviewed and approved it" is a normal business answer. This matters for anything touching money, contracts, employment or safety.

Permission to ship earlier. An automation that requires approval can go live long before one that does not, because the failure modes are contained. You learn what actually goes wrong from real traffic instead of from a risk workshop. Many teams then discover the approval step is cheap enough to keep permanently.

A source of improvement data. Every time a person overrides the automated result, that is information. If you capture what they changed and why, you have a ready-made list of the rules your system is missing.

Where the approval step should sit

Put it where the error is still cheap and the reviewer still has context.

• Before anything irreversible. Sending an external email, issuing a refund, deleting records, publishing something public, submitting a filing.
• Before anything a customer sees with your name on it.
• Before money moves.
• At the point where a person can actually judge. Approving "the extracted invoice total is $4,212.80" next to an image of the invoice is a real check. Approving "run the nightly batch?" is not a check; it is a ritual.

Equally important is where the approval should not sit. An approval on every step of a ten-step workflow is not ten times safer. It is a workflow nobody uses, because the reviewer becomes a bottleneck and starts approving without reading. One well-placed checkpoint beats five ceremonial ones.

Designing an approval people will actually perform

Most approval steps decay into rubber-stamping. The causes are consistent and fixable.

Show the evidence, not the conclusion. The screen should contain everything needed to make the judgement, side by side. If the reviewer has to open another system to check, they will stop checking.

Make rejecting as easy as approving. If approve is one click and reject requires writing a justification into a ticket, you have built a machine that produces approvals.

Batch sensibly. Twelve similar items presented together with the differences highlighted is a good review. One item every four minutes all day is an interruption pattern that guarantees inattention.

Set a default that fails safe. If nobody responds within the timeout, the system should hold, not proceed. The exception is genuinely low-risk work where delay is the greater harm — and that should be a deliberate, documented decision.

Log the decision with the person's name and the time. This is what makes the accountability real, and it takes almost no effort to add at build time. Adding it later, after an incident, is much harder.

Never let the automation approve itself. It sounds obvious. It happens more than you would expect, usually through a service account that was given broad permissions for convenience. The system that proposes an action and the identity that authorises it should not be the same thing.

A tiering approach

Rather than one policy for everything, sort actions into three tiers and be explicit about which is which.

Tier 1 — runs unattended. Reversible, internal, low cost if wrong. Moving a file, updating an internal status, sending an internal notification, adding a tag. Log everything; approve nothing.

Tier 2 — proposed, then approved. External communications, record creation in systems of record, anything with a customer's name on it, anything with a number in it that came from an extraction step. The system does the work; a person presses go.

Tier 3 — a person does it, assisted. Contract terms, pricing exceptions, credit decisions, anything with legal or safety consequence. Automation here should gather and present, never decide.

Most businesses find that around two thirds of the work in a process is Tier 1, which is exactly where the time savings live. The instinct to automate the Tier 3 decision is the instinct to spend the most effort on the smallest, riskiest slice.

The migration path

A good sequence for any new automation:

1. Shadow mode. It runs and records what it would have done. Nobody acts on it. Compare against what people actually did for two to four weeks.
2. Approval mode. It proposes, a person approves. Track the override rate.
3. Selective release. For the categories where the override rate is near zero and the cost of error is low, drop the approval. Keep it everywhere else.

Step three is optional. Plenty of well-run automations sit in approval mode forever and are perfectly good businesses systems. The absence of a human is not a measure of maturity.

The businesses that get burned by automation are rarely the cautious ones. They are the ones that removed the last human from a process because removing humans sounded like the point. It never was. The point is that people should only be doing the parts that need a person — and approving a consequential action is one of those parts.