CONNECTED OPERATIONS
Design approval workflows around real decisions
An approval button is only one part of a business process. The useful design makes it clear what is being approved, by whom and which version will change.
KEY DECISIONS
- Keep proposed and final records distinct
- Check authority on every request
- Preserve the decision trail
Show the source beside the proposal
In our sample component request, the reviewer can compare the item, quantity, total and receiving department. Missing data stays visible. For a real system, define which corrections a reviewer can make and whether a material change requires a fresh approval.
Enforce authority where data changes
Hiding a button is not an access control. OWASP recommends denying access by default and validating permission on every request. Apply that principle to the specific record and action, including direct requests that bypass the interface.
Make retries and changes understandable
If two reviewers act at once, the second should see that the record changed. If an update is retried, avoid creating another order. Keep who decided, what changed and the outcome available to authorised users. Test these behaviours with realistic concurrent actions.
APPLY THE GUIDE
Need help with systems?
Bring the current workflow, website, or unresolved decision. We will start with the smallest useful next step.
Discuss your projectKEEP READING
Related field guides.
AI ENGINEERING
How to evaluate an AI workflow before launch
Define useful outputs, test difficult inputs and separate AI suggestions from approved actions.3 min read
PRODUCTION ENGINEERING