Approval Workflow: How to Design, Automate & Manage Business Approvals

An employee needs new equipment for a growing team. She emails her manager, who approves and forwards the message to Finance. Finance asks whether a director also needs to sign off, because the total looks high. Meanwhile the employee finds a cheaper supplier and changes the amount. Someone replies to the original thread. A week later, nobody can say whether the manager’s approval still applies, whether the director ever saw the request, or whether the order was placed.

That business does not simply have a slow approval process. It has an approval-policy problem—and faster email will not fix it.

Most approval failures begin before any software is involved. Nobody has decided who is authorized to approve what, which conditions require another reviewer, whether an edited request needs fresh approval, or what should happen when an approver is away. Automating those gaps only automates confusion.

A reliable approval workflow needs five things defined before a tool is chosen:

• Clear authority — who may approve which requests
• Routing rules — which conditions send a request to which reviewers
• Defined exceptions — rejections, revisions, changes, absences and silence
• Decision history — a record of who decided what, on which version
• Downstream actions — what happens once a request is approved

This guide follows one purchase request from submission to completion to explain approval types, authority, exceptions, automation choices and what happens after approval.

Why Approval Workflows Break Down

Approval problems tend to look like speed problems, but the underlying causes are often structural:

• Approval by scattered email. Decisions live in inboxes, forwarded threads and chat messages. Nobody can see the current status in one place.
• Unclear authority. People approve because they were asked, not because they are authorized for that type or size of request.
• Missing information. Requests arrive without a supplier, budget line or justification, so reviewers send them back or approve without enough context.
• Changes after approval. The amount or supplier changes, and nobody knows whether the original approval still covers it.
• No escalation rule. A request waits indefinitely because an approver is busy or away.
• No audit history. Months later, nobody can show who approved what, or on which version.
• Approval disconnected from action. The request is approved, but no purchase order is created until someone notices.

Software can help with each of these, but none is solved by software alone. Someone must first decide who holds authority, what counts as a material change and what happens when nobody responds. Those are policy decisions.

Anatomy of an Approval Workflow

Most approval workflows pass through seven stages. Here is the purchase request at each one.

1. 1. Request. The employee submits the purchase: items, supplier, amount, budget code and business reason. A structured form beats a free-text email because every request carries the same information.
2. 2. Validation. Before anyone reviews it, the request is checked for completeness and basic rules. Is the budget code valid? Is the supplier named? Is the amount within any hard limit? Catching gaps here saves reviewers from sending requests back.
3. 3. Routing. Rules decide who reviews the request based on its amount, category, department or supplier status. Routing should follow authority, not just the org chart.
4. 4. Review. The manager confirms the business need, and Finance checks the budget. Each reviewer sees the information relevant to their decision.
5. 5. Decision. Each reviewer approves, rejects or requests revision, ideally with a comment explaining why.
6. 6. Next action. Final approval triggers the next step: a purchase order, an update to the accounting system and a notification to the requester.
7. 7. Record. The decision history is kept: who acted, when, on which version of the request, and with what outcome.

Email-based approvals can make validation and reliable decision history easier to miss—the stages that help make the rest of the workflow trustworthy.

Sequential, Parallel & Conditional Approval Workflows

Most multi-step approval workflows combine three routing patterns.

Sequential Approval

In a sequential approval workflow, reviewers act one after another: Manager → Finance → Director. Each step starts only when the previous one is complete. Microsoft’s Power Automate guidance on sequential approvals describes this pattern: a pre-approval that must happen before a final approver signs off.

Sequential order makes sense when one decision depends on another. Finance shouldn’t spend time checking budget for a purchase the manager doesn’t believe is needed. The downside is delay. Every added step adds waiting time, and steps that don’t depend on each other shouldn’t be forced into a queue.

Parallel Approval

In a parallel approval workflow, independent reviews happen at the same time. Suppose the purchase involves a new software supplier. Finance, Legal and Operations can each review their own concern at once, rather than waiting for one another. Microsoft’s walkthrough on creating parallel approval workflows describes each approver’s decision as independent of the others.

Parallel does not automatically mean everyone must agree. The organization must define the completion rule:

• • Must every reviewer approve?
• • Does any single rejection stop the request?
• • Can one designated reviewer approve on behalf of a group?
• • What happens if two reviewers approve and one requests revision?

Approval tools support different completion options, but choosing among them is a policy decision.

Conditional Approval

A conditional approval workflow changes the route based on the request itself. Routing conditions might include:

• • amount
• • risk level
• • department
• • request type
• • whether the supplier is new
• • specific policy conditions

For illustration only, suppose a company’s policy says this:

• • Purchases under its internal threshold need manager approval only.
• • Purchases above it also need Finance.
• • Purchases from new suppliers need Procurement review at any amount.

These thresholds belong to that example company, not to any recommended standard. Salesforce’s documentation on Flow Approval Processes reflects the same idea: decision elements determine which path an approval follows based on conditions.

Conditional logic keeps routine requests fast and sends scrutiny where risk actually sits. It also creates a question the business must answer: what happens when an edit moves a request across a threshold? We return to that below.

Who Is Actually Allowed to Approve?

Routing tells a request where to go. Authority decides whether the person it reaches can make the decision.

A common failure is routing by job title alone. A department head may be the right approver for purchases in their own area, but not for a contract that commits the company to a multi-year obligation, and not for granting access to sensitive systems.

Authority can depend on several factors:

• • request type
• • department or cost center
• • amount
• • risk
• • location
• • contract type
• • sensitivity of the data or system involved

Four roles are worth separating:

• Requester: submits the request and supplies information. Where separation of duties is required, the workflow should prevent requesters from approving their own requests.
• Reviewer: provides an opinion or check, such as Legal reviewing terms. They may not hold final authority.
• Approver: is authorized to approve a step within defined limits.
• Final authority: makes the decision that allows the business to commit.

Writing these roles down can expose gaps, such as requests nobody is formally authorized to approve. An approval matrix makes the rules explicit.

An illustrative framework, not a recommended universal policy. Each organization defines its own categories, thresholds and authorities. The Final authority column is especially important, because leaving it undefined creates ambiguity when a request reaches the edge of someone’s authority.

What Happens When Approval Does Not Go as Planned?

The main approval path is the easier part to design. The exceptions separate a dependable approval workflow from a fragile one.

Rejected vs Revision Requested vs Cancelled

These statuses should never mean the same thing:

• Rejected: the decision is no. The request does not proceed as submitted.
• Revision requested: the request may be acceptable once corrected. It goes back to the requester and can be resubmitted.
• Cancelled: the requester or the business no longer wants to continue.

Merging them causes problems. If Finance marks a purchase “rejected” when it only needs a different budget code, the requester may abandon a legitimate purchase.

Rejection after partial approval needs a rule too. If the manager approved but Finance rejects, the request normally stops. The manager’s earlier approval stays in the history, but it does not override Finance’s authority.

What If the Request Changes After Approval?

Suppose the manager approves the purchase, and then the employee changes it. Examples of changes:

• • the amount rises or falls
• • a different supplier is selected
• • items are added and the scope grows
• • for access requests, a higher access level is requested
• • contract terms change

Some changes are trivial. Others are material and may invalidate the earlier approval. The business must define what counts as material. An increase that crosses a threshold is an obvious case, because the request now needs an approver it never reached.

Software can help enforce this. Salesforce’s documentation on record locking in Flow Approval Processes describes locking a record so it can’t be changed while under review, while administrators—and, if configured, assigned approvers—can still edit it. So the edit policy must be deliberate, and the workflow should handle approvals already given without erasing them.

A related question is what happens when the policy changes while requests are in progress. For example, a threshold is lowered mid-quarter. The organization should decide whether in-flight requests finish under the old rules or are re-evaluated, and record which policy version applied.

What If an Approver Is Unavailable?

When the manager is on leave, three responses are possible, and they are not the same:

• Temporary delegation: another authorized person acts on the manager’s behalf for a defined period.
• Substitute authority: the policy names a standing alternate for certain request types.
• Escalation: the request moves up or across because nobody acted within the expected time.

Delegation should never let someone approve beyond the authority they are acting under. Every decision should record that it was made by a delegate.

Delegation vs Escalation

What If Nobody Responds?

The usual sequence is:

1. 1. Reminders.
2. 2. Escalation, after a defined period.
3. 3. Expiration, where the request closes if nothing happens.
4. 4. Manual intervention by a workflow owner.

The timing belongs to each organization; there is no universal standard. One rule is worth stating firmly: silence should never quietly count as approval unless that is an explicitly authorized policy for a specific low-risk request type.

What About Duplicate or Resubmitted Requests?

The workflow should preserve a stable request identity across revisions. That can mean one request ID with explicit versions, or linked revision IDs tied to the same underlying request. Either way, reviewers and downstream systems must be able to tell which request this is, which version was approved, and whether a newer revision exists. This helps in two ways:

• • Reviewers can see that a resubmitted request was previously sent back, and why.
• • The system can detect likely duplicates before two identical purchases are approved.

Downstream actions should also check which approved version they are acting on, alongside duplicate-prevention logic, so a single approval never creates two purchase orders.

Manual vs Automated Approval Workflows

A manual approval process might run like this: request by email, forwarding, follow-up, tracking in a spreadsheet, and finally an unclear status. It works at low volume and breaks down as requests multiply and approvers change.

An automated approval workflow runs differently: structured request, validation, rules, approver, reminders and escalation, decision, downstream action, audit history.

Approval automation can reliably improve these things:

• Routing: rules send each request to the right people.
• Required fields: incomplete requests can’t be submitted.
• Status visibility: requesters and managers see where every request stands.
• Reminders and escalation:follow-up doesn’t depend on someone remembering.
• Audit history: decisions are recorded automatically, with timestamps and versions.
• Downstream updates: approved requests trigger the next step in other systems.

What automation does not do is remove judgment. The Finance reviewer still decides whether the purchase is justified; automation removes the chasing around that decision.

What Should Be Automated—and What Should Stay Human?

The dividing line becomes clearer once the process is defined.

Good candidates for automation:

• • intake through structured forms
• • validation of required information
• • routing based on defined rules
• • threshold checks
• • reminders and status tracking
• • notifications
• • updates to downstream systems
• • audit recording

Judgment that should stay with an authorized person:

• Commercial judgment: is this purchase worth making?
• Risk acceptance: is the business comfortable with the supplier or terms?
• Policy exceptions: should an out-of-policy request be allowed?
• Sensitive access: should this person get elevated system access?
• Material financial decisions: commitments above a defined level of significance.

Some organizations auto-approve narrowly defined, low-risk requests, such as routine purchases from a pre-approved catalog below a small limit. That can be sensible if it is an explicit, documented policy with an owner, rather than a side effect of configuration.

The principle is that automation should support accountability, not hide it. Every automated step should be explainable: which rule applied, which version of the policy, and which person is accountable. For more on deciding where automation fits, see NogaTech’s guide to what business processes to automate first.

Approval Workflow Software vs Automation Platform vs Custom System

Once the process is defined, the system choice becomes easier. There are four broad options.

Existing / Native Workflow

Many business systems already include approval features: accounting, procurement, CRM, HR and document platforms. Use native approvals when the system that holds the record already supports your rules. Configuring what you own can be the lowest-risk option, because the approval stays next to the data.

Approval Workflow Software

Dedicated approval workflow software provides forms, routing, delegation, reminders and audit history as a packaged product. It fits when a standard approval model matches your process and your users, and when you mainly need a consistent place to submit and decide requests. Check that it supports your real exceptions: material changes, parallel completion rules, delegation limits. The easy path is not enough.

Automation Platform

Workflow automation platforms connect existing systems and move work between them. Microsoft describes approvals in Power Automate as combining human decisions with automated flows, for cases such as expense reports and document sign-off. These platforms are useful when your systems already exist and the main need is routing requests and triggering actions across them. NogaTech’s workflow automation guide explains how these flows are structured.

Custom Workflow / Internal System

A custom workflow or internal system is worth considering when:

• • rules are genuinely specific to the business
• • permissions are complex
• • approval is one part of a larger process
• • users need records, queues and admin capabilities
• • several systems must participate
• • customers or partners need their own experience

It is not universally better: it carries build and maintenance responsibility, so choose it only when simpler options can’t handle the real process. NogaTech’s guide to internal tools covers when a custom internal system makes sense.

What Happens After Final Approval?

“Approved” is a status, not an outcome. For the purchase request, final approval might trigger any of these:

• • create a purchase order
• • update the accounting or ERP system
• • create a project or task
• • provision access, for access requests
• • update the CRM
• • notify the requester
• • generate a document
• • update a customer or internal portal

Here the approval workflow meets system integration—and its most important failure case: the approval succeeds, but the downstream update fails because a system is unavailable or rejects the data.

The approval decision should stay intact, and the follow-up action should be tracked separately with its own status. Otherwise the business ends up with an approved request and no purchase order, and nobody notices.

Post-Approval Integration Flow

Retries should carry a stable request or operation identifier and use duplicate-prevention (idempotency) logic, so the same approved action is not created twice. NogaTech’s system integration guide and API integration explained for businesses cover how these connections are designed.

Security, Permissions & Audit History

An approval is only meaningful if the right person made it and the record can be trusted:

• Only authorized users can approve. Approval rights should match the authority matrix, not simply anyone who receives a link.
• Server-side enforcement. In software, authorization must be checked on the server for every decision, not just hidden in the interface. The OWASP Authorization Cheat Sheet recommends least privilege and denying access by default.
• Sensitive visibility. Salary, health, legal or security details may need to be visible only to reviewers who need them.
• Decision history. Record who acted, what they decided, their comment, and a timestamp.
• Version identification. Tie each decision to a specific version of the request.
• Delegated authority. Record when someone acted as a delegate, and for whom.
• Changes after approval. Log edits, and whether they triggered re-approval.

Regulatory requirements vary by industry and jurisdiction. Confirm them with qualified advisors rather than assuming a tool satisfies them.

Common Approval Workflow Mistakes

1. 1. Automating an unclear policy. The software faithfully reproduces the confusion, only faster.
2. 2. Too many approval levels. Add approvers for authority or risk, not habit.
3. 3. Every request follows the same path. Routine purchases wait behind high-risk reviews.
4. 4. No distinction between rejection and revision. Requesters restart or abandon requests that only needed a correction.
5. 5. No rule for edited requests. Approvals silently cover amounts or suppliers nobody reviewed.
6. 6. Escalation treated as approval. Moving a stalled request should put it in front of someone, not approve it by default.
7. 7. Delegation without authority controls. Delegates approve beyond the limits of the person they cover for.
8. 8. No audit history. When a decision is questioned, nobody can prove what happened.
9. 9. Approval disconnected from downstream work. Approved requests wait for someone to manually create the next record.
10. 10. Choosing software before defining the process. The tool's defaults become the policy by accident.

How to Plan an Approval Workflow

Work through these steps in order.

1. 1. Define the request: what exactly is being approved.
2. 2. Define required information: the fields a reviewer needs to decide.
3. 3. Define authority: who may approve which categories and amounts.
4. 4. Define routing conditions: when requests go sequentially, in parallel or conditionally.
5. 5. Define decision outcomes: approve, reject, request revision, cancel.
6. 6. Define exceptions: changes after approval, duplicates, policy changes.
7. 7. Define delegation and escalation: who can act, when, and within which limits.
8. 8. Define downstream actions: what approval triggers, and how failures are handled.
9. 9. Decide what to automate, and what stays with human judgment.
10. 10. Choose the system that fits the defined process.

For other workflows suited to this approach, see NogaTech’s business process automation examples.

15 Questions Before Automating an Approval Process

1. 1. What is being approved? One clearly defined request type at a time.
2. 2. Who can submit requests? Everyone, or specific roles?
3. 3. What information is required? Only what reviewers actually use.
4. 4. Who reviews it? Name roles, not individuals.
5. 5. Who holds final authority? For each category and condition.
6. 6. Which conditions change the route? Amount, risk, supplier, department.
7. 7. Can any reviews run in parallel? And what is the completion rule?
8. 8. What counts as a material change? And what happens to earlier approvals?
9. 9. How do rejection and revision differ? And can rejected requests be resubmitted?
10. 10. Who can act as a delegate? For how long, and within which limits?
11. 11. When does escalation happen? And to whom?
12. 12. Do requests expire? If so, when, and what happens next?
13. 13. What happens after final approval? Which systems update?
14. 14. What must the audit history show? Actors, versions, times, delegation.
15. 15. Who owns the workflow? Someone must maintain rules as the business changes.

When Professional Workflow Automation Help Makes Sense

Existing and native tools are often enough when the workflow is straightforward, the rules are stable and the system that holds the record already supports the approvals you need.

Outside help becomes more useful when:

• • approvals span several systems
• • rules are conditional
• • different roles hold different authority
• • the process depends on integrations
• • existing tools require constant manual workarounds
• • the approval is part of a larger portal or internal-system workflow

NogaTech approaches approval projects by starting with the workflow, authority, systems, users, exception paths and downstream actions, before choosing technology. That work may lead to configuring an existing tool, connecting systems through automation and system integration, or building a workflow within business portals and internal systems. The right answer depends on the process.

Frequently Asked Questions