Automation  ·  Finance

How to automate approval routing

A refund waits four days because the approver was on leave and nobody else knew they could sign it. Here is how approval routing that never stalls actually works, the prompts that build it, and what running it demands.

Built with Tray Headless

  1. System Salesforce
  2. Step Look up the rule
  3. Step Send with the facts
  4. Step Record the decision
  5. System NetSuite
Also Escalate at the deadline

The rules decide who approves, the request carries its own facts, and a deadline moves it on instead of letting it wait.

The short answer

What is approval routing?

Approval routing decides who has to approve a request from rules held as data, sends each approver the facts they need in the tool they already use, sets a deadline that escalates or delegates instead of waiting, and records who decided what and when. Most approval flows stall on people, not rules. An approver who is away, or who cannot decide without opening three systems, turns a one-minute decision into a four-day wait.

Stage 4 of 7: Approve. Part of Process automation, end to end : every stage, the systems it runs on and the guide that builds it.

What matters here

  • Keep who approves what as data: amount bands, request types and owners in a table, not conditions in the workflow.
  • Send the facts with the request. An approver who has to go and look something up decides later.
  • Ask in the tool approvers already use. Approvals in Slack or Teams get answered; approvals in a portal get forgotten.
  • Give every approval a deadline that escalates or delegates. Waiting forever is a decision nobody made.
  • Check for leave and delegation before routing, not after the request has sat for a week.
  • Record who approved, what they saw and when. The record is what the auditor asks for.

Who this is for

You run finance or business operations. Discounts, refunds, spend and exceptions need someone's sign-off, the rules live in a spreadsheet and people's heads, and requests stall whenever an approver is busy.

How it works in practice

What has to happen between a request needing sign-off and the decision being acted on.

  1. 1

    The request is matched to a rule

    By type and amount, against the approval table, which names the approver or approvers.

  2. 2

    The approver's availability is checked

    Leave and delegation from the HR system, so a request never goes to somebody who is away.

  3. 3

    The approver gets the request with its facts

    In Slack or Teams, with the amount, the reason, the history and a link to the record.

  4. 4

    They approve, reject or ask a question

    In the same message, without logging in anywhere else.

  5. 5

    The deadline escalates anything left waiting

    To a delegate or the next level, with the original approver told.

  6. 6

    The decision is recorded and acted on

    Written to the system of record, and the next step of the process runs.

What approval routing is made of

Four pieces, and the first is the one that keeps the rest changeable.

An approval table

Request type, amount band, approver role and order, held as data. When the limits change, someone edits a row, and the change is itself on record.

Requests that carry their own facts

The amount, the reason, the customer or supplier, previous approvals for the same account, and a link to the source record. Enough to decide without opening anything else.

Deadlines with escalation

Each step has a time limit. When it passes, the request moves to a delegate or up a level, and the waiting approver is told why.

A decision record

Who approved, what they were shown, when, and through which channel. Kept with the request, not reconstructed later from chat history.

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

    Hold the approval rules as data

    The limits change more often than the workflow should.

    Headless skills build-workflow 

    Use build-workflow. The systems in play are Salesforce, NetSuite, Slack
and Workday, or whatever we run in those seats.

Build an approval table: request type, amount band, approver role,
order (one after another or at the same time), and the deadline for
each step. Store it where finance can edit it, and log every change to
it with who made it.

Resolve the approver role to a person at the moment of routing, from
Workday, rather than naming people in the table. People move; roles
stay.

If a request matches no rule, send it to the process owner. Never
approve it by default.
  2. 2

    Check availability and delegation before routing

    A request sent to someone on leave waits for their return.

    Headless skills build-workflow tray-patterns 

    Use build-workflow. Before sending a request, check the approver's
leave in Workday and any delegation they have set. If they are away,
route to their delegate, and if there is none, to the next level up.

Never let the requester be the approver, including through a
delegation that points back to them. Route those to the next level.

Tell the original approver what was routed around them when they
return.
  3. 3

    Send the request with everything needed to decide

    An approver who has to look something up decides later.

    Send each approval to Slack (or Teams, for people who work there) as
one message with:

  The amount and what it is for
  The requester and their reason
  The customer or supplier, and recent approvals for them
  Which rule triggered the approval, and why it needs this person
  Approve, reject and ask-a-question buttons, and a link to the record

Keep the message short enough to read on a phone. If the approver asks
a question, send it to the requester and keep the approval open with
its deadline paused.
  4. 4

    Escalate at the deadline instead of waiting

    Waiting forever is a decision nobody made.

    Headless skills tray-gotchas 

    Use tray-gotchas, then give every approval step its deadline from the
table. When the deadline passes, remind the approver once, then move
the request to their delegate or the next level, and post in the
thread who it went to and why.

If the request has a hard date (a customer refund promised by Friday,
a supplier payment term), show it in the request and escalate earlier
when it is close.

Never let a request sit with no one able to act on it. A request with
no possible approver goes to the process owner with an alert.
  5. 5

    Record the decision and act on it

    The record is what the auditor asks for.

    When a decision is made, write it to the source record in Salesforce or
NetSuite: who decided, when, what they were shown, and through which
channel. Then run the next step of the process, the credit memo, the
purchase order or the discount on the quote.

Keep a copy of every decision in Snowflake, so you can report time to
decision by request type and approver, and show an auditor every
approval above a threshold in one query.
  6. 6

    Validate it, then hand the table to finance

    Because approval limits are finance's to change.

    Run the per-step checks and the whole-workflow audit before this goes
live. Test a request in each amount band, one whose approver is on
leave, one where the requester would approve their own request, one
that hits its deadline, and one that matches no rule.

Then open the same workflow in Tray Build so finance can change the
approval table, the deadlines and the message wording in the visual
canvas without a deployment.

What it connects to

The request starts in a system of record, the decision happens where people already work, and the result goes back to where it started.

Salesforce

Raise discount and refund requests, and receive the decision on the quote or the case.

Reads and writes

NetSuite

Raise spend and credit requests, and act on the approval with the purchase order or credit memo.

Reads and writes

Workday

Resolve each approver role to a person, and supply leave and delegation.

Reads

Slack

Put each request in front of its approver with the facts and the buttons to decide.

Reads and writes

Microsoft Teams

Do the same for approvers who work in Teams.

Reads and writes

Snowflake

Hold every decision, which is where time to decision and audit questions get answered.

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 Microsoft Dynamics 365, SAP S/4HANA, Google BigQuery, Google Chat, SAP SuccessFactors or HubSpot.

Connections in this build

Field mapping, templates and common problems for each pairing: NetSuite + Salesforce, Workday REST + Salesforce, NetSuite + Workday REST and Salesforce + Slack.

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 is a control. If it stops, money moves without sign-off or does not move at all.

It runs on the platform, not on your laptop

Deadlines run around the clock, and an escalation that only fires during office hours is a deadline that is wrong at weekends.

The table is the control

Changes to it are logged with who made them, so the approval limits in force on any date can be shown.

Credentials are managed, never in code

Read access to the HR system for leave and reporting lines, and write access only to the fields the decision updates.

Nobody approves their own request

Checked at routing time, including through delegation, rather than trusted to the approver.

Finance owns the limits

The table, the deadlines and the wording, all open in Tray Build and changed without a deployment.

Questions people ask

Why keep the rules as data?

Because approval limits change, and a change has to be on record. Editing a row in a table is quick and logged; editing conditions in a workflow is neither.

Can people approve from Slack or Teams?

Yes. The request arrives as a message with the facts and approve, reject and question buttons, and the decision is written back to the system of record.

What happens when an approver is away?

Their leave and delegation are checked before routing, so the request goes to the delegate or the next level from the start, and they are told what was routed around them.

How is this different from access request and approval?

That guide covers access to systems, with expiry and review built in. This covers any request that needs sign-off: discounts, refunds, spend, credits and exceptions.

Which metric matters most?

Time to decision, by request type and approver. It shows where requests wait, and whether the wait is a rule, a person or missing facts.

Related guides

IT and security

How to automate request intake forms

Capture each request once with the fields the decision needs, check it against the systems that already know, and route it to an owner. The prompts.

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.

AI operations

How to build human approval for agent actions

Decide what needs approving by blast radius, show the approver what will happen, expire cleanly, and keep the record. The Headless prompts that build it.

Last reviewed October 2026.