How to Automate Airtable with Make: The Complete Guide

Airtable's native automations cover the simple cases — when a record changes, do one or two things. The moment your workflow needs to talk to a service outside Airtable's small list of integrations, or branch in three directions, or process a batch of records, you need a real automation platform. For us, that's Make.

This guide walks you from your first Make scenario to production-ready workflows. We'll cover triggers, the most useful modules, branching with routers, processing batches with iterators, and the error-handling patterns that keep scenarios working when reality gets messy.

Why Make for Airtable

Airtable and Make are unusually well-matched. Airtable is the source of truth — clean, structured data. Make is the action layer — every workflow that moves that data, transforms it, or syncs it with another system. A handful of reasons we default to Make on most client projects:

• The visual canvas stays readable as scenarios grow. A 12-step scenario with a router and an iterator is still understandable at a glance. The same workflow in code or another tool gets messy fast.
• Operations-based pricing scales predictably. Each module run is one operation. You can model the cost before you build.
• Built-in tools for the hard parts. Routers for branching, iterators for batches, aggregators for rolling results back up, error handlers, schedule controls, and a long history of every run.
• Three thousand app integrations. Most business tools are already supported. The ones that aren't usually have a REST API you can call with the HTTP module.

For when Zapier makes more sense, we have a separate comparison.

Concepts You Need First

A few terms used throughout the rest of this guide.

Pricing on Make is per operation, not per scenario. A scenario that processes 20 records through 5 modules runs 100 operations. Keep this in mind as you design — adding a needless module to a scenario that runs thousands of times a month adds up.

Connecting Airtable to Make

Before you can build anything, Make needs access to your Airtable workspace.

1. In Make, open Connections under your profile and click Add.
2. Choose Airtable.
3. Select Airtable (OAuth) as the connection type. This is more secure than the older Personal Access Token method.
4. Approve the workspace access in the Airtable popup. Grant access only to the bases this connection should touch — not your whole workspace.
5. Name the connection something descriptive (e.g. Airtable — Client X production).

You only do this once per workspace. Every scenario after that reuses the same connection.

For the official module reference, see Make's Airtable modules documentation.

The Five Airtable Modules You'll Use Most

Make has more Airtable modules than this, but you can build 90% of real workflows with these five.

Watch Records (Trigger)

Watches a base/table/view and returns new or updated records. The most common trigger. Configure:

• Base, table, view. Pick the source. Use a view rather than the full table — it filters records to only the ones that should trigger the scenario, and it costs you nothing extra in operations.
• Trigger field. Either Created Time or a Last Modified Time field on the table. If you want updates to trigger the scenario (not just new records), use Last Modified Time.
• Max records per run. Default 10. Bump this up if the scenario can keep up with bigger batches.
• Polling schedule. How often Make checks Airtable. Every 15 minutes on free, every minute on paid plans.

Tip: create a dedicated Make Trigger view on the table with filter conditions for exactly the records you want to act on. Once Make has acted on a record, the scenario updates a field that removes the record from the view, so it never triggers twice.

Search Records

Looks up records in any table by a formula. Use it to find related records that aren't directly linked, to dedupe by a unique field like email, or to fetch configuration data stored in a settings table.

A common pattern: a new lead comes in. Search Records looks for an existing Contact with the same email. If found, update it. If not, create a new one. This is how you avoid creating duplicates.

Get a Record

Pulls a single record by ID. Use it after a router or iterator when you only have an ID and need the full record's fields. Cheaper than a Search Records when you already know the exact record.

Create a Record

Adds a new record. Pass in field values from earlier modules.

For linked record fields, you have to pass an array of record IDs, not names. The most common error in early scenarios is putting Client Name into a linked field instead of the client's record ID — the field stays blank with no obvious error. Use a Search Records to find the ID first, then pass it to Create a Record.

Update a Record

Updates an existing record by ID. Same field rules as Create. Only the fields you map get updated — anything you leave blank keeps its existing value.

Branching with Routers

A router takes one input and sends it down one of many paths based on filter conditions. Use it whenever your scenario needs to do different things in different cases.

Example: a new deal record comes in. You want to:

• Create a Stripe customer if the deal value is over $5,000
• Send a "qualification" email if the value is $500–$5,000
• Mark it as low-priority and move on if it's under $500

Build it with a Router right after the Watch Records trigger. Each path has a filter — Path 1: {{1.Value}} > 5000, Path 2: 500 <= {{1.Value}} <= 5000, Path 3: {{1.Value}} < 500. Each path has its own chain of modules afterward.

Two rules to keep routers manageable:

1. Use mutually exclusive filters. If two paths could match the same bundle, both will run — that's usually not what you want. Set filters so exactly one path matches per bundle.
2. Always include a fallback path. Make sets the last unfiltered path as the fallback. If your filters miss a case, the fallback catches it instead of silently dropping data.

Processing Batches with Iterators

When a module returns multiple items in one bundle — like a Search Records that finds five invoices — downstream modules only see the first one unless you split the bundle. That's the Iterator's job.

Insert an Iterator module right after the bundle-producing module. Point it at the array field (e.g. {{2.records}} from Search Records). After the Iterator, the scenario runs once per item.

Example workflow: every Monday morning at 8am, find all overdue invoices, send each one a follow-up email.

1. Schedule trigger (every Monday 8am)
2. Airtable Search Records — find all invoices where Status = "Overdue"
3. Iterator — split records into individual bundles
4. Email Send — one email per record

Without the iterator, only the first overdue invoice would get an email. With it, every overdue invoice does.

For more on iterators and aggregators in real workflows, see Make's official Using Airtable with Make tutorial.

Five Practical Scenarios

1. New Lead to CRM

Trigger: New row in a typeform/webflow/Calendly. Steps: Search Airtable Contacts by email. If found, update Last Contact field. If not, create new Contact, post to Slack #sales channel, send a welcome email via Gmail. Why Make: The dedupe-by-email pattern needs a Search Records and a Router. Native Airtable can't easily do this from an external trigger.

2. Invoice Generation from Approved Quote

Trigger: Airtable Watch Records on Quotes table, view = "Approved Quotes Awaiting Invoice." Steps: Search Records on Line Items for items linked to the quote. Iterator splits line items. Create Stripe invoice with each line item. Update the quote record with the invoice ID and link. Why Make: Multi-step, requires iteration, talks to two external systems (Stripe and Airtable).

3. Daily Project Status Digest

Trigger: Schedule (every weekday at 8am). Steps: Search Records for all active projects. Iterator splits projects. For each, compose a summary using fields. Aggregator collects all summaries. Send one combined Slack message to the team channel. Why Make: Aggregator pattern (split → process → recombine) is unique to Make.

4. Inventory Reorder Alert

Trigger: Airtable Watch Records on Products, view = "Below Reorder Threshold." Steps: Search Records on Suppliers linked to the product. Email the supplier contact with quantity needed. Create a Purchase Order record in Airtable. Slack a notification to ops. Why Make: Touches three actions in different systems based on one trigger.

5. Form to Custom Onboarding

Trigger: Airtable form submission (via webhook from native automation). Steps: Router branches on client size. For each branch, create a different set of tasks in the Tasks table. Send a tailored welcome email. Generate a folder in Google Drive. Add the client to a Softr portal user table. Why Make: Heavy branching + multiple external systems.

For the client onboarding scenario in detail, see our client onboarding automation guide.

Error Handling You Should Always Add

A scenario that works in your test data will fail in production. APIs go down, fields go blank, edge cases show up. Spend an extra ten minutes setting up error handling and you'll save hours of debugging later.

The minimum we add to every production scenario:

1. An Errors table in Airtable with fields for scenario name, module that failed, error message, the bundle data, and timestamp.
2. Error handlers on every external API call. Right-click the module, Add Error Handler, choose Resume. Route the error path to a Create Record in the Errors table.
3. A Slack notification when a new error record is created (via a separate scenario or Airtable automation). High signal, low noise — you only hear about real failures.
4. Retry logic on flaky APIs. Use the Break error handler with retry enabled — Make will wait and try again automatically.

Without this, your first sign that something is wrong is a customer complaint. With it, you find out within minutes and you have the data you need to fix it.

Pricing and Operations Budget

Make charges per operation. Each module execution on each bundle is one op. A scenario with five modules processing 100 records per day uses 500 ops a day, 15,000 a month.

Plans in 2026:

You can upgrade operations within a plan as you grow. Most small businesses fit in Pro. Mid-sized agencies typically need Teams or Enterprise for the shared workspace and history retention.

To save operations:

• Use views, not full tables, on Watch Records
• Add filter conditions inside scenarios so trivial bundles exit early
• Combine related actions where possible (a single Update Record with five fields beats five separate updates)
• Disable scenarios that aren't currently in use

When Not to Use Make

Make is excellent but it's not always the answer. Skip it when:

• The workflow is fully internal to Airtable and uses only fields Airtable can change — native automations are simpler and free.
• The integration only exists in Zapier — use Zapier for that piece.
• The workflow runs millions of operations a month — at that scale, a custom backend is usually cheaper than Make.
• The logic is so complex it needs tests and version control — push it into code.

For most everything in between, Make is the tool to reach for.

Where to Go Next

If you haven't already, read our Airtable Automation Guide — it covers the native side of the same workflows and helps you decide what stays in Airtable vs what moves to Make. For specific patterns we use on real client projects, the client onboarding automation and Xero invoice integration walkthroughs both run on Make.

Make's official Airtable integration page lists every available module with current limits and update history.