Every Airtable workflow eventually needs to do something outside Airtable: send the Slack message, create the invoice, update the CRM. In 2026 you have three reasonable ways to do that: native Airtable automations, Zapier, and Make (the platform formerly called Integromat, renamed in 2022). n8n deserves a mention as the self-hosted option. We build with all of them, and the choice is rarely about which is "best"; it is about triggers, volume, cost, and what happens when a step fails. This guide gives you the decision matrix we use and then walks through moving one Zapier zap into a native automation.
The short version
- Start native. If the trigger is in Airtable and the actions are in Airtable, Slack, Gmail, Outlook, Google Sheets, Teams, or a handful of other built-in integrations, a native automation is free of per-task fees, lives next to the data, and has a run history your team can read.
- Reach for Zapier when you need a connector native does not have and you want the broadest catalogue with the least setup.
- Reach for Make when you need branching, loops, aggregation, or error handling beyond "retry", or when run volume makes Zapier's per-task pricing hurt.
- Reach for n8n when you need self-hosting for data-residency reasons or want code-level control without building a service from scratch.
Decision matrix
| Question | Native automations | Zapier | Make | n8n |
|---|---|---|---|---|
| Trigger lives in Airtable | Best (record created, matches conditions, form submitted, scheduled, button) | Good (polling or instant via webhooks) | Good (webhook or polling) | Good |
| Trigger lives elsewhere | Webhook trigger only | Best (largest catalogue) | Very good | Very good |
| Branching / loops | Conditional groups only; loops need a script step | Paths (limited), loops via extra steps | Routers, iterators, aggregators built in | Full control |
| Scripting | JavaScript "Run script" step | Code step (JS/Python) | Limited; functions in mappings | JavaScript/Python nodes |
| Volume pricing | Monthly run quota by plan; no per-task fee | Per task; every step counts | Per operation; cheaper at scale | Flat (cloud) or free (self-hosted) |
| Error handling | Retry on some failures; failure shows in run history | Auto-replay on some plans; alerts | Error routes, rollback, custom handlers | Error workflows |
| Who can maintain it | Anyone with base editor access | Ops / marketing | Needs a builder who likes diagrams | Developers |
| Data stays inside Airtable | Yes (except Slack/email payloads) | No; passes through Zapier | No; passes through Make | Yes if self-hosted |
Three rows matter more than the rest.
Triggers. Native automations trigger on things that happen in Airtable. If the event you care about happens in Stripe, HubSpot, or a web form outside Airtable, native can only listen through a webhook, which means something else has to call it. That alone pushes a lot of inbound workflows to Zapier or Make.
Volume. Native automations have a monthly run quota per plan and no per-task charge, so a high-volume internal workflow (every record update writes to a log table) is far cheaper native. Zapier charges per task, and a five-step zap that fires 10,000 times a month is 50,000 tasks. Make charges per operation but its tiers are more forgiving at volume.
Error handling. Native automations show failures in the run history and that is about it. Zapier will replay some failures. Make lets you build an error route that, for example, writes the failed payload to an Integration errors table and notifies someone. If a failed run has financial consequences, that capability is worth the extra complexity.
The cost question, honestly
For a typical small team the native quota covers every internal workflow, Zapier's free or starter tier covers the two or three external connectors, and nobody needs Make. For an operation with tens of thousands of monthly events, per-task Zapier pricing becomes the single largest line item in the stack, and moving the internal workflows to native and the heavy external ones to Make pays for the migration in a quarter. Check the current plan pages for exact quotas; they change, and we are deliberately not quoting numbers that will be stale in six months.
Worked example: migrating a Zapier zap to a native automation
The zap: When a record in Inquiries has Request type = Sales and Lead score ≥ 7, post a message to the #sales-leads Slack channel and create a record in the Deals table linked to the inquiry. Three steps in Zapier, fires on a polling trigger, costs three tasks per lead.
This one is native-shaped: trigger in Airtable, actions in Slack and Airtable.
1. Create the automation and trigger
In the base, open Automations, create a new automation, and choose the trigger When record matches conditions. Select the Inquiries table and set the conditions: Request type is Sales, Lead score ≥ 7. Run the trigger test against a real record so the later steps have sample data to map from.
Note the semantics: "matches conditions" fires when a record enters the matching state, not every time it is edited while matching. That is what you want here; it prevents re-posting to Slack when someone tidies the company name.
2. Add the Slack action
Add action Send Slack message and connect the workspace. Pick the channel and write the message, inserting fields from the trigger record:
New qualified lead: {Company} ({Lead score}/10)
{Name} <{Email}>
{Summary}
Open in Airtable: {Record URL}
Use the record URL token so the message links straight to the record. Test the step.
3. Add the Airtable action
Add action Create record, table Deals. Map Deal name from Company, Stage to New, and the linked-record field Inquiry to the trigger record's ID. Linked-record fields in automations accept record IDs, which the trigger exposes.
4. Guard against double-firing
Add a checkbox Deal created on Inquiries. Add a fourth action, Update record, that ticks it on the trigger record. Then add Deal created is unchecked to the trigger conditions. Now even if someone manually drops the score to 6 and back to 8, the automation will not create a second deal.
5. Turn it on, then turn the zap off
Enable the automation and watch the run history for a day with the zap still on but its Airtable create step paused, so you can compare outputs. Then disable the zap. Leave it in Zapier, switched off, for a month in case you need to roll back.
What you get
No per-task cost, a run history inside the base where the people who own the data can see it, and a trigger that fires on state change rather than polling every few minutes.
Where the native version would have been wrong
If the trigger had been "a new payment in Stripe", native has no Stripe trigger, and the right move is Zapier or Make calling Airtable. If the Slack message needed to go to a different channel per region with a lookup table and a fallback, Make's router is cleaner than a pile of conditional groups. If the deal creation needed to loop over several products on the inquiry and create one line item each, native would need a script step, and at that point Make's iterator or n8n is easier to maintain.
Rules of thumb we give clients
- Native first for Airtable-to-Airtable and Airtable-to-Slack/email.
- One tool per workflow. A zap that triggers a native automation that triggers a Make scenario is undebuggable.
- Every external workflow writes its failures somewhere a human looks.
- Document the trigger semantics. "Matches conditions" versus "record updated" is the source of most duplicate-record bugs we are asked to fix.
- Revisit annually. Airtable keeps adding native integrations and AI steps; a workflow that needed Zapier in 2023 may not in 2026.
If you inherited a tangle of zaps and are not sure which should be native, our Custom Workflow Automation service starts with exactly that audit. Contact us.