Airtable Approval Workflows: Multi-Step Sign-Off, Escalation, and an Audit Trail

Approvals are where most Airtable operations bases quietly fall apart. A single Approved? checkbox works until someone asks who ticked it, when, on what version of the number, and what happens when that person is on holiday. This tutorial builds a proper approval workflow in Airtable: a status machine instead of a checkbox, multi-step sign-off with thresholds, escalation on delay, and an append-only audit trail you can hand to a finance lead or an auditor.

We will use purchase requests as the example, but the same shape fits contract sign-off, content approval, expense claims, discount requests, and change requests.

What you need

• A base with an Approvals table (we will call records "requests").
• A People table holding approvers, with an Email field and a Manager self-link.
• Editor permission and the ability to create automations and interfaces.

Step 1: model the request

Fields on Approvals:

• Request ID: autonumber or formula, so humans can quote it.
• Requester: link to People.
• Amount: currency.
• Category: single select.
• Justification: long text.
• Status: single select — Draft, Submitted, Manager review, Finance review, Approved, Rejected, Withdrawn.
• Current approver: link to People.
• Submitted at, Decided at: date with time.
• Decision note: long text.

Two rules make this robust. First, the status options are the only states the record may be in; no free text. Second, Current approver is a real link, not a name typed in, so automations and interface filters can use it and so you can roll up "open approvals per person".

Step 2: decide the routing rules before you build anything

Write the policy down in one paragraph and get it agreed. For example:

Requests under £1,000 need the requester's manager only. £1,000–£10,000 need manager then finance. Over £10,000 need manager, finance, and a director. Anything in category Software also needs IT regardless of amount.

Now encode the threshold in a formula field, Required steps:

IF(
  {Amount} >= 10000, "Manager,Finance,Director",
  IF({Amount} >= 1000, "Manager,Finance", "Manager")
)

Keeping the policy in one formula field rather than scattered across five automation conditions is the difference between a workflow you can change in a minute and one you have to reverse-engineer next year. When finance moves the threshold, you edit one formula.

Step 3: submission

Give requesters an Interface Designer form or a record-review page filtered to their own drafts, not the raw grid. The submit action sets Status to Submitted; everything after that is automation.

Automation 1 — Route on submit:

• Trigger: When record matches conditions — Status is Submitted.
• Action: Find records in People where the requester's manager matches, or read the requester's Manager link directly via a lookup field Requester manager.
• Action: Update record — set Current approver to the manager, Status to Manager review, Submitted at to now.
• Action: Send email (or Slack/Teams message) to the approver with the request details and a link to the approval interface.

Add a lookup field Requester manager on Approvals so the automation does not need a search step. Lookups are free and instant; find-record steps are neither.

Step 4: the decision, without giving everyone edit rights on the grid

Approvers should not be browsing the table. Build one Interface Designer page, My approvals, with a record list filtered to Current approver is current user, and buttons for Approve and Reject that write to a helper field, Decision, a single select with Approve / Reject, plus Decision note.

That filter — "current user" — is what makes a single interface page work for thirty approvers. Combine it with interface-level permissions so approvers cannot open the underlying base. If your plan does not offer the granularity you need, see our notes on client portals and external interfaces for the sharing model.

Automation 2 — Advance the chain:

• Trigger: When record updated — watch the Decision field.
• Condition: Decision is Reject → set Status to Rejected, Decided at now, clear Current approver, notify the requester. Stop.
• Condition: Decision is Approve → work out the next step from Required steps and the current Status:
  • Manager review and Required steps contains Finance → set Status to Finance review, Current approver to the finance approver.
  • Finance review and Required steps contains Director → set Status to Director review.
  • Otherwise → Status is Approved, Decided at now, clear Current approver.
• Final action in every branch: clear Decision so the field is ready for the next approver, and write an audit row (next step).

Clearing the helper field is easy to forget and causes the classic bug where the second approver sees the first approver's decision already filled in.

Step 5: the audit trail

Revision history exists, but it is not an audit trail: it is hard to filter, it is not reportable, and on lower plans it ages out. Build an explicit Approval events table:

• Request: link to Approvals.
• Event: single select — Submitted, Approved, Rejected, Escalated, Reassigned, Withdrawn.
• Actor: link to People.
• From status, To status: single line text.
• Amount at decision: currency, copied at write time.
• Note: long text.
• Timestamp: created time.

Every automation branch creates one row here and never updates one. Append-only is the whole point: if a row can be edited, it proves nothing. Copying Amount at decision matters too — if someone edits the amount after approval, the trail still shows what was actually approved, and a rollup comparing the current Amount against the last approved amount gives you a "changed after approval" flag worth alerting on.

Step 6: escalation and cover

Approvals stall. Two automations fix most of it.

Reminder and escalation — a scheduled automation running each weekday morning:

• Find records where Status ends in review and Submitted at is more than 2 days ago and Escalated is unchecked.
• Send a reminder to Current approver; if the wait is more than 5 days, set Current approver to that person's manager, tick Escalated, and write an Escalated audit row.

Delegation — an Out of office until date on People, and a routing step that checks it before assigning. If the chosen approver is away, assign their manager or a named delegate and log a Reassigned event. Without this, one holiday backs the whole queue up.

Use a Days waiting formula (DATETIME_DIFF(NOW(), {Submitted at}, 'days')) for the views, and remember NOW() refreshes periodically rather than instantly — fine for daily SLA work, not for anything needing second-level precision.

Step 7: reporting that finance will actually ask for

Three views and one dashboard cover the usual questions:

• Open approvals by approver — grouped by Current approver, sorted by Days waiting descending. This is the bottleneck report.
• Approved this month — filtered on Status is Approved and Decided at is within this month, summed by Amount and grouped by Category.
• Cycle time — a formula DATETIME_DIFF({Decided at}, {Submitted at}, 'hours'), averaged per approver and per step.

Cycle time per step is the number that changes behaviour. It usually shows that one step — often the one nobody agreed was necessary — accounts for most of the delay, which is the evidence you need to remove it.

Common mistakes

A checkbox instead of a status. Checkboxes cannot express "waiting on finance", cannot be escalated, and cannot be reported on.

Approver names typed as text. You lose per-person rollups, current-user filters, and delegation.

Automations that fire on every field change. Trigger on the specific field or on "record matches conditions" with a tight condition, or your approval chain will advance because someone fixed a typo in the justification. Our guide to automations that fail silently covers the monitoring side.

Letting approved records stay editable. Lock them down with a view that approvers use and an automation that flags post-approval edits to Amount or Category.

Treating Airtable as the system of record for regulated sign-off without checking the requirement. If your auditors need immutable, independently timestamped logs and enforced segregation of duties, confirm what Airtable's plan-level controls and admin audit logs give you before you commit. See Airtable security and compliance for how we scope that.

Where to go next

Once the chain works for one process, generalise it: the same status machine, event table, and escalation pattern handle contract sign-off and change requests with nothing more than different fields on the request table. Keep the policy in one formula, the history in an append-only table, and the humans in an interface rather than the grid.

BaseBrainers builds approval and operations workflows on Airtable, including the governance and audit design around them — see Airtable for business operations or get in touch with the process you are trying to tame.