Airtable Automations are no-code if-this-then-that recipes built into a base: a trigger (a new record, an updated field, a scheduled time, a button click) sets off one or more actions (send an email, update a record, call a webhook, run a script). They genuinely handle same-base logic well. They stop being enough the moment the logic has to react to something outside Airtable or reach a system Airtable's own actions can't talk to properly.
A trigger fires on a record being created or updated, a field hitting a certain value, a scheduled time, or someone clicking a button on a record. From there, actions can send an email, update or create another record, post to a webhook, or send a message to another connected app. For anyone comfortable with a little JavaScript, the Scripting extension inside Automations opens up logic the point-and-click builder can't express on its own, conditional branching, looping over multiple records, custom formatting.
For logic that starts and ends inside one base, triggered by things happening inside Airtable itself, this native layer covers a lot of ground without needing a developer at all.
The webhook action can call an external URL, but it wasn't built to handle complex authentication, retries on failure, or pagination from an API that returns data in pages. Reacting to something that changed in a completely different system, rather than inside Airtable, isn't something a trigger can do at all. And multi-step logic that has to coordinate across several bases or outside systems reliably, with real error handling, usually outgrows what the point-and-click builder or even the Scripting extension was designed for.
That's where we build custom automation instead, often still working directly against Airtable's own API and webhooks rather than replacing Automations outright.
A button-triggered approval in Airtable also updates the matching record in an accounting or CRM system the moment it's approved, instead of the Airtable action stopping at an internal email that someone still has to act on manually.
A scheduled Automation that used to generate a report email someone still had to manually follow up on gets replaced with a full pipeline, one that retries on failure and reaches the right system directly instead of landing in an inbox.
If an Airtable Automation does most of a job and a person still finishes the rest by hand, tell us what the remaining step is and we'll scope closing it.
Tell us what trigger you're working with and where the built-in actions stop short, a webhook that can't authenticate properly, a system Automations can't reach at all. We'll scope the custom work. And if Airtable isn't where your real bottleneck sits, that's a fine place to start the conversation too.
Let's talk →A new record being created, a field or record being updated, a scheduled time, or a button clicked on a specific record are the common ones.
Yes, through the webhook action or connected app integrations, but with real limits: no built-in retries on failure and no handling for complex authentication or paginated API responses. Anything beyond a simple call usually needs custom work.
No, for the standard trigger-and-action setups. The Scripting extension inside Automations does require some JavaScript if you need logic the point-and-click builder can't express.
Run limits and frequency depend on your plan and can change, so airtable.com/pricing has the current numbers.
An Automation runs inside Airtable, triggered by Airtable's own events. The API lets a system outside Airtable read or write to it on its own schedule and its own triggers, the opposite direction of control.