Automation  ·  Finance

How to build purchase request approval

Somebody needs a tool, asks in a thread, and three weeks later buys it on a card because nobody knew who had to say yes. The model behind requests that reach the right people, the prompts that build it, and what it takes to run it.

Built with Tray Headless

  1. System Slack
  2. Step Check what we already own
  3. Step Pick the reviewers
  4. Step Chase and delegate
  5. System Coupa
Also Requester told

The request is checked against what the company already owns before anybody is asked to approve it.

The short answer

What is purchase request approval?

Purchase request approval comes down to four things: one way to ask that works where people already are, a check against existing contracts and licences before anybody approves, reviewers chosen from what is being bought rather than one fixed chain, and approvers chased and delegated before a request stalls. The part teams get wrong is the routing. Sending every request through the same chain means a box of pens waits behind a legal review, and a new data tool skips the security review it needed.

Stage 1 of 7: Purchase request and approval. Part of Procure-to-pay, end to end : every stage, the systems it runs on and the guide that builds it.

What matters here

  • Take requests where people already ask. A form nobody can find produces purchases on personal cards.
  • Check for an existing contract or licence before approval. The cheapest purchase is the one the company already made.
  • Choose reviewers from what is being bought. Software needs IT and security, a new supplier needs onboarding, a contract needs legal.
  • Run independent reviews in parallel. Legal and security waiting on each other doubles the wait for no reason.
  • Tell the requester every time the status changes. A request with no visible status gets asked about in four places.

Who this is for

You run procurement operations or finance systems. Requests arrive in Slack, email and hallway conversations, nobody can say who approves what, and spend appears on cards that never went through procurement at all.

How it works in practice

What has to happen between somebody needing something and a purchase order being raised.

  1. 1

    A request is raised where the requester already works

    A short form in Slack or the service portal: what, why, roughly how much, which supplier if known, and when it is needed.

  2. 2

    It is checked against what the company already has

    An existing contract with that supplier, spare licences for that tool, or a catalogue item that covers it. Any match is offered before approval starts.

  3. 3

    The reviewers are chosen from what is being bought

    The budget owner always. IT and security for software, supplier onboarding for a new supplier, legal for anything with a contract attached.

  4. 4

    Reviews run in parallel, with a deadline on each

    Approvers are chased before the deadline, and anybody marked away hands to their deputy automatically.

  5. 5

    The requester sees every change in status

    Approved, waiting on security, sent back with a question. In the thread where they asked, not in a separate portal.

  6. 6

    An approved request becomes a requisition

    Raised in the procurement system with the approvals and attachments carried across, ready for the purchase order.

What purchase request approval is made of

Four parts, and the third is the one that decides whether people use it.

One front door

A short form where people already ask, in Slack, Microsoft Teams or the service portal. The fields are the ones routing needs, and nothing else.

A check for what you already own

Contracts, licences and catalogue items looked up before approval, so a duplicate tool or a second contract with the same supplier is caught at the request.

Routing on what is being bought

Category, amount, supplier status and whether data leaves the company decide who reviews. The rules sit in a table procurement maintains.

Chasing and delegation

Every review has a deadline. Approvers get a reminder before it passes, and anybody away hands to a named deputy instead of holding the request.

The Tray Headless prompts

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

  1. 1

    First, read the request and procurement models

    Routing depends on fields the requester never sees.

    Headless skills build-workflow 

    Use build-workflow. The systems in play are Slack, Coupa, Okta,
Ironclad and Google Drive, or whatever we run in those seats. Before
you plan anything, tell me which of them are already authenticated in
the workspace.

I need the requisition object in Coupa, the supplier list with its
status, the commodity or category list, and the contract records in
Ironclad with their supplier and end date.

Then tell me: where does the list of software we already pay for live,
and does it name an owner for each tool. That decides whether the
"already own it" check is possible on day one.
  2. 2

    Build the front door in Slack

    Because a form nobody can find is a purchase on a personal card.

    Headless skills build-workflow 

    Use build-workflow. Add a shortcut in Slack that opens a short form:

  What do you need, in a sentence
  Why, in a sentence
  Supplier, if you know it
  Rough cost and whether it repeats
  When you need it by
  Does it store or touch customer or employee data (yes, no, not sure)

Keep it to those fields. Derive the cost centre and the requester's
manager from the directory, never ask for them.

Post a confirmation in the thread with a request number, and keep every
later status update in that same thread.
  3. 3

    Check what we already own

    The cheapest purchase is the one the company already made.

    Before routing for approval, look up:

  An active contract with the named supplier
  Spare licences for the same tool, with the owner
  A catalogue item that covers the request

If anything matches, reply in the thread with what was found and who
owns it, and ask the requester whether that covers it. Only route for
approval if they say no or nothing matched.

Match supplier names loosely. The same company appears under its trading
name in the request and its legal name in the contract.
  4. 4

    Pick the reviewers from what is being bought

    One chain for everything slows the small purchases and misses the risky ones.

    Build the routing as a table procurement can edit, not as logic:

  category, amount band, new or existing supplier, data access (yes,
  no, not sure), and the reviewer roles each combination needs

The budget owner always reviews. Add IT and security for software or
any "yes" or "not sure" on data access, supplier onboarding for a new
supplier, and legal when a contract or order form is attached.

Resolve each role to real people through Okta at run time. Never put a
name in the table, because the person in the role changes.

Run independent reviews in parallel. The budget owner goes first only
when the amount is above a threshold I set.
  5. 5

    Chase, delegate and close the loop

    A request waiting on somebody on leave is a request that gets bought anyway.

    Give every review a deadline from the table. Remind the reviewer in
Slack a day before it passes, and escalate to their manager after it.

If a reviewer is marked away, hand the review to their named deputy and
say so in the thread.

When every review is done, raise the requisition in Coupa with the
approvals, the answers from the form and any attachments carried across
from Google Drive. Tell the requester it is approved and what happens
next.

If any reviewer sends it back, post their question in the thread and
pause until the requester answers.
  6. 6

    Validate, then hand the table to procurement

    Because who reviews what is a procurement policy.

    Run the per-step schema checks and the whole-workflow audit before this
touches production. Run it alongside the current process for two weeks
and compare who it would have routed each request to.

Then open the same workflow in Tray Build so procurement can change the
routing table, the deadlines and the deputies in the visual canvas.

What it connects to

People ask in chat, the policy sits with procurement, and the approved request lands where purchase orders are raised.

Slack

Take the request through a shortcut, post every status change in the same thread, and chase reviewers before their deadline.

Reads and writes

Coupa

Read the supplier list and catalogue, and raise the approved requisition with its approvals attached.

Reads and writes

Okta

Resolve reviewer roles and deputies to the people in them today, and find the requester's manager.

Reads

Ironclad

Look up active contracts with the named supplier, so a second contract is caught at the request.

Reads

Google Drive

Hold the quote, the order form and anything else attached, linked to the request for the auditor.

Reads and writes

Snowflake

Land each request with its route and timings, so time to approval by category is a query.

Writes

Same build, other stacks

The design does not change if you run something else in one of these seats. The same prompts build it against Google BigQuery, Microsoft Teams, Azure Active Directory, SharePoint, Databricks or Google Chat.

Connections in this build

Field mapping, templates and common problems for each pairing: Okta + Slack, Ironclad + Slack, Google Drive + Slack and Ironclad + Google Drive.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Running it in production

This decides who can commit company money. It is audited, and people stop using it the first week it is slow.

It runs on the platform, not on your laptop

Every request, reminder and escalation runs on the same engine, at whatever volume the start of a quarter produces.

Every approval is evidence

Who reviewed, in which role, against which version of the routing table, and when. That is what an auditor asks for first.

Credentials are managed, never written into the build

The credential that raises requisitions lives in your workspace, scoped to procurement, and nowhere near the routing rules.

Procurement owns the routing table

Categories, thresholds, deadlines and deputies open in Tray Build, maintained by the team that sets the policy.

Requesters always see the status

Every change posts in the thread where they asked. A request with no visible status gets asked about in four other places.

Questions people ask

Why check for existing contracts before approval?

Because the request is the cheapest place to catch a duplicate. Once a second contract is signed with the same supplier, or a second tool bought for the same job, the money is already committed.

Who should review a purchase request?

The budget owner always. IT and security when it is software or touches company data, supplier onboarding when the supplier is new, and legal when there is a contract. The amount alone is a poor guide to risk.

Should requests go through a procurement portal?

Take them where people already ask, and let the procurement system hold the record. A portal people have to remember to open gets bypassed, and the bypass shows up later as card spend.

How is this different from the approval matrix in procure-to-pay?

This covers the request: intake, the check for what you own, and the cross-team reviews. The procure-to-pay guide picks up at the requisition with the budget check, the purchase order and matching.

Can procurement change the routing without engineering?

Yes. The routing table, deadlines and deputies open in Tray Build, so a new category or a reorganisation is a table edit.

Related guides

Finance

How to build a procure-to-pay integration

Requisition to PO to receipt to payment, with the approval matrix as data, three-way matching, and the budget checked before the commitment. The prompts.

Legal and compliance

How to build vendor security review

Tier on what the vendor can reach, ask questions that match the tier, track conditions to closure, and re-review before the evidence expires. The prompts.

Finance

How to build a vendor master sync

Onboard a supplier once, verify bank details out of band, keep one record per legal entity, and make a change to payment details an event. The prompts.

IT and security

How to build access request and approval

Route to the system owner, grant with an expiry by default, provision automatically, and produce the access review as a by-product. The prompts that build it.

Last reviewed October 2026.