What is Airtable automation?

Airtable automation is a native, base-scoped builder that runs fixed actions when a trigger fires, like updating a record or posting to Slack when a status changes. It suits simple in-base rules. For work that needs judgment, an agent on the Airtable Web API can enrich, validate and route each record, and Major turns that logic into a deterministic app.

Can Airtable automations use AI?

Yes. The Generate with AI action runs a model inside an automation step and returns text or structured data from your prompt. It is a fixed step in a fixed flow, so it does not decide what to look up or reason across records. An agent on the Web API handles that second kind of work.

What are the limits of Airtable automations?

Native automations are scoped to a single base, run the same fixed steps regardless of input quality, and are capped by plan-level run limits. They cannot join data across bases or judge messy records. An agent built on the Web API, running as an app on Major, removes those boundaries and logs every write.

How do you build a custom Airtable automation?

Use the Airtable Web API. Authenticate with a scoped personal access token or OAuth, register a webhook for new records, then list, create and update records over REST. Use PATCH for writes so only the fields you send change, and batch requests to stay under the 5 requests per second per base limit.

Can an AI agent clean up messy Airtable records at scale?

Yes, if the judgment and the mechanics are separated. A model can decide what a half-filled company row should contain, but running it over every row is costly. On Major the agent builds an app that normalizes and patches records as code, calling the model only for ambiguous rows.

Airtable Automation: From Trigger-Action Rules to a Record-Enrichment

Airtable's automations are fine for simple in-base rules. This is what comes next: an agent that enriches new records, validates them against your rules, and routes the exceptions to a human.

Jose GironJuly 20, 2026Updated October 21, 2026

Airtable automation covers simple in-base rules well: a trigger fires, fixed actions run, a Slack message goes out. It stops when a record needs judgment, like a half-filled lead whose industry, domain and region have to be worked out. For that, build a record-enrichment agent on the Airtable Web API that cleans each new record, checks it against your rules, writes it back, and sends real exceptions to a person. Major is where that agent turns into a deterministic app, so the enrichment runs as code on every row and the model is only called for the rows that need a decision.

This is written for RevOps and operations owners who already live in Airtable and have hit the ceiling of the native builder.

Where native Airtable automation stops

A native automation lives inside one base. You pick a trigger (a record enters a view, a field changes, a form is submitted, a schedule) and chain actions: update a record, post to Slack, send an email, run a script. A status flips to "Approved" and a message fires. Use native automations for that and nothing heavier.

Airtable also offers a "Generate with AI" step that returns text or structured data from a prompt. It is still one fixed step in a fixed flow. It does not choose what to look up, notice that two fields contradict each other, or hold off because the input looks wrong.

The limits you hit in practice:

Native automations: single base, fixed steps, no judgment on messy input
Zapier or Make: cross-app, but rule-based branching only
Agent on the Web API: base plus outside sources, reasons per record, routes exceptions to a human

What an agent adds to an Airtable base

Three jobs show up again and again.

Enrichment. A lead arrives with a company name and little else. The agent finds the domain, maps the industry to your picklist, fills the region from the address, and leaves a note on whatever it could not resolve.

Validation. "Valid" is rarely one formula. A $0 amount can be correct for a pilot and wrong for a renewal. The agent checks amount against stage, currency against region, and whether the company already exists under a different spelling.

Exception routing. Clean records go straight back to the base. Ambiguous ones go to a person with the specific question attached ("industry 'Fintech' is not in the picklist, closest match 'Financial Services', confirm?") instead of a generic needs-review flag.

What you need from the Airtable Web API

Authenticate with a scoped personal access token, or OAuth for an app acting on behalf of users. Scope it to the one base. Read records with GET /v0/{baseId}/{tableIdOrName}, and create or update with POST and PATCH on the same path. Use PATCH for enrichment, because it changes only the fields you send while PUT clears the ones you omit.

For triggers, register a webhook with the webhook:manage scope. Airtable posts a small notification, then you fetch the actual changes from the list-payloads endpoint. Deliveries are at-least-once and can be coalesced, so use the transaction numbers to dedupe and keep order.

Two gotchas matter. Airtable allows 5 requests per second per base, and a 429 means waiting 30 seconds, so batch writes and back off. And the API is scoped per base, so any join across bases happens in your own code.

Build the Airtable record-enrichment agent on Major

Here is the worked example. A new row lands in a Leads table half-filled.

Trigger. An Airtable webhook fires on a new record in Leads. The app receives it on a route and fetches the change through list-payloads.
Enrich. The agent reads the company name, looks up domain and industry from an enrichment source, and normalizes the industry to your picklist.
Validate. Region must match country, industry must be in the allowed set, and the company must not already exist under another spelling.
Write back or escalate. A passing record is patched with the enriched fields and marked Enriched. A failing or ambiguous one stays flagged, and the Slack connector posts the exact issue to a review channel.

On Major the pieces map like this:

Connectors: Airtable for reads and writes, Slack for the review channel
The app that holds state: a managed database table of rules, picklist mappings, and a log of every record cleaned, so the app knows which rows it has already processed after a retry or a duplicate webhook
The agent and its judgment: the agent works out the enrichment and validation rules once and builds them into the app. After that, rule checks, picklist normalization and the PATCH run as code. The model is called for the ambiguous row, such as deciding what an unusual company name means
Trigger: the Airtable webhook, or a schedule that sweeps for missed rows
Governance: the Airtable token sits behind the credential proxy and is scoped to one base, so the agent never reads it. Role-based access controls who can edit the rules, and every write is recorded with the record, the field, and the reason

This is the difference from re-prompting a model on every row: the enrichment is software with its own state, so a 50,000-row backfill and the next new lead follow identical rules, and token cost is front-loaded while the agent works out the pattern, then stays flat. Start building free and describe the Leads app in a sentence.

Guardrails for an agent that writes to your base

Keep the scope narrow. The agent writes clean data and flags exceptions. It does not delete records or override a decision a person made. Respect the per-base rate limit by batching updates. Keep the log, because "which fields did it change on this record, and why" is the first question anyone asks after an automation touches a system of record.

Start with one table and one rule set. Enrichment on a single Leads table is the easiest first agent, because failures are visible, reversible, and cheap to review.

When to stay on native automations

If the job is a single field change that notifies a channel, keep the native automation. It is simpler and free of moving parts. Reach for the agent when the work depends on input quality you do not control, spans systems beyond the base, or needs an audit trail. This guide does not cover multi-currency reconciliation or syncing Airtable with a data warehouse; those are separate builds.

Start building on Major

Build the Airtable record-enrichment and validation agent as a governed app: Airtable for the records, Slack for exceptions, and a managed database that remembers every change. Your team reviews the exceptions and the app handles the rest.

Frequently asked questions

What is Airtable automation?: Airtable automation is a native, base-scoped builder that runs fixed actions when a trigger fires, like updating a record or posting to Slack when a status changes. It suits simple in-base rules. For work that needs judgment, an agent on the Airtable Web API can enrich, validate and route each record, and Major turns that logic into a deterministic app.
Can Airtable automations use AI?: Yes. The Generate with AI action runs a model inside an automation step and returns text or structured data from your prompt. It is a fixed step in a fixed flow, so it does not decide what to look up or reason across records. An agent on the Web API handles that second kind of work.
What are the limits of Airtable automations?: Native automations are scoped to a single base, run the same fixed steps regardless of input quality, and are capped by plan-level run limits. They cannot join data across bases or judge messy records. An agent built on the Web API, running as an app on Major, removes those boundaries and logs every write.
How do you build a custom Airtable automation?: Use the Airtable Web API. Authenticate with a scoped personal access token or OAuth, register a webhook for new records, then list, create and update records over REST. Use PATCH for writes so only the fields you send change, and batch requests to stay under the 5 requests per second per base limit.
Can an AI agent clean up messy Airtable records at scale?: Yes, if the judgment and the mechanics are separated. A model can decide what a half-filled company row should contain, but running it over every row is costly. On Major the agent builds an app that normalizes and patches records as code, calling the model only for ambiguous rows.