Build it with AI
Turn manual approvals into a visible, traceable workflow.
Build an interface for requests, reviewers, evidence, decisions, status, and escalation paths.
Introduction
What an approval workflow has to hold.
Most teams end up with an approval workflow the same way: approvals requested by email and tracked by remembering to follow up. Email approvals work while there is one approver who reads everything. They fail at the point where approval depends on who is available, because an inbox has no concept of delegation and a thread has no concept of a deadline.
An approval sitting in somebody's inbox looks identical to one that was never sent. There is no record of what was approved as distinct from what was requested, no delegation when the approver is away, and no evidence attached to the decision that survives the thread being archived.
What follows covers building an approval workflow: the records it holds (the request, what is being approved, the approver, the decision, and the elapsed time), the systems it reads (Slack and Gmail), and what it does not fix.
The problem
Approvals that live in email threads and end in silence.
Email is where approvals are requested because it is where people are, and it models neither state nor delegation nor deadline. Workflow tools model all three and are routed around whenever the requester is in a hurry, which is always.
The records are the request, what is being approved, the approver, the decision, and the elapsed time, and the authoritative copy of most of them already lives in Slack or Gmail. The spend was approved in a thread, the finance system has no record of it, and the reconstruction six months later depends on somebody still having the email.
The cost is not the inconvenience: work waits on a decision nobody knows is outstanding.
You're likely here because
- The answer to whether something was approved requires searching an inbox
- An approval sitting in somebody's inbox looks identical to one that was never sent.
- When it is wrong, work waits on a decision nobody knows is outstanding
What gets built
Launch builds it, Grow operates it.
Built in Launch
- • Request intake
- • Approval queue
- • Decision log
Operated through Grow
- • Notifications
- • Escalations
- • Follow-up
Systems it reads
- • Slack
- • Gmail
- • Google Drive
The record model
What an approval record has to keep.
- What was requested and what was approved
- As two fields. The gap between them is the one most often omitted and most often needed, because approvals are frequently partial and remembered as total.
- Evidence at the decision
- What the approver was actually shown. Approvals are questioned later, the thread will have been archived, and the evidence is the answer.
- Approver and delegate
- The delegate defined in advance. Without it, one person on leave becomes a two-week stall in every request above the threshold.
- Policy version in force
- So a past approval can be judged against the rule that applied at the time rather than against the current one.
- Request age and its window
- Because the characteristic failure is not refusal, it is a request nobody saw, and only elapsed time makes that visible.
- Threshold and auto-approval record
- Below-threshold approvals granted automatically still need an audit record, and that record is what makes automatic approval defensible.
- Requester and channel
- Including requests raised from chat or email, since a workflow that only records portal requests reports excellent performance on a minority of them.
How it runs
From a request in an inbox to a decision on a record.
Step 01
Describe what an approval workflow has to do
Define what requires approval, at what threshold, and by whom — including who decides when that person is unavailable. Delegation is the field that is always omitted and always needed.
Step 02
Connect the systems of record
Email and chat are where requests originate and where notification has to land, and the systems holding the thing being approved supply the evidence. Meeting people where they already are is what stops the workflow being bypassed.
Step 03
Build the operating surface
Request intake with the required evidence, an approval queue with thresholds and delegation, a decision log, and escalation when a request ages past its window.
Step 04
Start narrow
One approval type — the one that stalls most often — with delegation and a deadline. One type done properly demonstrates the pattern better than a general engine covering everything badly.
Step 05
Route the exceptions
A request sitting past its window escalates to the delegate rather than waiting, which is the single change that removes most approval delay.
Step 06
Measure median and worst-case time from request to decision
Time from request to decision, at the median and the ninetieth percentile. The tail is where the frustration lives and the median hides it entirely.
Implementation path
Building approvals people cannot route around.
- 01
Write the threshold and the approver for each request type, including the delegate. If the delegate is unnamed, the workflow will be bypassed the first time the approver takes a week off.
- 02
Baseline time to decision at the median and ninetieth percentile, plus the share of requests that received no response at all. The last number is usually not zero.
- 03
Make the request path at least as easy as sending an email, or people will send the email. Adoption of an approval workflow is decided almost entirely by intake friction.
- 04
Log decisions with the evidence attached from the first day, since the value of an approval record is realised at audit rather than at the time.
- 05
Build the narrowest useful version first: the single approval type that stalls most often, with the pending approver and elapsed time visible.
- 06
Writing the thresholds, approvers, and delegates for each request type takes a session and the delegate is the field that will be omitted unless someone insists. One approval type with delegation and a window is a week to two weeks. Making intake as easy as sending an email is the design constraint that decides adoption, and it should be treated as a requirement rather than a nicety.
- 07
Once one type runs with delegation, add auto-approval below threshold with the audit record, then the second request type. Analytics on decision time by type comes after, and only if somebody will act on it.
Controls
Controls that matter.
Control 01
Delegation defined in advance for every approver, so absence produces a route rather than a queue
Control 02
The evidence the decision was made on captured with the decision, because approvals are questioned later and the thread will not be there
Control 03
Threshold changes versioned with effective dates, so a past approval can be judged against the policy that applied at the time
Examples
Three approvals that stop stalling.
The approver on annual leave
Pre-defined delegation converts a two-week stall into a routing decision the system makes, without anyone having to work out who is standing in.
Was this ever approved?
A decision log with evidence attached answers in seconds what currently requires searching an archived mailbox and hoping the person still works here.
The request that was never seen
An ageing threshold with escalation catches the requests that fall between people, which in an email-based process are invisible by construction.
How it goes wrong
Three ways approval workflows get bypassed.
The workflow is more effort than an email, so under time pressure people send the email.
Accept requests from chat and email and apply the structure on the way in. The bypassed cases are systematically the urgent and consequential ones, which is exactly the population you needed the record for.
Every request routes to a human, including the ones below any threshold anyone cares about.
Auto-approve below a value with an audit record. Reserving human attention for cases where judgement applies is where most of the time saving is, and it is usually left on the table.
An existing regulated control is retired in favour of the workflow, without checking what the control required.
Confirm signature, identity assurance, retention, and segregation requirements before replacing anything. Producing the record an auditor asks for is not the same as satisfying a specific control.
Limitations and considerations
What a workflow cannot approve for you.
- Faster approvals do not improve decisions. If approval is a rubber stamp, the workflow produces a faster rubber stamp with better documentation.
- Approvals with statutory or contractual weight may have form requirements — signature, identity assurance, retention period — that a general workflow should not assume it satisfies. Check before replacing an existing control.
- Any workflow harder to use than email will be bypassed under time pressure, and the bypassed cases are systematically the urgent and consequential ones.
- If approvals are a formality, this produces a faster formality with better documentation and no better decisions. If there is one approver who reads everything and is never away, email is genuinely adequate.
- Connector coverage varies: Slack, Gmail, Google Drive are representative rather than guaranteed, and the fields exposed depend on your workspace permissions.
FAQ
Build an approval workflow with AI: common questions.
How do we stop people routing around it?
Make intake as easy as email — request from chat or email itself — and make the system the only place the approval is recorded. Enforcement through policy alone loses to time pressure every time.
Can approvals be automatic below a threshold?
Yes, and that is usually where the largest time saving is. Auto-approve below a value with an audit record, and reserve human attention for the cases where judgement genuinely applies.
What should be captured with a decision?
What was requested, what was approved if they differ, the evidence shown, the policy version in force, and who decided. The gap between requested and approved is the field most often omitted and most often needed.
Does this satisfy an auditor?
It produces the record an auditor asks for. Whether it satisfies a specific control depends on requirements around identity assurance, retention, and segregation of duties that vary by regime — worth confirming before retiring an existing control.
What should the first version contain?
The single approval type that stalls most often, with the pending approver and elapsed time visible. Everything else waits until that one is genuinely used.
How will we know whether it worked?
Measure median and worst-case time from request to decision against the baseline taken before anything changed.
Related pages
Keep exploring
Start with ARIA
Ask ARIA to build it.
Describe the website, application, workflow, or operating surface you need. ARIA plans, connects, builds, tests, and keeps refining it — inside the permissions you set.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Build an approval workflow around the process you actually run.
Name the delegate for every approver, make intake easier than email, and measure the ninetieth percentile rather than the median.