Approval Workflow

Because some decisions commit money or accept risk on behalf of an organisation, and the organisation needs to say in advance who is allowed to make them.

Approval workflow is where governance stops being a policy document and becomes something the software enforces. Its value is almost entirely in the exceptions — the 2% of transactions someone should look at twice — which is why designing it around the 98% produces a control that costs everybody time and catches nothing.

• An approver must be able to reject, not only approve. A step with no possible outcome but yes is a notification wearing a control's clothes.
• The approver must be a different person from the requester. Self-approval defeats the entire mechanism.
• Every decision is recorded with who, when and — for rejections — why. An approval you cannot attribute is not evidence of anything.
• A document in flight is not yet binding. It commits nothing until the last required approval lands.

It fails organisationally rather than technically. The workflow is configured correctly, and then the first urgent order is delayed by an absent approver, and someone finds the override. After that the override IS the process, the audit trail records approvals nobody read, and the failure is invisible until somebody tests it — usually an auditor, usually after something has already gone wrong.

• Emergency purchases where the goods are needed before anyone can approve, which needs a defined retrospective path rather than an undefined one.
• An approver who is also the requester on their own department's spend.
• Documents amended after approval — whether that voids the approval is a policy decision the system must encode, not infer.
• Approval thresholds in a foreign currency, where the limit is breached or not depending on the day's rate.