An approval workflow is the path a request takes to a decision. How it works, its main types, examples by team, and where approvals stall.
What is an approval workflow?
An approval workflow is the defined path a request follows to get a decision: who approves it, in which order, under which conditions, and what happens on a no, on silence or on a change. Every team runs them, for purchase requests, expense reports, contract reviews, access requests, role changes and non-standard deals.
The rule behind an approval usually exists, written in a policy or a delegation of authority. The friction is in running it across teams, tools and inboxes, and that is where requests wait.
How an approval workflow works: building blocks and types
Every approval workflow is built from the same four blocks. The trigger is a request that needs a yes, sent with what the approver needs to decide: the amount, the reason, the documents. The routing rule says who approves, by amount, type, entity or risk. The sequence sets the order. The last block, outcome handling, decides what happens on a yes, on a no, when nobody answers, or when something changes after the approval, and it is where most requests stall.
The sequence gives the main types of approval workflows. A sequential workflow waits for one approver before the next, because one decision depends on the other. A parallel workflow sends independent approvals at the same time, so Legal and Finance can answer on the same day. A multi-level workflow adds approvers as the stakes rise: a manager up to a threshold, a director above it. A conditional workflow opens a branch for the exception and lets the standard request go straight through. Most real workflows mix two or three of these.
Approval workflow examples, team by team
Every department runs approval workflows, and only the request, the approvers and the stakes change from one to the next. The table below lists six common ones, from purchase requests to HR role changes, with the results a team can expect once the workflow is orchestrated end to end.
Contract review is often the slowest of the six, because it waits on Legal while Sales waits on the customer. A VP Sales at a European software company describes it from the sales side:
“Anything to do with legal documentation, depending on the complexity of the deal, can be quite lengthy. The legal department is the slowest piece.”
VP Sales, European software company
Non-standard deals follow the same logic. A discount above the rep’s limit goes to the Head of Sales up to a threshold, and to the CRO above it. That approval belongs to the deal desk, which runs it with its own rules.
Where approval workflows break
Approval workflows rarely break on the rule. They break on the path the request takes between teams.
The request often arrives without its context, so the approver first asks for the contract, the quote or the budget line. Sometimes the approver has changed role, and the request waits in front of an empty seat. A deadline passes with no answer, and the requester starts chasing in a thread. Later, a customer redline reopens a clause Legal had already approved, and nobody notices that the approval no longer holds. When Finance or an auditor finally asks who said yes, the answer sits somewhere in a chat history.
A former Head of Sales we spoke with points to the most common miss: companies underestimate “the time it will take for legal and procurement”. The process exists in most companies. What slows it down is everything it has to cross: teams, tools, inboxes, calendars. And when the official path is slower than a message, people send the message, so the trail is empty exactly where the risk is.
Approval workflow vs approval process, sign-off and business rule
These terms are often used interchangeably, and they should not be. The approval process is the policy: who must approve what, written in a procedure or a delegation of authority. A business rule is one condition inside it, such as a discount above 20% that needs the CRO. A sign-off is a single approval. The approval workflow is the path that runs the policy every time, chaining the sign-offs, applying the rules and handling what happens between them.
Workflow automation is a close neighbour, and it does its own job well: it moves tasks and data between tools. An approval workflow adds a decision that a person takes at a defined point, and the process waits for it. The two work together, since automation prepares the request and carries out the outcome, while the approval workflow governs the decision in the middle.
How to run an approval workflow well
Write the rule once, then make the orchestrated path the fastest one. When following the workflow takes less effort than sending a message, people follow it, and the trail fills itself.
- Give each step one owner and each approver a deadline.
- Send the request with its context: the amount, the reason, the documents.
- Run independent approvals in parallel.
- When an approver misses the deadline, the process asks, reminds, then escalates. Nothing is approved by default.
- When a term changes after approval, the request goes back to the right approver with what changed.
- Record every decision with its basis. That record is the request’s audit trail.
- Keep the decision with the person who answers for it, which is what human-in-the-loop means on an approval.
- Let the process owner change the rule, while IT controls who can publish the change.
Then measure one number: the time from request to decision. If it does not drop, the workflow is a form, not a path.
Callout · Three signs your approvals run outside the process
- A term was agreed in a thread, and nobody can show who approved it.
- Requests still go to the person who used to hold the role.
- The same approval is asked twice, because the first answer is lost in a channel.
Learn more: see how operations and sales teams run their approvals with Ofelia, and how the deal desk handles non-standard deals.
Ofelia Agentic and approval workflows
Ofelia Agentic is the governed agentic execution layer for enterprise operations, inside Slack and Microsoft Teams. It runs approval workflows where requests already start, works with your ERP, HR system, CRM and any system you use, and leaves every decision to a person.
Ofelia answers and guides first. An employee asks “Who approves this purchase?” or “What do I need to request a contractor’s access?”. Ofelia answers from the approved policy and your connected systems, then guides them to the next step, with a button to submit the request.
When a request crosses teams, Ofelia runs it as a workflow. Take a contract review. The rep launches it from Slack with the customer’s terms attached. Legal gets one request with the deal context and a deadline, and Finance gets the payment terms at the same time. An agentic step extracts the key terms and flags the clauses that leave the standard, and a lawyer decides on each one. If an approver misses the deadline, Ofelia asks, reminds, then escalates. If the customer redlines a clause Legal already approved, the request goes back to Legal with what changed, while the other approvals stand. Once every approval is in, the signature request goes out, and every decision is on record: who approved what, when, under which rule.
Watch one deal orchestrated from lead to renewal, in four minutes
The process owner, in Finance, Legal, IT or HR, gives Ofelia the policy or describes the rule in plain language. Ofelia proposes the workflow, with its approvers, thresholds and parallel steps, and the owner adapts it in the no-code Workflow Designer, tests it and publishes it into Slack or Teams. IT keeps control of who can build and publish, of access and connections, and of the full audit trail. Everyone a request needs can take part, CRM seat or not.
Under the hood, Ofelia builds on Bonita BPM, which has run enterprise processes for more than 15 years at more than 130 enterprise customers. The right path is the fastest one.
Download the Ofelia Agentic one-pager (PDF).
See Ofelia run your approval workflows in a personalised session
Frequently asked questions
What is the difference between an approval process and an approval workflow?
An approval process is the policy: who must approve which request, and under which conditions. An approval workflow is the path that runs that policy every time. It routes each request to the right approvers in the right order, handles silence and changes, and records every decision. The process says what should happen, and the workflow makes it happen.
What happens when an approver does not answer: should the request be approved by default?
No. When an approver misses the deadline, a well-run approval workflow asks again, sends a reminder, then escalates to the next person in line. Approving by default turns silence into a decision that nobody took and nobody can answer for. The speed comes from the deadline and the escalation, not from skipping the approver.
What happens when the customer changes a term that was already approved?
The approval no longer holds for that term. In a well-run approval workflow, the change goes back to the approver who owns it, with what changed, while the other approvals stand. The new decision is recorded next to the first one, so anyone can see which version was approved, by whom and when.
Sources
Expected results: Ofelia Agentic use cases (purchase request and multi-level approval, expense report, contract review, access request, deal desk).