How to Design an Approval Workflow: More Steps Do Not Mean Tighter Control

The hardest part of an approval product is not drawing several nodes. It is clarifying who can decide, under what conditions, what happens when nobody responds, and whether a decision can be reversed. More nodes can create more waiting and confusion; clear rules create real control.

The hardest part of an approval product is not drawing several nodes. It is clarifying who can decide, under what conditions, what happens when nobody responds, and whether a decision can be reversed. More nodes can create more waiting and confusion; clear rules create real control.

01 Define Approval Policy Before Drawing the Flowchart

Before design begins, business stakeholders should answer at least these questions:

• What is being approved, and which fields affect the decision?
• Who initiates it, and who is ultimately accountable for the outcome?
• Do amount, region, risk, or project type change the approver?
• Is one approval enough, or must everyone approve?
• Are rejection, return for changes, and requests for more information different?
• What are the processing deadline, delegation, and escalation rules?
• Which decisions are irreversible, and which can be withdrawn?
• How long must actions and comments be retained?

Without these answers, even an attractive flowchart merely visualizes ambiguous rules.

02 Five Common Approval Models

Parallel approval must also state whether everyone or any one person must approve. These options have entirely different business meanings. Do not offer only a dropdown without explaining the outcome to administrators.

03 Adding, Transferring, and Delegating Approvers Are Different

Add Before

The current approver adds another person who must provide an opinion first. This suits situations requiring specialist judgment while the current approver retains final accountability.

Add After

The current approver submits an opinion before adding a subsequent approver. Clarify whether the current opinion takes effect immediately and what happens if the added approver rejects.

Transfer

The current task moves to another person and the original approver no longer handles it. The system must record the transfer reason and change in accountability.

Delegate or Assign a Proxy

An approver authorizes a proxy for a defined period, generally with effective and expiration times, scope, and restrictions on sensitive workflows.

If the product provides only a "Send to Someone Else" button, users cannot tell whether accountability remains, and the audit trail becomes ambiguous.

04 Define Rejection, Return, Withdrawal, Reversal, and Cancellation Separately

Different organizations may define these terms differently. The system must use business-approved definitions and explain consequences before the action.

05 What the Requester Needs to See

Requesters care less about the diagram itself than who has the task now, why it is waiting, and what they can do.

Recommended request details include:

• Current overall status and most recent change;
• Completed, current, and upcoming nodes;
• The approver or role, processing time, and opinion for each node;
• The current waiting reason and estimated deadline;
• Available actions to supplement, withdraw, remind, or cancel;
• Whether edits restart the complete workflow;
• Notifications and history.

Do not make "Pending Approval" the only information. Waiting for Legal to provide more details and waiting for automatic system processing are completely different states to a requester.

06 Approvers Need a Decision Summary, Not a Raw Form

The approval screen should prioritize information relevant to the decision: changes in amount, key terms, risks, remaining budget, prior requests, and attachments. Group long forms, but do not hide critical differences in collapsed areas.

For change requests, show "Before—After" directly instead of forcing approvers to locate an old version. High-risk actions may also require an opinion, secondary confirmation, or stronger identity verification.

Common approver support features include:

• Reviewing related records and past decisions;
• Requesting additional information without rejecting outright;
• Mentioning relevant colleagues for collaboration without changing formal accountability;
• Saving a draft opinion;
• Securely reviewing a summary on mobile;
• Limiting bulk actions to simple, controlled-risk tasks.

07 Prevent Reminders, Timeouts, and Escalations from Becoming Harassment

A reminder should tell the approver who requested it, what it concerns, how long it has waited, and the deadline. Frequency, channel, and quiet hours must be configurable so requesters cannot create unlimited notification floods.

After a timeout, the system can:

• Remind the original approver;
• Notify the approver's manager;
• Transfer to a proxy or shared queue;
• Automatically escalate to the next role;
• Terminate the request and notify the requester;
• Mark it overdue for manual handling only.

Use automatic approval with extreme caution. It treats no response as consent and should be used only when business rules explicitly allow it and risk is acceptable.

08 Prevent Administrators from Configuring Dead Ends

A visual workflow editor should detect at least:

• Missing approvers or approvers who cannot be resolved;
• Overlapping conditions or branches that can never be reached;
• Loops without exit conditions;
• The requester and final approver being the same person without restriction;
• One person repeated across multiple mandatory nodes;
• Delegation or employee departure leaving no handler;
• No defined destination after return;
• Rejection branches without clear outcomes;
• Which workflow version governs running instances after configuration changes.

Before publishing, offer a test run with sample data so administrators can see the actual nodes reached under different conditions instead of only static connectors.

09 Approval States and Actions

Exact actions depend on business rules, but confirming them in a table like this is more effective than discussing interface buttons alone.

10 Audit Logs Must Reconstruct a Decision

Record at least the workflow version, node, approver and proxy relationship, assignment time, open time, processing time, opinion, attachments, before-and-after states, matched rules, automatic system actions, and client information.

Logs are not technical event dumps. Compliance, support, and business leaders need to query by request, person, time, and outcome, and distinguish user actions from system actions.

11 Test at Least These Scenarios Before Launch

1. A standard single-level approval;

2. Rejection at an intermediate sequential node;

3. One participant never responding in parallel approval;

4. A condition exactly at a threshold boundary;

5. An approver who leaves, takes leave, or loses permission;

6. A requester who withdraws, edits, and resubmits;

7. Return to a specified node rather than restarting;

8. Adding approvers before and after;

9. Transfer and proxy expiration;

10. Repeated clicks, network interruption, and concurrent handling;

11. Legacy instances still running when configuration changes;

12. Notification failure after the approval task was created.

Frequently Asked Questions

Do More Approval Levels Make a Process Safer?

Not necessarily. Repeated approval disperses accountability and encourages rapid approval. Give every node a distinct decision responsibility, then control risk through conditions, sampling, and audits.

Should Approval Comments Be Mandatory?

Actions requiring explanation—such as rejection, return, and reversal—generally need comments. Whether ordinary approval does depends on business value. Forcing everyone to write a meaningless "Approved" only creates noise.

Should Bulk Approval Be Supported?

It suits low-risk tasks with simple rules and consistent information. High-value, sensitive-permission, contract, or exception items should not be approved from a list alone; show key differences and risk warnings at minimum.

What Happens to Active Requests After a Workflow Redesign?

Define a version policy in advance. Commonly, existing instances continue on the old workflow while new requests use the new one. If migration is required, define node mapping, opinion retention, notifications, and rollback; never switch silently.

12 Bring Research and Design into Product Decisions