Skip to content

Human approvals in automated workflows

Good automation does not have to decide every case itself. It has to recognise which case it cannot decide — and present it in such a way that the decision is made quickly.

  • AudienceManagement, business departments
  • LevelPlanning
  • Reading timeabout 6 minutes
  • Last updated16 October 2026

What you will learn

  • Where a decision must remain with a person
  • What a good briefing contains
  • Why approval steps fail in practice
  • Why every approval needs a deadline

Where the decision stays with a person

  • When the impact is large and the case is rare — an automatic decision is not worthwhile there, and its errors weigh heavily.
  • When discretion is involved: goodwill, priority, exceptions.
  • When people are directly affected.
  • When the data is incomplete or contradictory — then the exception is the normal case.

Conversely: an approval step in which ninety-nine out of a hundred cases are approved is not a decision but a tick box. It costs time and creates the impression of control without exercising any.

What a good briefing contains

The quality of an approval step depends on whether the person can decide without first having to look something up. Four pieces of information belong in it:

  • What it is about, in one sentence — not the record number.
  • Why the case is being presented: which rule did not apply, which value is missing, which limit has been exceeded?
  • What happens if it is approved, and what happens if it is rejected.
  • The information needed for the decision — included directly, not as a link to another system.

The second point is the one that is missing most often. “Please review” is not a briefing; “The discount is above 20 percent and therefore needs approval” is.

An example from practice

Why approvals fail

Three patterns that repeat:

  • The approval depends on one person, and that person is on leave. Without a defined substitute, the process stands still.
  • The approval arrives by email, and emails get buried. Without a list showing what is outstanding, nobody sees the backlog.
  • There is no deadline. A transaction that has been waiting for three weeks goes unnoticed because it belongs to nobody.

All three can be solved at the design stage: define a substitute, keep a visible list of open approvals, and agree a deadline with escalation — after n days the transaction goes to the next person in line or back to the sender.

Approvals must be traceable

For every decision, record who, when, with what result and on what basis. This is not mistrust, but the prerequisite for answering a question later — and, when in doubt, the basis for improving the rules.

An evaluation of which cases were presented how often and how they were decided shows, after a few weeks, which approvals are genuine decisions and which can be replaced by a rule.

Common misconceptions

A well-built one moves waiting time to a visible place. Things become slow without a substitute, without a list and without a deadline.

Approvals that always say yes train people to click them away. Fewer, but genuine decisions work better.

An approval step added later affects the entire process — statuses, notifications, reports. Planned from the start, it is just one more status.

About the author

Fabian Lücker is managing partner of PHP-Schmiede KG in Rheine and has worked in software development since 2007. He is responsible for development and design, and writes here about decisions that arise in real projects.