Make it clear whose decision comes next.
A purchase request goes out on WhatsApp, the quote follows by email, and the go-ahead comes in a phone call nobody wrote down. We build approval workflows where the request, the route and the decision stay together.
Most approval chains look simple when someone draws them: the requester submits, the manager approves, finance pays. In practice the request arrives in pieces across chat, email and a call. The approver replies "ok" in a group with forty other messages. Two weeks later, finance asks who signed off and at what amount, and the answer is a long scroll through someone's phone.
Staff end up spending more time chasing than deciding. Requesters can't tell whether their request is stuck, under review or quietly forgotten, and approvers can't see what's waiting for them without searching.
An approval workflow fixes the record first. The request is captured with everything needed to decide on it. The software routes it by the rules you agree, tells the right person, and stores the decision with any comments, so everyone can see where it stands.
None of this removes judgement. The people who approve today still approve. What changes is that the request reaches them complete, the decision is written down where the next person will look for it, and nobody has to remember to follow up.
Requests that usually need a sign-off.
Most businesses run several of these in parallel, each with slightly different rules.
Who decides depends on the request.
Rules can draw on amount, department, branch or request type. A hypothetical purchase policy might look like this.
The return path matters most.
Requests are sent back far more often than flowcharts suggest. That's where processes get confusing, so we design it early.
A reviewer sends it back
One detail is wrong: a missing quote, a wrong cost centre. The reviewer notes what needs fixing.
The requester corrects it
Decide which fields can change after a return. Sometimes only the flagged one; sometimes the whole request.
Do earlier approvals stand?
If the amount changed, earlier sign-offs may need repeating. If only an attachment was added, perhaps not. Write the rule down.
The reviewer sees what changed
The new version shows its differences from the old one, and the reviewer gets a notification that it's back in their queue.
What people notice after the switch.
- Requesters see live status instead of sending "any update?" messages.
- Approvers get one list of what's waiting for them.
- Rejections come with a reason and a clear way to resubmit.
- Withdrawn requests are marked as withdrawn, not deleted.
- Finance can see who approved what, at what amount, and when.
- Every comment and edit sits on the request in an audit trail, with notifications tied to each step.
Approval questions.
Can a request need more than one approval?
Yes. Approvals can run in sequence, in parallel, or a mix of both, depending on the request type and the rules you set.
Can approvers decide from their phone?
We usually design for it, since that's where most approvals happen today. The approver opens the request from the alert, sees the details and attachments, and decides there.
Can people see why a request was rejected?
Yes. A rejection carries the reviewer's note, and the requester can either withdraw the request or resubmit a corrected version that keeps the earlier conversation attached.
What if our approval limits change next year?
Limits, approvers and delegations that change often can be made editable by an authorised admin. Requests already in progress keep the rules they started under unless you decide otherwise.
Which approval do you chase most?
Tell us about it and we'll sketch the route, the return path and the record it needs.