Approval chains worth asking about

Every system has an approvals screen, and every vendor can draw the diagram: raised, checked, approved, released. Boxes and arrows are cheap.

What separates a working control from a picture of one is the set of cases the diagram does not draw — the approver on leave, the amount that changes after the chain started, the person who is both raiser and signatory. Spend the meeting on those. They belong high on the list when choosing construction software.

What the chain has to be able to depend on#

Start with the conditions. Ask whether a chain can vary by the amount, by the project, by the category of spend, and by who raised it.

Most systems do one. Your actual rule is all four at once: a purchase above a figure, on a particular site, in a category with an annual rate contract, raised by somebody who joined last month. If the software supports one dimension, the other three are enforced by somebody remembering, which means they are not enforced.

Then the follow-up that catches people. What happens when the value changes after the chain has started? An order raised below a threshold and then edited above it should re-enter the higher chain. A surprising number of systems keep it where it was, and the amount that needed the extra signature is precisely the amount that got fewer.

Who may change the chain#

The chain is itself a control, and a control any administrator can quietly rewrite is not one.

• Who can edit it. Not "an admin". Which named role, and how many people hold it today.
• Is the change itself approved? A control that changes without a second person agreeing is a control with a back door.
• Is the change recorded? Old chain, new chain, who, when. Without it nobody can explain why a March document took a different route from an April one.
• What happens to items already in flight? Do they follow the chain they entered or the chain as it now stands. Both are defensible. Silence is not.

The questions about people#

What happens when an approver is on leave? Three honest answers exist: it waits, somebody else may act, or it escalates on a clock. Ask which. Then ask whether a delegation carries an end date, whether the person raising the request can see it is in force, and whether the record names who actually approved rather than who the chain nominally names.

A delegation with no end date becomes permanent, and that is how one person quietly acquires the authority of three. A permission with a clock on it is the safe shape, and who is allowed to decide argues most organisations cannot state their own answer here.

Can somebody approve their own request? Test it rather than asking. Raise something as a person who also holds an approval and see whether the button is there. Then the harder versions: raise it in somebody else's name and approve it, or raise it, have it rejected, edit it, and approve the edited version yourself.

On money, is there a second signature, and can it be the same person twice? A two-step chain where one person holds both steps is one signature drawn twice. That erosion happens by convenience, not by intent — the subject of two signatures on money.

What the approver sees at the moment of deciding#

This gets the weakest answers, and it decides whether the chain does any work at all.

At the instant the approve button is pressed, what is on the screen? A title and an amount is a rubber stamp with extra steps. What ought to be there:

• The document itself, readable without opening a second system.
• What changed since the previous person approved it.
• The history, including any earlier rejection and its reason.
• The position on the head — what is already committed against this budget, this project, this vendor.
• Anything outstanding on the other side — an open dispute, an overdue balance, a quality issue not closed.
• What this step is for, in one sentence, so a new approver knows what to check.

Then ask the same about the phone. Most approvals happen on a phone, between other things, and if the phone screen carries less than the desktop one, the approval that actually occurs is the shallow version.

After the fact#

Can an approval be withdrawn? Between the approval and the order leaving the building there is usually a window. Ask whether it exists, who may use it, and whether using it leaves a line in the record.

What happens to a record approved and then edited? This is the important one. If a rate can change after approval and the approval stays attached, the approval means nothing. Three answers are defensible: the edit is refused, the approval is voided and the chain runs again, or the edit is allowed and marked so the next person sees it. Ask which, then change a rate on an approved order and watch the screen.

How approval chains fail in practice#

They rarely fail by being wrong. They fail by being ignored.

• Too many steps. Each approver assumes the others read it, so everybody signs. A few steps genuinely read catch more than many that are not.
• A step whose owner does not know what they are checking. Ask an approver what they look for. If the answer is "that it is correct", that step is a delay wearing the costume of a control.
• The out-of-office stall. Nothing is refused. It sits, and moves when somebody rings. The commonest failure and the hardest to see, because a stalled item produces no event — why tasks stall between people.
• Escalation that needs an accusation. If moving a stuck item upward means naming a colleague, nobody moves it, and management hears of the problem only once it is unfixable; escalation without shame designs that requirement out.
• The override that becomes the route. Used once for a real emergency, then for something merely urgent, then for anything raised late on a Friday. Given a year, the bypass is the process and the chain is decoration.

Two of these cost us real work#

Delegation is bounded and never lowers the floor. A stand-in is named for a window with an end date, is revocable, and cannot turn two signatures into one.

Moving a reviewer re-addresses the review. When a task's lead changes mid-review, the new reviewer is knocked with the brief the submission carried, and the previous one is told nothing is owed. Quietly swapping queue rows leaves two people each assuming the other has it.

What good looks like#

The fewest steps that each mean something. Every step added dilutes the attention of the ones already there.

Every step named for what it checks, not for the rank of whoever signs. "Confirms the rate matches the contract" tells a new approver what to do; "director approval" tells them only that they are senior enough.

Every bypass recorded rather than silent. An override that writes a line, names the person, asks a reason and appears on somebody's screen next morning stays rare. A silent one becomes the default.

The short version#

Ask whether a chain can depend on amount, project, category and raiser at once, and what happens when a value changes mid-flight. Ask who may edit the chain, and what happens on leave, on self-approval and on an edit made after approval.

Then ask what the approver actually sees at the moment of deciding, and on a phone. Fewest steps that each mean something, every step named for what it checks, every bypass written down.