Approval Process Flowchart: 7 Steps and Routing Rules

Build an approval process flowchart by defining intake, completeness, routing, review, decision, fulfillment and the recorded outcome. Keep “return for revision,” “reject and close” and “waiting too long” on separate paths; a rejected request does not always go back to the requester.

The seven-step example below uses a fictional purchase process. Its amounts and time targets illustrate how to draw rules, not a policy to copy into every organization.

What an Approval Flowchart Shows

A good approval flowchart answers three questions that plain text usually leaves vague:

1. Who reviews the request, and in what order?
2. What happens when the request is incomplete or gets rejected?
3. Where does an approved request actually end up?

The second question is the one most people forget. A linear "submit → approve → done" diagram isn't an approval flow — it's a wish. Show revision loops and final rejection separately, with an explicit outcome for each.

Step by Step

Here is the flow our approval flowchart template maps, which you can use as a model for your own:

1. Start — submit request. The process begins when someone submits a request: a purchase, a content draft, a budget, a contract.

2. Completeness check (decision). "Info complete?" If No, the request goes to a Revise request step and loops back — nobody should review an incomplete request. If Yes, it moves forward.

3. Manager review. The first approval stage. The reviewer evaluates the complete request.

4. Approval decision (decision). "Approved?" This is the core branch:

• Yes → Process and file → Approved (end state)
• Revise → return for correction; Reject → record the reason and close this version

5. Apply threshold rules. Decide whether value, risk, contract type, or data sensitivity requires another reviewer. Put the rule inside the diamond: "At least $5,000?" is more useful than "Extra approval needed?"

6. Set a time limit and escalation. A request waiting for review is a real state. Add an SLA check and route overdue work to a reminder, delegate, or escalation owner.

7. Close and record the result. End with an explicit outcome such as Approved and ordered, Rejected and closed, or Withdrawn. Store the request version, approver, timestamp, decision reason, and evidence at the same point.

That loop-back on rejection is what makes this a flowchart and not a checklist. Open the flowchart maker with this template to see how the rejection arrow routes back to the revision step.

Worked Example: A Purchase Request

Suppose an employee needs a $7,500 analytics subscription. A useful approval flow does more than send a form to a manager:

1. The requester submits the business purpose, supplier, annual cost, budget code, contract, and data-access requirements.
2. An intake check confirms that every required field and attachment is present. Missing information returns to the requester before a reviewer spends time on it.
3. The manager confirms the business need and budget owner. A rejection here returns with a reason and creates a new request version.
4. A value decision checks whether the amount exceeds the organization's $5,000 threshold. Because this request does, it moves to finance.
5. A data-sensitivity decision checks whether the supplier will process customer or employee data. If yes, security and legal reviews can run in parallel; if no, the flow skips them.
6. Finance approves the spend, procurement creates the order, and the system records the decision trail.
7. The requester receives one of three explicit outcomes: approved and ordered, rejected and closed, or returned for revision.

This exposes two kinds of branches. A business-rule branch changes who reviews the request; a quality branch returns incomplete work for correction. Keeping them visually distinct makes the diagram easier to maintain when thresholds or policies change. Compare layouts in the approval flowchart examples.

Open the approval starter below and first rename the request and reviewer for your team. Keep “return for missing information” separate from final rejection, then add your own amount threshold and review branches. These are editable drawing objects; the template does not route or approve requests.

Make this Approval Flowchart your own

Start with an editable example. Replace the text, move the shapes, and adapt it to your task.

Edit this Approval Flowchart

No sign-up needed to start editing.

Define Routing Rules Before Drawing

Write a small decision table before placing shapes. It prevents vague diamonds and reveals where reviews can happen in parallel.

Each row should become either a labeled branch or a validation rule outside the visual flow. Do not put every policy sentence inside the diagram. Keep the chart readable, then link to detailed policy definitions.

Assign Ownership with Swimlanes

Use a standard flowchart when one team owns nearly every step. Switch to swimlanes when the important question is where responsibility changes. A purchase flow might use lanes for Requester, Manager, Finance, Security/Legal, and Procurement.

Place an action in the lane of the person who performs it, not the person who receives a notification. Cross-lane arrows then represent handoffs. If finance and security can review at the same time, split into parallel paths and join only after every required decision is complete.

Keep systems separate from people when automation matters. A Workflow system lane can own validation, reminders, timestamps, and notifications, while human lanes own judgment. This makes automation opportunities visible without pretending every approval can be automated. Compare other layouts in Types of Flowcharts.

Add SLA, Delegation, and Escalation Paths

The most damaging approval state is often not rejection but silence. Model waiting explicitly:

• Start the review timer when a complete request reaches an approver.
• Send a reminder before the deadline, not only after it.
• Allow a named delegate for absence, but preserve who made the decision.
• Escalate overdue work to a role or queue, not an individual who may also be unavailable.
• State whether returning for revision pauses or restarts the SLA clock.

Avoid automatic approval merely because a reviewer missed a deadline unless policy explicitly permits it. For spending, security, legal, or compliance decisions, escalation is usually safer than implied consent.

Validate the Flow with Real Requests

Walk three records through the finished diagram: one clean approval, one incomplete request, and one high-risk rejection. Check that every decision has labeled exits, every return arrow says what must change, parallel reviews have a join rule, and every path reaches a named outcome.

Also verify that every waiting state has an owner and SLA, and that the final step records enough information to reconstruct the decision. Ask someone who did not design the process to trace a request. If they need a verbal explanation to choose a branch, rewrite the rule on the chart.

Save the reviewed diagram beside its policy owner and revision date so the process does not drift away from the version people actually follow.

Common Mistakes

No rejection path. If your diagram only shows the happy path, it's documenting what you hope happens, not the process. Every approval decision needs a "No" branch.

Unlabeled decision exits. Every diamond exit needs a label — "Yes / No", "Approved / Rejected". An unlabeled branch forces the reader to guess.

Skipping the completeness check. Sending incomplete requests into review wastes reviewers' time. A quick "Info complete?" gate up front catches this.

Too many approval layers. If a request passes through five sequential approvers, the diagram (and the process) becomes a bottleneck. The flowchart often makes over-engineered approval chains obvious — which is a good reason to draw it.

When to Use a Simpler Flow Instead

If one owner checks one condition and makes one decision, a short checklist or status field may be clearer than a multi-lane chart. Use a flowchart when there are branches, returns, thresholds, parallel reviews, or uncertain ownership. The goal is to make consequential routing visible, not to diagram every administrative action.

Frequently Asked Questions

Does rejection always return to revision?

No. A request for correction returns to revision; final rejection records a reason and closes that request version. Label both routes rather than using one No arrow for all outcomes.

What should a timeout do?

Use the agreed reminder, delegation or escalation route. A timeout does not mean approval unless an explicit applicable policy defines that behavior.

What if the request changes?

Record a new version, recalculate the route and determine which prior approvals must be repeated. Preserve the audit record rather than editing the approved request invisibly.

Related Reading

• Types of Flowcharts — process, swimlane, and more
• Approval flowchart examples — real layouts to copy
• Flowchart Symbols Guide — every shape explained
• How to Make a Flowchart — the general tutorial

Three request tests expose ambiguous rules

Agree on a rule table before routing a real purchase. The following is a fictional policy for the example, using one currency consistently.

Now run the third case twice: first with a missing attachment, then with all evidence present. Missing information returns to revision. A final rejection closes that request version with a reason. An overdue review goes to a named delegate or escalation queue; it does not count as automatic approval unless an explicit policy says so.

Label the parallel-review join if both security and legal must approve. One completed branch must not let the request skip the other. If the requester cancels, show a cancellation end state and stop fulfillment.

For implementation handoff, retain request ID, version, rule version, decision and decision time. When the same completion event arrives twice, the fulfillment step should recognize the recorded request/version and avoid creating a second purchase. The diagram describes that responsibility; drawing an arrow does not implement duplicate protection. Ask the process owner to walk these cases before treating the diagram as an approved procedure.

For formal BPMN notation, consult the OMG specification. This ordinary flowchart example does not claim BPMN conformance.