Short answer
Automating a simple approval workflow means routing a request, such as a purchase, to the right person and recording their decision without anyone chasing emails. The reliable method is to write the rule as a decision table, test it on paper against edge cases, then build it in a tool such as Power Automate, Zapier, Make or n8n. AI can extract and summarise the request; a person still approves.
- Write the approval rule as a decision table before opening any automation tool.
- Ask AI for edge cases: exact thresholds, GST, split orders, self-approval, leave.
- Use approve and reject buttons, never free-text replies, to record decisions.
- Show the approver the original document beside any AI-extracted amount.
- Every action step can count toward plan limits, so estimate usage first.
Goal: Design, test on paper, and then build a purchase approval flow in which AI prepares the request and a named person makes the decision. Who it is for: Office managers, finance administrators and operations staff who chase approvals by email, and anyone building their first automation. Time: 45 minutes for the design and paper test, plus extra time if you build it the same day in your automation tool.
Most broken approval flows were built in the automation tool first and thought about second. The flow runs for a week, then a request arrives for exactly $500, or one quoted including GST, or from the manager who is supposed to approve it. Nobody decided what should happen, so the tool decides by accident. AI is genuinely useful here, but mostly before the build: it is very good at finding the cases you did not think of.
How a simple approval workflow fits together
A simple approval workflow has five parts: a request comes in, the details are captured, a rule picks the approver, the approver decides, and the decision is recorded and acted on. AI belongs in the capture step, not the decision.
| Part | Plain automation | Where AI helps | Who decides |
|---|---|---|---|
| Request | A form or shared inbox | Reading a forwarded quote or free-text email | Requester |
| Capture | Form fields | Extracting supplier, amount, GST and cost centre | Nobody yet |
| Route | Decision table | None needed | The rule |
| Decide | Approve and reject buttons | A one-line summary for the approver | Named approver |
| Record and act | Log row, notification, purchase order | None needed | The system |
Exercise: design and paper-test a purchase approval
- Write the rule in plain words. Write it as you would explain it to a new staff member, including who approves at each level.
- Turn it into a decision table. Paste the rule into ChatGPT, Claude, Copilot or Gemini and ask for a decision table plus a list of ambiguities, using the worked example prompt.
- Resolve every ambiguity. Decide each one with whoever owns the policy, and update the rule. GST and exact thresholds always come up.
- Generate test cases. Ask for at least 12 test cases with expected outcomes, including boundaries, split orders, self-approval, leave and missing information.
- Run a tabletop test. With a colleague, walk each case through the table by hand. Any case where you disagree on the outcome means the rule is still unclear.
- Decide the failure paths. Write down what happens on no response, rejection, a duplicate request and an extraction you cannot read.
- Build the simplest version. In Power Automate, Zapier, Make or n8n: form, optional AI extraction step, routing, an approval with buttons, a log row and a notification. Run all 12 test cases through it before going live.
Worked example: a contractor’s parts purchases
Illustrative example: a 40-person Palmerston North agricultural contractor that buys machinery parts and repairs during a busy season. The business and rule are fictional.
Our purchase approval rule: "Purchases under $500 just get logged.
$500 to $5,000 need the operations manager. Over $5,000 needs a
director. New suppliers always need finance to set them up first."
1. Turn this into a decision table.
2. List every ambiguity or gap a new staff member could trip over.
3. Write 12 test cases with the expected outcome for each. Include
boundary amounts, GST-inclusive amounts, split orders, a requester
who is also the approver, an approver on leave and missing details.
Do not resolve ambiguities yourself; list them for me to decide.
Example output (illustrative, abridged):
Ambiguities to decide
- Are thresholds GST inclusive or exclusive?
- Does exactly $500 or exactly $5,000 fall in the lower or higher band?
- Two orders of $400 from one supplier on the same day: one purchase
or two?
- Who approves when the operations manager is the requester?
- Is there an emergency rule for breakdowns during harvest?
Test cases (first five)
1. $499.00 excl GST, existing supplier -> log only
2. $500.00 excl GST, existing supplier -> depends on boundary rule
3. $575.00 incl GST ($500.00 excl) -> depends on GST rule
4. Ops manager requests $2,000 -> director (no self-approval)
5. $120 from a new supplier -> finance setup first
Case 3 is the one that breaks most real flows. A quote of $575 including GST is $500 excluding it, so the same purchase lands in different bands depending on which figure the form captures. Decide once, label the form field, and make any AI extraction step return the GST-exclusive amount with the original quote attached.
Where approval automations go wrong
- Free-text replies. Parsing “ok”, “not ok” or “ok but check the freight” from an email reply is unreliable. Use approve and reject buttons in Teams, Slack, email or the tool’s own app.
- Extraction errors. An AI step can misread an amount, miss GST or pick the wrong supplier. Show the approver the extracted fields beside the original document, and reject amounts that fail a format check.
- Waiting forever. Approvals stall when someone is away. Build reminders and escalation to a named alternate, and check how long your tool can wait on a step. Never approve by default on timeout.
- Self-approval and split orders. Both are classic controls in purchasing. Put them in the decision table, not in someone’s memory.
- No audit trail. Log every request, decision, approver and time in one place you can search later.
- Plan limits. Zapier counts a task as any successful action, and its Free plan included 100 tasks a month as listed on 19 October 2026. Forty requests a month through a four-action flow already uses 160. Estimate before you choose a plan.
The decision table is the specification from the previous lesson, writing a workflow specification, applied to one step. For tool choice, see our guides to Zapier, n8n and Make, and AI and Microsoft Teams if approvals will happen there. When review volumes grow, the patterns in human review queues apply. If you are unsure whether a flow needs AI at all, read when a workflow does not need an agent. Larger or cross-system approval flows are part of our AI workflow automation work.
Self-check
- The rule is written as a decision table with no unresolved ambiguities.
- GST treatment and exact threshold boundaries are stated.
- Self-approval, split orders and approver absence have explicit rules.
- At least 12 test cases passed both the paper test and the built flow.
- Approvers decide with buttons and can see the original document.
- Every decision is logged with who approved and when.
- Expected monthly usage fits the plan you chose.
Next lesson: Connecting AI to your CRM.
Sources
- How is task usage measured in Zapier?, Zapier, as listed 19 October 2026
- Zapier pricing, Zapier, as listed 19 October 2026
Written by the Levy Street team in Wellington. Last updated 19 October 2026.