Bismillah.
A purchase request arrives in a group chat. A manager replies “approved.” Later, finance asks which quote was approved and who authorized the final amount. The team has to reconstruct the decision from messages, attachments, and a spreadsheet.
If you’re commissioning custom software, walk through a case like this before designing screens. Follow one request from submission to handoff, and capture the decisions people currently make along the way.
Start with a real request
Ask a requester, an approver, and a finance teammate to walk through a recent case together. Gather the original request, the quote, the approval message, and the record finance used. Then write down who owned each handoff and where people waited, copied information, or asked for clarification.
Turn that walkthrough into a small map. Here is an illustrative purchase approval flow.
| Step | Owner | Rule |
|---|---|---|
| Submit | Requester | Provide the vendor, amount, currency, cost center, and quote. |
| Review | Department manager | Approve, reject, or return the request with a reason. |
| Approve high-value requests | Finance approver | Review requests that exceed the department’s configured approval limit after manager approval. |
| Hand off | Procurement | Receive the approved request and its supporting documents. |
Agree on where the workflow ends. If this release ends at the procurement handoff, the application can show that a request was approved and handed off. Purchase orders, deliveries, and payments can have their own workflows.
Write down what happens when the request changes
Suppose a vendor updates the quote after approval. The team could require a new request or allow a revised version to go through approval again. In the second design, retain the previous version and its approval history, route the revised version using the new amount, and make clear which version procurement can act on.
Work through a few other cases together. What happens when an approver is away? Can a requester withdraw a pending request? Who can approve if a manager submits the request personally? Each answer can become an acceptance test.
One useful test reads like this. Given an approved request, when the requester submits a revised quote, the revised version returns to review and procurement can no longer act on the earlier approval. Also decide what happens if procurement has already placed the order, since that change may require a separate amendment process.
Capture the decision and design the report together
For each approval, rejection, or return, record who acted, when they acted, which version they reviewed, and the reason where applicable. Decide who can see the history and supporting documents. Give approvers the context they need to make a decision, and give finance enough information to reconstruct it later.
Ask finance to sketch one report they would use each week. For example, a list of pending requests grouped by current approver, with the amount and time spent waiting, makes it easier to find a bottleneck. To build that report, agree on when the waiting clock starts and resets, then capture those events in the workflow.
Keep the first release focused
For this example, the first release could cover intake, approvals, decision history, procurement handoff, and one report. Run a handful of representative requests through the design, including a changed quote and an unavailable approver, before committing to integrations or more automation.
If you’re planning custom software for an approval process, inventory workflow, or internal operations, bring one example of how the work gets done today. Tell LionCoders about your project.
Top comments (0)