Designing approval systems that people can trust
What a procurement platform taught us about roles, state, and keeping important actions easy to follow.
An approval flow looks simple on a whiteboard. Someone asks, someone approves, and the work moves on. Real products are rarely that neat. People leave, requests come back, permissions change, and money may move at the end.
A trustworthy workflow always tells people what happened, who needs to act, and what can happen next.
Muhammad Amjad, One Percent
flowchart LR
A[Buyer creates request] --> B{Approval needed?}
B -->|No| D[Invite vendors]
B -->|Yes| C[Approval levels]
C -->|Approved| D
C -->|Returned| A
C -->|Rejected| X[Close request]
D --> E[Compare proposals]
E --> F[Purchase order]
F --> G[Receive goods]
G --> H[Release payment] Start with the business event
In Vakse, the useful unit was not the page or the button. It was the business event: create an RFP, invite a vendor, approve a purchase order, receive goods, or pay an order. Each event could be allowed, blocked, returned, or rejected.
Naming those events first gave the product a stable language. The interface could change without changing what the system meant.
Make state visible
A request needs more than approved or rejected. It can be waiting at a specific level, returned for changes, resubmitted as a new attempt, or completed. We kept a separate status record for every entity and a row for every approver action.
That history makes support easier and gives users confidence. When someone asks why an order did not move, the answer is in the product rather than in a private message.
- Show the current step and the next responsible person
- Keep earlier attempts instead of overwriting them
- Explain why an action is unavailable
- Treat notifications as reminders, not as the source of truth
Permissions belong in the data layer
Buyer, vendor, approver, receiver, and payer are not labels for navigation. They define who may see and change company data. The interface should hide actions that do not apply, but the database must enforce the same rule.
For Vakse, company-scoped access and row-level security helped keep one company from seeing another company’s records. This matters more as a product adds chat, files, payments, and shared vendor networks.
Design for the unhappy path
The best workflow work happens after the happy path is drawn. What if no invited approver has accepted? What if one person returns a request? What if payment succeeds but the browser closes? These cases need deliberate answers.
Our rule is simple: every important transition should be repeatable, auditable, and understandable by a person who did not build the system. That is how a complex workflow starts to feel calm.
Muhammad Amjad
Co-founder and CEO at One Percent. Writes about the practical choices behind products that need to work in the real world.