Skip to main content
Question

Enhancement Request — Native support for automations that trigger and act across multiple bases

  • September 15, 2026
  • 3 replies
  • 24 views
lkaminski92

 

Summary

Airtable Automations and Zapier's native Airtable integration both operate within a single base's boundary. There's no first-party way to build a trigger-and-action automation where the trigger lives in one base and the corresponding lookup/write lives in a different base — even when both bases belong to the same workspace and the same organization. Any cross-base workflow currently has to be built by dropping out of native tooling entirely and hand-writing REST API calls inside a Zapier/Make code step, using a manually-generated Personal Access Token.

Concrete example of the workaround we had to build

We needed: when a title record in our "Metadatabase" base gets a specific identifier populated, look up the matching title in a separate "Creative Base," find its linked Audio Cover Art project record, and write a direct link back into Metadatabase — so our Distribution team can jump straight to cover-status info without manually navigating a second base they aren't familiar with.

Because Airtable Automations can't natively read from or write to a second base, and Zapier's Airtable app can only "Find Record" one at a time (no bulk "Find Records" action either), we ended up needing:

  • A hardcoded Personal Access Token embedded directly in a Code step, scoped across both bases
  • Manual fetch() calls to api.airtable.com to simulate a cross-base "Find Record" that the native integration doesn't offer
  • A hand-built pagination/offset system (using Storage by Zapier) just to page through more than ~100 records at a time, because a plain batch fetch inside a Code step blows past the 30-second runtime limit on any view larger than a few hundred rows
  • No visibility into any of this from Airtable's own Automations interface — the whole cross-base piece lives invisibly in a third-party code sandbox

What we'd like instead

  1. A native Automation trigger/action pair that can target a table in a different base within the same workspace or organization — without requiring a manually-managed PAT.
  2. A native "Find records" (plural) action, not just "Find record" (singular), so a batch of matches can be retrieved without a code step.
  3. Some official mechanism for cross-base lookups analogous to what Airtable Sync already does for read-only mirroring — but usable inside Automations logic, not just for passive syncing.

Why this matters

Sync tables already prove Airtable understands cross-base relationships are common at the workspace level — but Sync only mirrors data, it doesn't let that data drive further automated actions. Any organization with more than one base per department (which seems to be nearly all of them, based on how our own bases are structured) hits this same wall the moment they want automation logic that spans bases, and ends up needing a developer to hand-roll API calls in a third-party tool instead of using Airtable's own automation builder.

3 replies

ScottWorld
Forum|alt.badge.img+35
  • ScottWorld
  • Genius
  • September 15, 2026

I would recommend submitting this as a feature request on Airtable’s product feedback page.

In the meantime, I would also recommend taking a look at Make’s advanced automations & integrations, which enable you to create automations that work across multiple bases — all within the same automation.

Make is also less expensive & more powerful than Zapier — I did a writeup on this topic here.

If you’ve never used Make before, I’ve assembled a bunch of Make training resources in this thread.

For example, here is one of the many different ways that you can instantly trigger a Make automation from Airtable. You can even instantly trigger a Make automation by having a button or URL link trigger a custom webhook (with optional webhook response).

I give live demonstrations of how to use Make in many of my Airtable podcast appearances. For example, in this video, I show how to work with Airtable arrays in Make. And in this video, I show how to use custom webhooks.

Hope this helps!

If you’d like to hire the best Airtable consultant to help you with anything Airtable-related, please feel free to contact me through my website: Airtable consultant — ScottWorld

Russell_Bishop1
Forum|alt.badge.img+22

Hi ​@lkaminski92. Your use case sounds to me like it is possible to handle with sync, but maybe with a little re-thinking. I’m only 80% confident though.

 

Two requests to start with:

  1. Automation trigger/action pair that can target a table in a different base
  2. Cross-base lookups — but usable inside Automations logic, not just for passive syncing.

I would propose setting up your automations in the base downstream from where the trigger happens, using a sync.

 

Example:

  • We have a base called Projects.
  • We have base called Budgets.
  • When a project is “Won”, we want to create some Roles for people in the Budgets base.


Instead of the trigger ‘When a project is “Won”’ living in the Projects base, it would live in the Budgets base, watching the synced Projects table for that change.

  1. When project status = “Won” (synced records)
  2. Repeating over the “People” linked to this project
  3. Create a record in the Roles table
  4. ✅ Roles created for Won project

Similarly, if other bases for other departments required that same trigger, they too would have a downstream sync from Projects and their own Automation configured locally.

 

 

Last one:

  1. Native "Find records" so a batch of matches can be retrieved without a code step.

I think you were talking about Zapier here, but Find records in Airtable is <=1000 records.

 

Hope that helps, if I missed the point completely let me know!

Russ @ Mass
TheTimeSavingCo
Forum|alt.badge.img+32

+1, I had to do something similar and having bases be able to talk to each other would be great

I didn’t have the pagination / storage step tho and I’m kind of curious about that; the fetch would have a filterByFormula param so you’d only get back the records you wanted right?  Or if we’re doing multiple records from the triggering base, then that’d be handled by a Repeating Group followed by the Code step?

Adam, Airtable Consultant - https://thetimesaving.company
Terms & ConditionsAccessibility statement