A purchase request approval workflow, and the thresholds

Every company reaches the same point. Purchases used to be three people who talked to each other, and now they are forty people, a WhatsApp group, and an email thread where the approval is a message that says "ok go ahead" with no amount in it. Finance cannot tell what was committed, the person who ordered cannot prove they were allowed to, and nobody can answer the only question that matters at audit, which is who approved this and against what limit.

A purchase request approval workflow fixes that, and it is one of the better internal tool projects because the requirement is unusually clear. It is also one of the easiest to overbuild. This note is about what the thing actually needs, what the platforms you already pay for will do for free, and the two design decisions that determine whether people use it or route around it.

What the workflow is, minimally

Five states and nothing more in a first version. A request is drafted, submitted, approved or rejected, ordered, and received. The request carries a requester, a cost centre, a description, an amount, a currency, and a vendor. The approval carries an approver, a timestamp, and a comment.

That is the whole data model, and resisting additions to it is most of the design work. Every field someone proposes in the first meeting, the budget line, the project code, the delivery address, the asset tag, is defensible on its own and collectively turns a form people fill in into a form people avoid. The rule I use: a field earns its place only if a decision changes when it is missing.

Thresholds: the part that is a policy question, not a technical one

Who approves what at which amount is the core of the system, and it is not yours to decide. It belongs to whoever owns the money. What you can do is force the question to be answered precisely, because an unanswered threshold is where these projects stall for weeks.

Three questions decide the configuration, and you want them answered in writing before you build anything. Is the band read from the gross or the net amount. Does a recurring monthly commitment get assessed on the monthly figure or the annual total, which is the one that gets gamed. And can a requester approve their own request when they are also the budget holder, which sounds like an edge case and is actually the single most common exception in a small company.

That last question is worth getting right because it is the one auditors ask first. On the buying side of a larger transaction the same structure appears from the other direction, and this piece on who is really in the B2B buying committee is a useful read on how many people a purchase decision actually passes through once amounts get material.

Check what you already pay for before you build

This is the part I am obliged to say before quoting on a build, because for a lot of companies the answer is that they already own enough. If you are on Microsoft 365, the approvals machinery is documented and ready to assemble: the Power Automate approvals documentation describes an "Approvals - Start and wait for an approval" action you drop into a flow, with approvers responding from their email inbox, the approvals centre, or the mobile app.

Multi approver routing is documented too. The parallel approval guide covers exactly the case where several people must sign off independently, and it names purchase orders among its examples. So "we need finance and the department head to both approve" is a configuration, not a feature request.

Two specifics from those pages are worth knowing before you commit to the configured route, because they shape what you can build on it. The first is a real ceiling: the documentation says that if a flow might run for more than 30 days, you store approvals in Microsoft Dataverse and split the work into two flows, one to send the request and one to act on the response, using the "Create an approval (v2)" action. A purchase request waiting on a director who is travelling can absolutely exceed 30 days, so the naive single flow version has a failure mode built into it.

The second is smaller and catches people in testing: the documented condition compares the approval response against the text "Approve", and the parallel guide notes that this text is case sensitive. A workflow that silently treats every approval as a rejection usually has that as its cause.

Cancellation is also only partly there. The documentation says the cancel feature is supported on the "Create an approval (v2)" action, so a requester withdrawing a request is available but only on the route that uses that action. And external approvers are possible through Microsoft Entra guest users, which matters if a part time finance director sits outside your tenant.

The question that decides whether anyone uses it

Not thresholds. Delegation. What happens when the approver is on leave, travelling, or has left the company.

Almost every first version answers this with nothing, and the consequence is predictable. Requests sit, work stops, somebody phones somebody, the purchase happens outside the system, and within two months the system is a place where requests are recorded after the fact rather than approved in advance. At that point you have built a logging tool and called it an approval workflow.

Three mechanisms, and you want at least two of them. An explicit delegate per approver, set in advance rather than in the moment. A time based escalation where a request unanswered after a defined period moves up a level, and the period should be short, a day or two, not a week. And a documented break glass path for genuine urgency, where a senior person can approve out of band and the record shows plainly that it happened that way.

That third one makes people uncomfortable and it is the one I argue hardest for. Urgent purchases will happen whatever the policy says. Your choice is whether they happen inside the system with a visible exception flag, or outside it with no record at all. The same trade off shows up in every internal process tool, and it is the pattern behind the onboarding tool note as well.

What finance will ask for on day two

Build the data model so these are reports rather than rebuilds, because they will be requested and they are cheap if you anticipate them. Committed but not yet invoiced, by cost centre. Approvals by approver and amount band, which is how you find out that one manager approves everything in four seconds. Requests that bypassed the flow, which is the number that tells you whether the system is working. And time from submission to decision, which is the number that tells you whether people will keep using it.

None of those need a dashboard in version one. They need the underlying records to carry timestamps and the amount band that was applied, which costs nothing now and is painful to retrofit. The general approach to this is in reporting automation for a small business.

When not to build this

If your accounting system already has requisitions, use them. Most mid tier accounting and ERP products ship a purchase requisition module, and a half used module beats a well built parallel system that finance has to reconcile by hand every month. Check this first, properly, including asking your accountant rather than only reading the feature list.

If you process fewer than roughly twenty purchase requests a month, a shared form plus a clear written threshold policy will get you most of the control for none of the build cost. The decision order is in custom software versus off the shelf, and for a company this size the honest answer is usually off the shelf or not yet.

The case for building is narrower than it looks: you have approval rules your accounting system cannot express, such as per project ceilings or multi currency bands, or you need the request to carry data from another system you already run, or you operate across entities with different signatories. Short of that, the risk is the ordinary one described in why software projects fail, which is a correct build of a process nobody had agreed on.

Two limits worth stating

The Microsoft behaviours above were documented on pages last updated in August 2026 for the approvals walkthrough and September 2025 for the parallel guide, and the 30 day limit in particular is a current platform constraint rather than a permanent law. If you are choosing between configuring and building, open both pages and check them against what you see in your own tenant, because this is exactly the kind of detail that changes quietly.

And a limit on the whole idea: an approval workflow does not control spending, it records authorisation. It will not stop a manager approving things they should question, and it will not make a bad purchase good. What it does is make the pattern visible, so somebody can ask about it. That is worth building. Expecting more than that from it is how these projects end up with features nobody uses.