Most approval processes live in email and a spreadsheet. Here is the model behind a real one, the prompts to build it with your AI coding assistant, and what it takes to run it for a team.
Your private status link is on its way to your inbox.
A purchase approval workflow is four parts: a request form that captures amount, category, vendor and justification, a routing rule based on amount and category, a queue where approvers act with context, and an immutable audit record. Email and a spreadsheet cover the first and none of the rest, which is why sign-off gets chased and audits get painful. You can build the whole thing with an AI coding assistant in an afternoon, and the harder part is not the build: it is running it with real access control, real credentials into your finance system, and a named owner.
Purchase approvals
14
Awaiting your approval
3
Overdue
2.4 days
Median to decision
38
Approved this month
Why do you need it
Design tooling renewal. Two teams are past the seat limit and cannot add anybody until this clears.
Asked before the amount, on purpose
Amount
18,400
Category
Software and subscriptions
Vendor
Figma
Needed by
30 September
This will need
VP Design, then Finance
Two approvers. At 15,000 it would need one.
You own finance operations, procurement, or a budget that other people spend against. You already know your approval policy: what needs sign-off, at what thresholds, and from whom. You do not need to write code to follow this, but you do need that policy clear in your head, because it is the part no tool can decide for you.
What a requester and an approver each do with it, in order.
Amount, category, vendor and a business justification, in one form. The form asks for the justification before it asks for the amount, because that ordering produces better answers.
Rules send it to the right approver based on amount and category together, and the requester can see where it sits and with whom without asking.
Each approver sees the request, what this vendor has cost before, and what similar requests were approved at. No second tab.
Nothing stalls because someone is on leave. A named deputy picks it up after a set number of days.
Every decision is appended with who, when, and what they saw at the time. This is the part an auditor asks for first and the part email cannot give you.
An approval workflow is not a form with an email trigger. It is four parts that have to work together, and getting the model right is what makes the build follow from it.
Amount, category, vendor, business justification, and the budget it draws against. The justification field earns its place: it is what an approver reads to decide, and what an auditor reads two years later.
Which approver a request goes to, based on amount and category together. This is your policy expressed as logic, and it is the part that has to match how your company actually delegates authority.
One place where an approver sees what is waiting on them, with enough context to decide without asking three questions first. Approvals stall in inboxes because an email is a notification, not a queue.
Who approved, when, what the request said at that moment, and what changed after. Reconstructing this from an email thread is the work nobody budgets for until an auditor asks.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
The form, and the rule that decides who sees it.
In this Helix project, build me a purchase approval workflow.
Start with the request itself. Someone asks to spend money, so I need the
amount, the category, the vendor, when it is needed by, and a business
justification. Put the justification field above the amount. People write
better answers when they have not already anchored on a number.
Then the routing. Do not route on amount alone: a small legal spend goes
to someone who cannot assess it, and a large routine renewal crawls
through three approvers who add nothing. Route on amount and category
together, and keep those rules in one place I can edit without asking
anybody. Show the requester which approvers their request will need
before they submit it.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.Worth knowing. Showing the routing before submission is the cheapest control here. People right-size their own requests when they can see the threshold.
Everything needed to decide, without opening anything else.
Now build the screen an approver actually opens.
For each request waiting on them, show the request, who asked, what this
vendor has cost us before, and what similar requests in this category were
approved at. An approver who has to go and look something up will decide
tomorrow instead of now, and tomorrow is how approval processes die.
Give them four actions: approve, approve with a condition they type,
reject with a reason, or ask the requester a question without ending the
request.
Sort the queue by how long each request has been waiting, not by when it
arrived. Those are different, and the first one is the one that matters.Deputies, reminders, and the reason approvals actually get finished.
Make sure nothing sits still.
Every approver has a named deputy. If a request goes untouched for a
number of days I set, it moves to the deputy automatically and both people
are told. Approval processes do not fail because someone says no, they
fail because someone is on holiday.
Remind approvers of what is waiting on them, once a day, in one message
rather than one per request.
Track time to decision per approver and per category, and show it on a
dashboard. If one step is always the slow one, I want that to be a fact
rather than a suspicion.What an auditor asks for, ready before they ask.
Add the audit record.
Every state change gets appended, never edited: who did it, when, what
they decided, why, and a snapshot of what the request looked like at that
moment. Requests get edited after approval, and the snapshot is the only
thing that makes that visible.
Then give me the views built on top of it: everything approved in a
period, everything rejected and why, and anything approved outside the
normal rules. That last list is short and it is the one worth reading.The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<NetSuite>. Check the budget line a request is drawn against, and push
approved purchases through as commitments.
<Okta>. Resolve who somebody's manager is, so routing does not depend on a
list somebody maintains by hand.
<Slack>. Tell an approver something is waiting, and let them approve
without opening another tab.
<Google Drive>. Keep quotes and contracts attached to the request, which
is what an auditor asks for.
<Coupa>. Raise the purchase order once a request is approved, so approval
and procurement are not two separate acts of typing.
<DocuSign>. Send anything above a threshold for signature and read the
status back onto the request.
<Google Sheets>. Export the approved list for whoever still wants it in a
spreadsheet, which is most finance teams.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. Set Access Control on the project before you share it, so approvers see what is theirs and requesters see their own requests.
An approval workflow is mostly about reaching the people and the systems that already hold the answer.
NetSuite
Check the budget line a request is drawn against, and push approved purchases through as commitments.
Okta
Resolve who somebody's manager is, so routing does not depend on a list somebody maintains by hand.
Slack
Tell an approver something is waiting, and let them approve without opening another tab.
Google Drive
Keep quotes and contracts attached to the request, which is what an auditor asks for.
Coupa
Raise the purchase order once a request is approved, so approval and procurement are not two separate acts of typing.
DocuSign
Send anything above a threshold for signature and read the status back onto the request.
Google Sheets
Export the approved list for whoever still wants it in a spreadsheet, which is most finance teams.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working app. An approval tool holds spend data, reaches into a finance system, and outlives whoever built it, so a few things have to be true before other people can use it.
AI Deployment
One command takes the app from your assistant to a live address, so approvers get a link rather than instructions for running it locally.
App Security
Approval data is spend data. SSO means an approver signs in with their existing account, and access is scoped to the workgroup that should see it.
App Security
The app needs to read budget codes and write approved spend. Managed credentials mean the connection is granted to the app rather than pasted into it, and can be rotated or revoked without a redeploy.
App Registry
Every app carries a named owner and an entry IT can see. When the person who built the approval tool changes role, the tool does not become nobody's problem.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
It is the path a spending request takes from submission to a decision: capture the request with amount, category, vendor and justification; route it to the right approver based on your delegation policy; give that approver a queue and the context to decide; and record who approved what and when. The record is the part that separates a workflow from an email thread.
Buy when your policy matches the vendor's model and you would rather not own the thing. Build when your routing rules are specific to how your company delegates authority, which is common, because a procurement platform imposes its own model and you spend the contract bending your policy to fit it. Building is now an afternoon rather than an engineering project, which changes the maths.
Amount, currency, category, vendor, the budget it draws against, and a business justification long enough to be worth reading. The justification is what an approver decides on and what an auditor reads later, so a minimum length on that field does more for approval speed than any amount of workflow tuning.
Route on amount and category together, not amount alone. Amount alone sends a small professional-services contract to a manager who cannot assess the terms, and a large routine renewal through three approvers who add nothing to it. Keep the rules as data in one place so a threshold change does not require touching logic.
Who approved, when, and a snapshot of the request as it stood at that moment, kept append-only so corrections are new entries rather than edits. The snapshot is the part teams skip: an auditor needs to see what the approver was looking at, not what the record says today.
Yes. The prompts on this page are written for Claude Code, Codex or Cursor and build the app in stages, so you can stop after any of them and still have something that runs. The part that needs thought is not the code, it is your approval policy, and you already know that.
Finance
Check expense claims against your own policy before a human sees them, so reviewers only look at the ones that need judgement. Prompts to build it, and what it takes to run it.
Finance
Match invoices to what was approved, route the exceptions, and stop paying late because an email got buried. Prompts to build it, and what it takes to run it.
Finance
Show budget owners where they stand before the month closes: committed versus actual, variance by owner, and a forecast they can act on. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.