Automation With Human Approval: How to Design the Gate

The gate is not the brake: it is the design

The most common objection when someone hears "automation with human approval" is that it sounds like the worst of both worlds: the complexity of an automatic system plus the slowness of waiting on someone to approve. It is a reasonable objection and it is wrong, for a reason that becomes clear when you invert the question.

Without a gate, the decision doesn't disappear. It moves earlier. Somebody decided — at build time, with no data about the specific case and with no record of it — that every future execution would run. The gate doesn't add a decision: it moves the decision to the moment when there is information to make it, and it leaves a record of who made it.

What follows is how you design that gate: what gets approved, at what granularity, what gets written down, and how everything stops if it has to.

Which actions require a gate

The base rule of a governed system is that nothing that produces an effect executes without sign-off. The design question is not whether there is a gate, but how it is configured for each class of action. Four questions sort almost any workflow:

Is it reversible? Writing a row into an internal sheet undoes itself in seconds. Cancelling a tax invoice, moving money, or deleting a master record does not. Irreversibility is the strongest criterion and the least arguable.

Is it visible outside the company? An email to a customer, a message to a supplier, a post: the workflow cannot retrieve them. Even when the internal effect is nil, the action has already left your control.

Does it have a financial or tax consequence? Issuing, cancelling, paying, applying a discount. Here the gate is not operational prudence: it is the only way to have an answer later to "who authorized this?".

Does it touch personal data? Sharing, exporting or deleting information about people changes the nature of both the risk and the liability.

On the other side sit the read, compute and prepare actions: querying, comparing, classifying, drafting, assembling a case file. That work is where automation pays most and where per-action approval only adds friction, because the result doesn't touch anything yet. The practical rule: automate the preparation completely, govern the moment of effect.

Three ways to configure the gate

Once the class of action is settled, the gate gets configured one of three ways. These are not levels of "how much governance you accept": they are different ways of putting the human decision in the right place.

Per-action approval

Each case is presented on its own, with its context, and someone authorizes or rejects it. It is the right configuration when consequence is high and volume is low: the credit note, the payment to a new supplier, the deletion of a master record. Its cost is real — human attention per case — which is why applying it to everything is a design error: an inbox with two hundred daily approvals doesn't get reviewed, it gets bulk-approved unread, and at that point the gate has become paperwork.

Batch approval

The workflow prepares every case for the period and presents them together, with the rows that fall outside the pattern flagged at the top. A person reviews the summary, handles the exceptions and authorizes the set. It is the right configuration for high volume with medium consequence and stable rules: the day's collections reminders, the week's receipt intake.

The condition that makes it legitimate: the batch has to arrive sorted by risk, not in arrival order. A batch that forces you to read two hundred identical rows to find the three odd ones is per-action approval in disguise.

Notification with an objection window

The action is scheduled, the responsible person is notified, and it executes when an explicit window closes — thirty minutes, two hours — during which anyone can stop it. It is the right configuration for reversible, repetitive actions where the cost of waiting on active approval exceeds the risk: the report that goes out every Monday, the nightly sync between two systems.

Here is the nuance that separates real governance from theater: the window is only worth something if the objection is effective. If pressing "stop" finds the action already executed, that was not a window; it was an announcement. And that is exactly the kind of detail to test before delivery, not discover in production.

What the audit trail must record to be worth anything

Start with the field almost no audit trail includes, and the one that makes it useful: what would have happened. The intended state before execution — which records it was going to touch, with what values, across how many cases.

Without that field, an approved entry only says somebody said yes; it doesn't say to what. And a rejected or stopped entry says nothing at all, because there was no effect to record: the single most important event in your trail — the time the gate worked — would be blank. Recording the counterfactual turns every rejection into evidence that the control operates, which is precisely what an auditor wants to see and what an ungoverned workflow can never show.

With that field in place, the full list of what an entry has to carry is short:

• Who. The person who approved or rejected, identified individually. "The system" and "the operations team" are not answers.
• What. The concrete action, not its category: not "record update", but which field, of which record, from which value to which value.
• When. Date and time of the execution and of the approval. When both match to the second on every entry, someone is approving without reading, and the trail gives it away.
• On what data. The input that originated the run, identifiable afterwards: the email, the file, the document number.
• What would have happened. The counterfactual above.
• What the outcome was. Executed, rejected, stopped, failed — and, if it failed, the error verbatim.

Two properties close the design. The trail is immutable: a correction is a new row that supersedes the previous one, never an edit to the original — a record that can be rewritten proves nothing. And it is legible to someone who did not build the workflow: if you need the vendor to interpret it, it doesn't serve the purpose it exists for.

Rollback is a design requirement, not an emergency plan

A workflow should not run for the first time without a written procedure for undoing what it did. Not as a contingency plan: as part of the design, written before the first real execution.

The reason is that rollback is a test of comprehension. If you cannot describe how an action is undone, it is because you are not clear on exactly what it touches or in what order — and that is precisely the workflow that should not be executing anything unsupervised.

Some actions cannot be reversed by nature: a sent email is not retrieved, an applied payment is not unilaterally undone. There the rollback is operational rather than technical, and it also gets written: who is notified, with what message, within what time. An action with no possible rollback is, by definition, an action that requires per-action approval.

A stop button nobody tested is not a stop button

The stop button is the easiest promise to make and the easiest to break without noticing. The failing version looks like this: the button halts future scheduling but not the run in progress; or it marks the workflow as paused while the already-dispatched queue keeps executing; or it needs permissions only the person who built the system holds — exactly the person who may be unreachable on the day it is needed.

The only way to know it exists is to press it. With the workflow running on test data, the person who will operate it — not the vendor — presses it, and you verify the only things that matter: that it stopped, how long it took, what state the half-finished work was left in, and what the audit trail shows. That is an acceptance criterion, and it belongs in the scope document alongside the others.

Why this is not optional in Mexico

Two realities make evidence mandatory, and neither is hypothetical.

The SAT. If your automation touches invoicing, it touches CFDI 4.0 — a tax document with strict issuance and cancellation requirements. A workflow that issues or cancels invoices with no record of what it did, when, on what data and under whose authorization is a liability waiting for a review.

ISO 9001. The standard requires documented information and traceability for the processes that affect quality. When the auditor asks who approved an output and under what criterion, a loose script has no answer; a governed workflow has it in print, with a name and a timestamp.

In both cases the evidence produces itself if the audit trail was designed at the start, and gets reconstructed by hand — with the cost and the doubt that implies — if it was left for later.

The point that sums it up

Governed automation means four concrete things, and all four are verifiable: approval gates, an audit trail for every action, a stop button, and a documented rollback procedure. These are not sales features: they are the conditions that make an automatic system defensible to a client, an auditor or the tax authority.

A workflow that runs well but cannot be explained is not an asset. It is a risk with good productivity.

Start by knowing where you stand

Our free assessment takes 3 minutes and returns a maturity score with recommendations prioritized by impact — no card, no mandatory call.

Take the free assessment →

Every automation we build ships with the four conditions above, a fixed written scope, and training so that you operate it. The full offer is at simiriki.com/automatizacion.

---

Sources cited in this article:

• SAT (Mexico) — CFDI 4.0, issuance and cancellation requirements for digital tax invoices (Anexo 20)
• ISO 9001:2015 — documented information and process traceability
• Governance conditions, timelines and scope match the current offer at /automatizacion