How to Build a Multi-Stage Approval Workflow in Airtable

Approvals are the hidden operating system of most businesses. Purchase orders, expense reports, content drafts, legal contracts, vacation requests, vendor onboarding — every one of these passes through a chain of people who need to sign off before the work moves forward. And every one of them is usually implemented as "email the right person and hope they respond."

Airtable handles approval workflows better than any general-purpose tool we've worked with. The combination of status fields, collaborator fields, automations, and Interface Designer gives you everything you need to build an approval process that sends notifications automatically, captures decisions with a full audit trail, and moves records through multiple stages without anyone having to ask "where is this in the queue?"

This guide walks through building a production-ready approval workflow in Airtable, from a simple single-stage approval all the way to a multi-stage manager → finance → legal chain. Every pattern is drawn from real client implementations.

The Anatomy of an Airtable Approval Workflow

Every approval workflow in Airtable boils down to five components:

1. A status field that tracks where the record is in the approval process.
2. An approver field that identifies who is responsible for the current decision.
3. A notification automation that pings the approver when action is needed.
4. A decision interface or action where the approver approves or rejects.
5. An audit trail that records who approved what and when.

Everything else is variation on these five pieces. Single-stage approvals use them once. Multi-stage approvals chain them together.

Step 1: Set Up the Fields

Start with your base table — whatever you're approving (Purchase Orders, Expense Reports, Content Drafts, etc.). Add these fields:

Status (Single Select). The core state machine. For a simple one-stage approval, the options are: Draft, Pending Approval, Approved, Rejected. Color them meaningfully — grey for Draft, yellow for Pending, green for Approved, red for Rejected. Good colors aren't decoration; they make the status visible at a glance in any grid view.

Approver (Collaborator). A single-collaborator field for the person who needs to make the decision. This can be assigned manually, auto-assigned based on other fields (more on that below), or pulled from a linked record.

Submitted By (Collaborator or Created By). Who requested the approval. Useful for notifications and the audit trail.

Submitted At (Date / Last Modified Time). When the request was submitted. Use a Last Modified Time field configured to track changes to the Status field.

Approved/Rejected By (Collaborator). Populated by the automation when the decision is made. Not manually editable.

Approved/Rejected At (Date/Time). Populated by the automation when the decision is made.

Decision Notes (Long Text). A place for the approver to write why they approved or rejected, especially useful for rejections that need context for the submitter.

These seven fields are the minimum viable approval tracking. You'll probably add more specific to your use case (amount, category, due date, etc.), but these are what drives the workflow itself.

Step 2: Build the Notification Automation

When a record enters Pending Approval, the approver should know immediately. Airtable automations handle this natively.

Trigger: When a record matches conditions — Status is Pending Approval.

Action: Send email (or Slack message).

In the email or Slack message:

• Subject: Clear and specific. "Approval needed: Purchase Order #{Record Name}" is dramatically better than "New record requires approval."
• Body: Key details the approver needs to make the decision — amount, requester, purpose, date — followed by a direct link to the record.
• The link: construct the record URL manually (e.g. "https://airtable.com/" & BASE_ID & "/" & TABLE_ID & "/" & RECORD_ID()) or insert it from the automation step. Never make the approver search for the record.

For Slack specifically, include a short preview of the record fields in the message so the approver doesn't even have to click through for routine decisions. They can approve with a reply, and a secondary automation can update the status based on the reply content.

For multi-approver scenarios: you can send to multiple people, or use conditional logic in the automation to pick the right approver based on record fields (amount brackets, department, category). This is where approval workflows start feeling like real enterprise systems.

Step 3: Build the Approval Interface

The approver needs a fast, clear way to approve or reject. The best pattern is a dedicated Interface Designer page.

Create a new interface page called "Approvals Queue."

Configure it with:

• A filter scoping to records where Status = Pending Approval AND Approver = logged-in user. This gives each approver a personalized queue.
• A list view at the top showing all records waiting for their decision.
• A detail panel that opens when a record is clicked, showing all the context fields the approver needs.
• Two action buttons: Approve and Reject. Each triggers an Airtable automation that updates the status, populates Approved/Rejected By and Approved/Rejected At, and captures the decision notes.

The button actions are the key magic. In Interface Designer, you can configure a button to run an Airtable automation when clicked. The automation does the work; the button provides the UX.

Bonus: add a "Request More Info" button that moves the record to a Needs Clarification status and notifies the submitter. Approvers love this because it gives them an alternative to just rejecting something with incomplete information.

Step 4: Build the Audit Trail

A single approval field that says "Approved By" is enough for simple cases. For anything that might be audited or reviewed later, build a proper audit trail with a linked Approvals table.

Create a new table called "Approval History."

Fields:

• Record (Linked Record back to the main table) — which record was approved or rejected.
• Stage (Single Select) — which stage of the approval this decision was for (relevant in multi-stage workflows).
• Decision (Single Select: Approved, Rejected, More Info Requested) — the decision made.
• Decision By (Collaborator) — who made it.
• Decision At (Date/Time) — when.
• Notes (Long Text) — any comments.

Create an automation with a trigger: "When a record's Status changes to Approved, Rejected, or Needs Clarification." The action creates a new row in Approval History with the details.

The result is a complete, queryable history of every approval decision — who, what, when, why, at which stage. This is exactly what auditors, compliance reviewers, and curious managers want when they ask "what happened to that PO?"

Step 5: Scale Up to Multi-Stage

Single-stage approvals are straightforward. Multi-stage approvals — manager → finance → legal, or any sequence — need a slightly richer state machine but the same underlying components.

Expand your Status field options:

• Draft
• Pending Manager Approval
• Pending Finance Approval
• Pending Legal Approval
• Approved
• Rejected

Add per-stage approver fields:

• Manager Approver
• Finance Approver
• Legal Approver

These can be populated automatically based on rules — for example, the Manager Approver is always the requester's direct manager (from a linked HR table), the Finance Approver depends on the amount, and the Legal Approver is a fixed collaborator.

Build per-stage notification automations:

Each automation triggers when the Status enters its specific stage and notifies the corresponding approver. You end up with three nearly-identical automations, one per stage.

Build the stage-transition automation:

When a record at Pending Manager Approval is approved, the next automation moves it to Pending Finance Approval (or skips directly to Approved if the amount is under the finance threshold). When it's approved at finance, it moves to Pending Legal Approval. When it's approved at legal, it moves to Approved.

Rejection at any stage moves the record directly to Rejected with the stage captured in the audit trail.

The mental model: your status field is a state machine, and each automation is a transition. Draw the state diagram on paper before you build — it takes ten minutes and prevents an hour of debugging later.

Step 6: Handle Edge Cases

Real approval workflows have messy edges. Here's how we handle the common ones.

Approvers who are out of the office. Add a backup approver field that gets notified if the primary hasn't responded within a set time. An Airtable automation can check "is the record still pending after 24 hours?" and send a reminder or escalate.

Bulk approvals. For approvers who need to approve many records at once, add a view called "Ready for Batch Approval" and a bulk-update action in Interface Designer that marks all selected records as approved in one click. Still logs each decision individually in the audit trail.

Conditional skipping. Some records should skip certain stages based on rules — for example, expenses under $500 skip the finance review. Build this into the stage-transition automation with IF logic: if the amount is below the threshold, skip directly to the next stage.

Revisions and resubmissions. When something is rejected with a "please fix X," the submitter needs a way to address the feedback and resubmit. Add a Returned for Revision status that's distinct from Rejected, and allow the submitter to edit and move the record back to Pending Manager Approval. The audit trail captures the full history of revisions.

Delegation. Sometimes an approver needs to delegate a specific decision to someone else. Add a "Delegate Approval" button that prompts for a collaborator and updates the Approver field to that person, logging the delegation in the audit trail.

A Real Example: Marketing Content Approval

A real client setup we shipped recently. A marketing agency needed approval on every piece of content before it went live. Three stages: Copywriter → Account Manager → Client.

Base structure:

• Content table with fields for title, type, body, assigned copywriter, account manager, client, and status.
• Clients table linked to content records.
• Approval History table for the audit trail.

Workflow:

1. Copywriter creates a new content record, fills in the body, and changes status from Draft to Pending AM Review.
2. Automation notifies the account manager via Slack.
3. Account manager opens the Approvals interface, reviews the content, and either approves (moves to Pending Client Review) or requests revisions (back to the copywriter with a Returned for Revision status and notes).
4. On AM approval, automation notifies the client via email with a read-only view link to the content.
5. Client approves or rejects in a simple client-facing interface (built in Softr to avoid giving them Airtable access).
6. Final approval moves the status to Approved and triggers a separate publishing automation that pushes the content to the marketing team's workflow.

Total build time: about six hours. Total time saved per week across the client portfolio: probably 10 hours of account manager time chasing approvals. Payback in one week.

Common Mistakes to Avoid

Using email notifications alone. Slack or interface-based approvals get dramatically faster response times than email. People live in Slack; they ignore email.

No timeout handling. If a record can sit in Pending Approval forever without anyone noticing, you don't have an approval workflow, you have a waiting room. Always build reminders and escalation.

Approvers who can't see the context. If the approver has to click three links and open two tabs to understand what they're approving, they'll either take forever or rubber-stamp everything. Build the interface so all the context is visible on one screen.

Skipping the audit trail. The audit trail is the difference between an approval workflow and "we changed some statuses sometimes." It's not optional for anything that touches money, legal, or compliance.

Too many stages. Every stage adds friction and delay. Five stages is usually too many. Three is usually plenty. Ask whether each stage really needs to happen, or whether you're just codifying bureaucracy that the business doesn't need.

What Comes Next

Once you have a working approval workflow, the natural next step is to feed the approval data into client reporting dashboards so leadership can see where things are stuck, and to connect the approval actions to downstream systems — generating invoices when expenses are approved, creating tasks when contracts are signed, notifying clients when content is live. Airtable automations handle all of these natively.

If your approval logic has gotten so complex that nested IFs in automations aren't keeping up, take a look at our IF statements complete guide and our SWITCH guide for patterns that keep the logic maintainable.

Build It Right the First Time

Approval workflows are one of those systems that look simple until you try to build them properly. The first version always works; the seventh edge case is where it starts falling apart. At Business Automated, we've built approval workflows for agencies, finance teams, and operations teams across dozens of engagements. We know the patterns that hold up and the gotchas that bite most first-time builders.

If your team needs an approval workflow that scales past "email the right person and hope," get in touch. We'll design the state machine, build the automations, and leave you with a system your auditors will actually like.