A requisition workflow competes with an alternative that always exists: buying the thing another way and sorting it out later. Whether the workflow wins is decided almost entirely by elapsed time, and elapsed time is decided by four design choices. None of them is about approval policy, which is why policy-first implementations so often produce a process people avoid.
A short form
What, roughly how much, which budget, when, why. Requesters are not finance staff and are doing this between other work. Each extra field reduces the number of requests raised rather than improving the decisions. The why field is the one approvers read, and it is the one most often omitted from form designs.
A named approver with automatic cover
One person, resolved by cost centre and value, with cover during absence and escalation to a named alternative after a set period. Group approval queues produce requests that sit while everybody assumes somebody else is handling them, and absence produces the long tail that people remember when they decide whether to use the process.
Visible status and a prompt answer either way
The requester should see where their request is without asking, and a declined request should say why, promptly. Silence is what teaches people to stop asking. Most of the informal chasing around requisitions is somebody trying to establish one fact, and showing it removes work from both sides.
Questions people ask about purchase requisition workflow
What is a realistic target?
Same working day for routine requests is achievable with cover and escalation configured. Anything slower competes badly with a company card.
How do we handle urgent requests?
A documented fast path with a named approver, reviewed afterwards. Undocumented bypasses leave no record at all.
Should budgets be enforced at request time?
Showing the budget position helps. Hard blocking tends to produce workarounds at the worst moments, so most organisations show rather than block.