How to redesign approval workflows before automation

Purpose

Replace the signature chain with an inventory of decisions

Observe completed cases and ask what each person actually decides. Authorization commits resources or permits an action. Verification checks a fact or calculation. Consultation supplies expertise without owning the final choice. Notification creates awareness. These are different controls and need different interfaces and evidence. Record the policy or risk objective behind every current touchpoint, the consequence of omission and whether later reviewers perform a genuinely independent check. A role that cannot change the outcome is not an approver simply because it receives an email.

Trace why the step exists. If it was introduced after an incident, determine whether a stronger upstream rule or validation now controls the same risk. If several levels check the same threshold, test whether hierarchy adds authority or only waiting. Preserve mandatory separation and specialist judgment, but challenge ceremonial repetition. Create a decision register with authority source, case scope, evidence, possible outcomes and accountable owner. Open ambiguities go to the relevant policy, legal, risk or control owner rather than being resolved by software configuration.

Control design

Route by consequence and preserve real separation of duties

Define tiers using attributes that change risk: value or materiality, reversibility, external commitment, data sensitivity, policy exception, novelty, related-party conflict, cumulative exposure and missing evidence. Thresholds should come from approved policy and observed cases, not from a desired automation rate. A deterministic standard case may pass under a rule with sampling. A material or unusual case may require a named authority. A prohibited combination should stop. Document what moves a case between tiers and test boundaries with historical examples.

Separate initiation, authorization, execution, recording and review where one person controlling them would create unacceptable error or misuse risk. Separation does not always require a long serial chain. Two independent decisions can sometimes occur in parallel, and a later quality sample can be more effective than a repetitive manager click. Configure roles dynamically so the same person cannot request and approve the same case through aliases or delegated groups. Define the final decision owner when specialist views disagree. Automation should enforce the control model, not infer it from an org chart.

• Base tiers on consequence, reversibility, novelty and conflicts.
• Use approved thresholds and test cases near their boundaries.
• Separate incompatible duties at the transaction level.
• Prefer independent judgment over repeated hierarchical confirmation.
• Name the authority that resolves disagreement and accepts residual risk.

Decision experience

Create an evidence-complete task with meaningful actions

An approval task should arrive only when required evidence is present or clearly marked missing. Show the original request, calculations, relevant policy, source provenance, prior verification, conflicts, related exposure and the action that approval will trigger. Freeze the version under review and define whether a later change invalidates the approval. Avoid a persuasive generated summary as the only view. Approvers need to inspect the basis and understand what the system inferred, validated or could not determine.

Offer actions that match authority: approve, reject, request information, return for correction, abstain for conflict, delegate within policy and escalate. Capture a reason proportionate to the risk and make irreversible decisions visually distinct. Set service levels by consequence rather than one global target. Reminders should not become pressure to approve. A timeout should follow an explicit safe state, such as escalation or stop, never silent acceptance unless policy intentionally permits it. Design mobile or batch interfaces only when they preserve adequate evidence and independent attention.

Assurance

Test decision quality, resilience and override governance

Pilot the redesigned route on a bounded set with a control group or shadow comparison. Measure more than elapsed time. Inspect harmful approvals and rejections, requests for information, evidence use, downstream corrections and reviewer agreement. Sample standard cases that the rules pass automatically. Examine whether some teams or case types are disproportionately escalated. Interview approvers about missing context and pressure. If cycle time falls because people stop examining evidence, the redesign has weakened rather than improved the control.

Test absence, delegation expiry, evidence-source outage, duplicate submission, changed data after approval and conflicting specialist advice. Overrides need a named authority, reason, duration, scope and later review. Emergency routes should expire and restore normal controls. Keep an immutable link between the decision, evidence version, rule version and actors. Review thresholds after policy or loss changes, but do not tune them only to reach a target automation rate. The approval system is successful when it produces valid, timely and explainable decisions with proportionate human effort.

• Compare control outcomes as well as cycle time.
• Sample automatically accepted cases independently.
• Test absence, outage, changed evidence and conflicting advice.
• Time-limit and review every exceptional override.
• Retain the evidence and rule version behind each decision.