Most approval workflows are designed backwards. Someone gets burned by an automated action, an approval step is added to that flow, and the step is never removed. Repeat this for two years and you arrive at an operation where a manager opens a queue of ninety items every morning and clears it in four minutes.
That queue is not a control. It is a receipt for a decision nobody made. Deciding where a human genuinely belongs is a design problem with an answerable rubric, and it is worth doing deliberately.
The four axes that decide whether a human belongs
An action warrants human approval when it scores high on any one of four axes. This is the rubric, and it is deliberately short enough to apply in a meeting.
Reversibility. How much does it cost to undo? An internal field change costs a click. An outbound email costs an apology. A wire transfer costs a lawyer. Irreversibility is the strongest single argument for a human, because a reviewer’s value is entirely in the window before the action commits.
Magnitude. What is the size of the effect if it is wrong? A $40 refund and a $40,000 credit note are the same operation with different blast radii. Magnitude thresholds are the most practical way to turn one rule into graduated control.
External visibility. Does anyone outside the company see it? Internal mistakes are corrected. External mistakes are remembered, forwarded, and occasionally screenshotted. Anything reaching a customer, a supplier, a marketplace listing or a public status page has a different risk profile from anything staying inside your own tables.
Regulatory exposure. Does a rule, a contract or an auditor require a second pair of eyes? This axis is not negotiable and not subject to efficiency arguments. If a regulation names the control, the control exists regardless of how annoying it is.
The rubric applied to real actions
| Action | Reversibility | Magnitude | External | Regulated | Verdict |
|---|---|---|---|---|---|
| Set ticket priority to high | Trivial | Low | No | No | Automate |
| Assign a ticket to an agent | Trivial | Low | No | No | Automate |
| Apply a $20 goodwill credit | Easy | Low | Yes | No | Automate with a cap |
| Issue a $5,000 refund | Hard | High | Yes | Sometimes | Approve |
| Send a bulk email to 10,000 contacts | Impossible | High | Yes | Sometimes | Approve |
| Change a customer’s contract terms | Hard | High | Yes | Often | Approve, dual |
| Post a supplier bill for payment | Hard | Varies | Yes | Often | Approve, segregated |
| Close an accounting period | Reversible by an admin | High | No | Yes | Approve, restricted role |
| Delete a contact record | Hard | Low | No | Sometimes | Approve or soft-delete |
Notice the pattern in the bottom half. Nothing there is approved because it is complicated. Complexity is not on the list. A complex action that is cheap to undo should be automated; a simple action that cannot be undone should not.
Approving everything is the same as approving nothing
A reviewer has a fixed budget of real attention. Somewhere between ten and thirty considered decisions a day is honest for most people doing approvals alongside another job. Route eighty items into that budget and the reviewer does not become eighty items better. They change strategy: they scan for anything that looks unusual, and they approve the rest in a batch.
At that point the control has inverted. The queue produces an audit trail that says a named person accepted each item at a recorded time, and that record is now false in substance while being true in form. You have added latency to every action and assurance to none, and you have created a document an auditor may rely on which the reviewer cannot actually defend.
This is why removing approvals is a safety activity, not a convenience one. Every low-risk item you take out of the queue raises the attention available for the items that remain. A queue of six items a day gets read. A queue of ninety gets cleared.
The corollary is that approval rate is a health metric. If a step has run for six months and never been rejected once, it is not protecting you. Either the threshold is set too low and should be raised, or the step should be deleted and replaced with an alert after the fact.
Designing the step itself
An approval step has four decisions beyond “does this need one”.
Who approves. Name a role, not a person, or the process stops when that person is on leave. Check authority server-side at the moment the decision is submitted, not when the button is rendered, because hiding a button is not an access control.
Can the requester approve themselves. Self-approval is fine for a three-person company and unacceptable for a finance control. Make it an explicit setting with a recorded default rather than an accident of implementation.
What happens on timeout. An approval with no deadline produces work that neither completes nor fails and never appears on any report. Choose escalation, auto-reject or auto-approve, and let reversibility choose for you: auto-approve only where undoing is cheap.
What the approver sees. A reviewer approving “Refund #4417” with no context cannot make a decision. The request needs the amount, the customer, the reason, who raised it, and what will happen on approval. Approval quality is mostly an information design problem, and most fatigue blamed on volume is actually caused by requests that force the reviewer to go and look things up.
The failure: a threshold that was never raised
A wholesale business sets a rule that any discount above 5% needs the sales manager’s approval. Reasonable at the time, when deals were small and rare.
Two years later, volume has tripled and 5% has become the ordinary opening discount in the category. Roughly seventy requests a day land in one queue. The manager approves in batches from a phone, usually in the evening.
Two things break. Deals sit for a day, and one quarter a competitor wins a renewal explicitly on responsiveness. Then a rep tests the boundary, submits a 34% discount on a large account among the daily batch, and it is approved at 21:40 with the rest. Nobody catches it until the margin review a month later, and the contract is signed.
The threshold was never wrong when it was written. It became wrong because the business changed and the rule did not, and the batch-approval behaviour that made the miss possible was the predictable result of a queue that outgrew its reviewer. The fix was not a stricter rule. It was two tiers: automatic below 15%, approval between 15% and 25%, and dual approval above, which reduced the queue to about six items a day and made each one worth reading.
Approvals in Oneop
Oneop implements approvals as a step that pauses a run until a person decides. The rank is checked when the decision is made rather than when the button is drawn, so approving is refused server-side rather than merely hidden from the wrong user, and a waiting approval survives a restart because the paused run is a database row rather than a process timer. Details are on the automation page, and the durability mechanism underneath is explained in durable automation.
In finance, approval is the posting event for a supplier bill, and segregation of duties is a separate control that stays inactive until it is switched on for the deployment and then for the individual workspace, before it stops a submitter approving their own expense or bill. It covers approval specifically and was never applied retroactively. That is a narrower claim than “approvals are segregated”, and the narrower claim is the true one.
None of Oneop’s automation features, approvals included, sit behind a paid plan.
Where this rubric stops
Everything above is the business-process view: a human approving an action a rule proposed. Actions proposed by an AI agent add a further question, because the reviewer is now assessing a suggestion whose reasoning they cannot fully inspect, and because a model’s confidence is not evidence. That case has its own design constraints and its own failure modes, covered separately in human-in-the-loop AI approval workflows and in the suggest-approve-autonomous ladder described in AI autonomy levels. How models are constrained and logged across the product sits on the AI governance page, and the deployment pattern for agents that act on real records is set out under deploying AI agents safely.
The rubric still applies to those actions. It is just no longer sufficient on its own.