How Should You Design a Multi Step Approval Flow?

How should you design an approval flow?

Model the states first, then design the screens. Most approval flows fail because the team built a submit button and a notification, then discovered halfway through that nobody defined what happens when an approver asks for changes. Get the state model right and the interface becomes obvious.

Approval is one of those features that looks small in a ticket and turns out to touch permissions, notifications, audit history and every edge case in the product.

It is also one where accessibility standards give you unusually concrete requirements, which is a gift when you are arguing about scope.

Why do approval flows go wrong?

Because they get built from the submitter's point of view. Someone designs the flow of sending a thing for approval, ships it, and then the approvers arrive with questions the design cannot answer. Who else has seen this. What changed since I last looked. Can I approve part of it.

The second failure is treating approval as a single yes or no. Real approval has a middle state, where the approver wants changes without rejecting outright, and that state is where most of the actual work happens.

The third is silence. An item sits in a queue, nobody is notified, and the submitter has no way to tell whether it is being reviewed or forgotten. That ambiguity is what drives people back to email.

What does the accessibility standard require here?

More than you might expect, because approval flows usually qualify as consequential actions. WCAG 2.2 success criterion 3.3.4, Error Prevention for Legal, Financial and Data, applies at Level AA to pages that "cause legal commitments or financial transactions for the user to occur" or "that modify or delete user-controllable data in data storage systems."

The criterion then gives you three ways to satisfy it, and you need at least one. The first is Reversible, where "Submissions are reversible." The second is Checked, where "Data entered by the user is checked for input errors and the user is provided an opportunity to correct them." The third is Confirmed, where "A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission."

That is a design brief handed to you by a standard. An approval that changes data and offers none of those three is both bad UX and an accessibility failure, which makes it much easier to get prioritised.

What are the five states an approval can be in?

Draft, submitted, changes requested, approved and withdrawn. Five is the smallest set that covers how approvals actually behave, and skipping any one of them is where flows break later. Most products ship with three of the five and then bolt the missing two on badly a year afterwards.

State	Who acts next	What the submitter sees	Reversible
Draft	Submitter	Editable, not visible to approvers	Not applicable
Submitted	Approver	Locked, with who it went to and when	Yes, via withdraw
Changes requested	Submitter	Editable again, with the comments attached	Yes
Approved	Nobody, or a next approver	Locked, with who approved and when	Depends on consequence
Withdrawn	Submitter	Back to draft, history preserved	Yes

The state nobody designs is withdrawn. A submitter who spots their own mistake after sending needs a way to pull it back without asking the approver to reject it. Leaving that out means people submit a correction as a second item and the approver gets two.

Who should see what at each state?

Approvers should see only what is waiting on them, and submitters should see exactly where their own item sits. That sounds obvious, and almost no product does it, because both audiences get handed the same list with a status column and are left to filter it themselves.

Build the approver view as a queue, not a table of everything. The question an approver opens the product to answer is what needs me today. Anything else on that screen is noise competing with the decision.

Give the submitter a timeline instead. Submitted on this date, to these people, currently with this person, last activity here. That single view removes most of the chase messages that otherwise land in your support inbox. We covered the underlying permission model in our notes on roles and permissions UX.

How do you handle a rejection?

Avoid the word rejection entirely and design the middle state properly instead. Almost nothing in a real workflow needs outright rejection. What approvers actually want is to send the thing back with specific comments attached, which is changes requested, and that should be the most prominent action on the screen.

Require a reason. An approver who can bounce something back with no explanation creates a loop where the submitter guesses, resubmits and gets bounced again. Making the comment mandatory feels paternalistic and saves everyone a round.

Attach comments to the thing they are about rather than the whole item. A comment on the specific field or section survives the next edit and tells the submitter exactly where to look. A general note at the top does not.

Keep the edit history visible after a change request. An approver returning to a second submission needs to see what moved, and asking them to reread the whole thing is how approvals get rubber stamped.

What happens when an approver is unavailable?

Plan for it, because it is the most common real world failure and almost never in the first version. Someone is on leave, has left the company, or simply never opens the product. The item sits there and the process quietly stops working.

Three mechanisms cover it. A delegate an approver can nominate, a group approval where any one of several people can act, and an escalation after a defined period. Which you need depends on how much the delay costs.

Be careful with automatic approval on timeout. It is tempting and it destroys the point of the flow, because the approval record now says approved when nobody approved anything. Escalate to a person instead, and if the process genuinely does not need a human, you did not need an approval step.

Should approvals be reversible?

It depends entirely on what the approval triggers, and WCAG gives you the framing. If approving sends money, publishes to the public or deletes data, then 3.3.4 wants reversibility, a check, or a confirm step. Pick deliberately rather than defaulting to a confirmation dialog.

Our preference is a short reversal window over a confirmation modal. A confirm dialog interrupts everyone to prevent a rare mistake, and people click through it without reading. A few minutes to undo catches the same mistakes without taxing every correct action.

Where reversal is genuinely impossible, say so at the point of action rather than in a dialog title. Telling someone this cannot be undone, next to what specifically cannot be undone, is more effective than a generic are you sure. Our notes on undoing destructive actions go through the patterns.

How do you keep the approver from having to re-enter things?

By carrying context forward, which is also a Level A requirement. WCAG 2.2 success criterion 3.3.7, Redundant Entry, says information previously entered "that is required to be entered again in the same process" must be either "auto-populated, or available for the user to select," except where re-entry is essential or needed for security.

In an approval flow that means the approver should never retype anything the submitter already provided, and a submitter responding to a change request should never rebuild a form from scratch. Both are common and both are failures against a Level A criterion.

Timeouts are the related trap. WCAG lists Timing Adjustable at Level A and Timeouts at Level AAA for good reason, because a session that expires mid review loses a decision and an explanation someone just spent ten minutes writing.

What does a good approval flow feel like?

Like almost nothing at all. The approver opens a queue, sees what needs them, reads enough to decide, and acts. The submitter always knows where their item is without having to ask anyone. Nobody sends a message saying any update on this, because the answer is already on the screen.

The test we use is whether the flow removes email rather than adding to it. If people still chase each other in Slack or by email after you ship, the flow is not carrying the information they need, and adding notifications will not fix that.

Keep the record honest as well. Who approved what, when, and on which version is the thing people will ask for a year later, usually during an audit. Our notes on designing an audit log cover how to present it.

If you are designing an approval flow and want a second opinion on the state model before it becomes screens, we are happy to work through it with you. You can find us at phoenix.studio.