Automating a purchase request can remove chasing and lost emails. The request still needs to reach someone with the right authority, and the resulting order must match what they approved.
Begin with a clear request record and explicit outcomes. “Approval email sent” should never mean “purchase approved”.
Decide what the request authorises
Write down the boundary. Is the approver agreeing a budget, a particular supplier quote, or an order ready to place? Those decisions aren't interchangeable.
A fictional facilities company might ask managers to approve a specified item, quantity and maximum total cost. Its request record includes the supplier quote, delivery requirements and cost centre. A later change to the specification or total needs another decision under the company's rules.
Your authority limits should come from the business, not from an automation template. Include relevant taxes, delivery and recurring commitments in whatever total the approver is being asked to consider.
Give the approver enough to decide
An approval notification should lead to a record containing:
- what is being bought and why.
- the quote or other evidence, with its version.
- the amount, currency and ongoing commitment if applicable.
- the budget or job it belongs to.
- the requested date and consequence of delay.
- the person requesting it and any required second approver.
Don't put sensitive supplier documents in a widely shared message channel merely because the workflow can post there. Use the appropriate record access and give reviewers a working link.
Choose the approval rule deliberately
Some decisions need one authorised person. Others require everyone listed, or a sequence of separate decisions. Microsoft's approval documentation describes these different response patterns. Choosing the first response rule when two approvals are required would change the business control, even though the workflow runs successfully.
Also distinguish sending a request from receiving a decision. In Power Automate, creating an approval doesn't itself wait for its completion. A builder must connect the outcome to the correct next action.
Ask for a demonstration of rejected, cancelled and unanswered requests as well as approved ones. Silence should go to an agreed exception route, not be interpreted as permission.
Keep approved details attached to the outcome
Record which version was approved, by whom and when. If someone changes the quantity afterwards, the earlier decision shouldn't automatically cover it.
Separate approval from ordering if a person still needs to check stock, delivery or final terms. The workflow can prepare an order task containing the approved details. It doesn't have to place the order itself.
Likewise, this process doesn't approve later supplier bank-detail changes or establish that an invoice is correct. Those are separate checks. Building a tidy purchase request workflow shouldn't quietly remove them.
Plan for absence and stalled requests
Name a deputy with the necessary authority rather than simply forwarding every delayed request to whoever is online. Set a review interval and escalation route appropriate to the purchase.
Show requesters what is waiting and who owns the next action. Repeated submission often means people can't see whether the first request went anywhere. Give a request a stable reference and prevent the same submission creating several orders.
For long waits, have the builder demonstrate the platform's timeout behaviour and how the request is closed or resumed. Don't assume a pending item will remain active indefinitely.
Try the decisions you don't want to get wrong
Use fictional quotes and a test environment that cannot place real orders. Cover a normal approval, a rejection, an absent approver, an amount above the requester's route and a changed quote after approval. Repeat a submission and confirm it produces one request.
At the end, inspect the resulting order task rather than stopping at the notification. It should identify the approved version and the next responsible person.
Measure request age, time spent chasing and the number of items returned for missing information. Those results help decide whether to widen the workflow to another team or improve the request form first.