Decide Where People Approve

This chapter has to resist its own topic.

An approval step feels like safety. It is a named person, standing between the system and the consequence, saying yes. In practice the approver clears the queue by pattern within two weeks and by reflex within a month, and what you have built is a delay with a person standing next to it, plus a plausible story about oversight that will be repeated in a meeting.

The test

There is a test for a real approval step, and it is a single question: does the approver have information the system does not?

If yes, the approval is doing work. A person who knows the account is mid-acquisition, or that this contact is a former colleague of the CEO, or that the last conversation went badly, is contributing something no rule could contain.

If no, and the approver is checking the same fields the system already checked, you have not added a control. You have added a delay, and the delay decays into a rubber stamp on a predictable schedule.

Forbidden states do the work approvals cannot

The more useful mechanism is a list of states in which an action is forbidden regardless of how right it looks.

A merge system carries one of these: it refuses to disqualify a surviving record that has an open deal, an active service relationship, recent engagement, or existing customer status. Read what that list is doing. None of those conditions makes the match wrong. The records really are duplicates. What they make is the consequence unacceptable, and no amount of confidence changes that.

A forbidden state is better than an approval in three ways. It is checkable, so it runs every time rather than when someone is paying attention. It is arguable, because it is written down and somebody can dispute the list. And it does not decay, because nothing about it depends on a human staying vigilant.

Use approvals where a person genuinely knows something. Use forbidden states everywhere else.