BaseBrainers | Airtable Sync: Hub-and-Spoke Bases, Multi-Source, and Two-Way Sync

Every growing Airtable estate hits the same wall. Sales want their own base. Finance will not let sales see margins. Ops need a single project list that both teams can read. Someone proposes "one base to rule them all", someone else proposes copy-pasting a CSV every Monday, and both are wrong.

Airtable sync is the answer to most of these, and it is one of the least understood features on the platform. This tutorial covers how synced tables actually behave, how to fan data out of a hub base, how to fan it in from many sources, when two-way sync earns its keep, and the failure modes we most often get called in to fix.

What a synced table is

A synced table is a read-only mirror of a source view in another base (or of an external source such as Google Sheets, Jira, Salesforce, or Box, depending on your plan).

Three things follow from that definition, and almost every sync problem traces back to one of them:

The unit of sync is a view, not a table. Whatever the view's filters hide does not sync. Whatever fields the view has hidden do not sync. This is the control surface — use it.
The destination is read-only for synced fields. You cannot edit them in the destination base. You can add your own local fields alongside them, and that is the whole trick to using sync well.
Sync is one-directional by default. Data flows source → destination. Two-way sync is an opt-in setting with real constraints, covered below.

Sync availability, refresh frequency, external sources, and the number of sources per table vary by plan and change over time — check your workspace's plan details before designing around a specific limit.

Step 1: set up a one-way sync

We will publish a filtered project list from an internal Delivery base into a Client Reporting base.

In the source base:

Create a view specifically for syncing. Name it SYNC → Client Reporting. Do not reuse a working view; someone will change its filters on a Tuesday and break your downstream base.
Filter it: Status is not Internal, Client visible is checked.
Hide every field the destination must not see — day rates, internal notes, margin.
Open the view's share menu and enable syncing to other bases. Copy the share link.

In the destination base:

Add a new table, choose to sync from another Airtable base, and paste the link.
Choose which of the available fields to bring in. Take fewer than you think you need; you can add more later.
Pick the refresh behaviour (automatic or manual) and finish.

You now have a Projects (synced) table that updates itself. Add local fields next to it: Client comments, Reviewed, Portal status. Those are yours, editable, and they persist across refreshes because they are matched to the synced record, not overwritten by it.

Step 2: understand what happens on refresh

New records in the source view appear in the destination.
Edits in the source overwrite the mirrored fields in the destination.
A record that leaves the view — because it was deleted, or because someone changed a field so the filter no longer matches — disappears from the destination, and any local field values you had attached to it go with it. If it comes back, the locals do not.

That last behaviour catches people out. If your local fields hold anything you cannot afford to lose, do not attach them directly to synced records. Instead, create a normal table in the destination base, link it to the synced record, and store the durable data there.

Also note that a synced field's type comes from the source. If someone converts Status from single select to text upstream, the destination follows, and every formula, filter, and automation you built on it in the destination base needs a look.

Step 3: fan out — the hub-and-spoke pattern

The most common healthy architecture we build looks like this:

One hub base owns each core entity: Clients, Projects, People. This is where records are created and edited.
Each spoke base (Finance, Client Portal, Recruiting, Exec Dashboard) syncs in the slices it needs, through a purpose-named view, and holds its own local tables for its own work.

Why this beats one giant base: permissions. Airtable's base-level permissions are coarse — someone with edit access to a base can generally see the tables in it. If Finance must not see candidate salary expectations, do not put both in one base. Put them in different bases and sync only the columns that are allowed to cross the boundary. The sync view is your field-level permission model.

Why it beats copy-paste: it is live, it does not drift, and there is exactly one place a value can be wrong.

Step 4: fan in — multi-source sync

The reverse pattern: several source views feed one destination table. Three regional sales bases sync into a single Global Pipeline table; four agency partners each sync a project list into your master schedule.

Two things make this work in practice:

Align the schemas first. Fields are matched by name. Deal Value in one base and Deal value in another become two columns in the destination, and your rollups will silently miss half the data. Agree on names and types before you connect anything.
Add a source field. Multi-source syncs expose which source a record came from; surface it as a field and use it in grouping and filters. Without it, debugging "why is this record here twice?" is miserable.

Where multi-source sync earns its money is consolidated reporting: one table, one set of rollups, one dashboard, without anybody exporting anything.

Step 5: two-way sync, carefully

Two-way sync lets you nominate specific fields as editable from the destination, with those edits pushed back to the source. It is genuinely useful in a narrow set of cases:

A client or partner updates Status or Delivery date on records you own.
A reviewer sets an Approved checkbox in a base they have access to, without giving them access to the base where the record lives.

Rules to follow:

Make as few fields two-way as possible. One or two. Everything else stays read-only.
Never make a field two-way that an automation also writes. A person edits in the destination, an automation writes in the source, and you get a last-write-wins race with no audit trail.
Do not two-way sync computed fields. Formulas, rollups, and lookups belong to the source.
Record the intent in the field description. Six months later nobody remembers which of the forty fields is the one that writes back.

If your requirement is starting to sound like "and then it also needs to write back to three other bases", stop. That is not sync, that is an integration, and it belongs in automations or a script where you can control ordering and log failures. Our Zapier, Make, or native automations guide covers choosing the right tool for that.

Step 6: performance and scale

Sync duplicates records. A 60,000-record source view synced into four destination bases is 240,000 more records against your workspace's usage, and four sets of rollups recalculating. Some habits that keep this manageable:

Sync the slice, not the archive. Filter sync views by a rolling window — Modified is within the last 12 months, Status is not Closed — rather than syncing everything ever.
Sync summaries, not raw rows. If the destination only needs monthly totals per client, build a rollup in the hub and sync that, instead of a million time entries.
Prune fields. Every hidden field in the sync view is one fewer column to move on every refresh.
Beware chains. Base A syncs to B, B syncs to C. Latency compounds and a schema change in A surfaces two hops away. Two levels is usually the sane maximum.

For genuinely large datasets, Airtable's enterprise tiers have added large-scale data capabilities aimed at millions of records feeding apps and agents; if you are trying to force tens of millions of rows through ordinary synced tables, that is a conversation about plan and architecture rather than a settings fix. Talk to us about enterprise-level Airtable solutions before you build it twice.

Troubleshooting checklist

"A record vanished from the destination." It no longer matches the source view's filter, or it was deleted. Check the filter first, ninety percent of the time that is it.

"The destination shows stale data." The sync is set to manual refresh, the source share link was regenerated, or the source view is on a base whose sharing was revoked. Open the synced table's settings and look at the last successful sync time.

"Two records for the same thing." Multi-source sync with mismatched field names, or the same source connected twice. Group by the source field to see it.

"I cannot edit this field." Working as designed — it is a synced field. If it genuinely needs editing in the destination, either make that one field two-way or move the workflow to where the record lives.

"My automation fires on every refresh." Automations triggered by "when record updated" on a synced table will fire when the sync writes. Narrow the trigger to specific fields, or trigger on entering a view instead.

"The field type changed and my formulas broke." Someone changed the type upstream. Add a note to the source table's field description asking people not to, and put the sync view in a base section that signals it is load-bearing.

A short design checklist

Before you connect anything, answer these five:

Which base owns each entity? One answer per entity.
Which fields are allowed to cross each boundary? That list becomes your sync view's visible fields.
What is the filter that defines the slice, and who is allowed to change it?
Does anything need to write back? If yes, exactly which one field?
What durable local data lives in the destination, and is it safe if a record leaves the view?

Sync is not a data-integration platform, and pretending it is one is how bases end up in the state we get called to rescue. Used as intended — a permissioned, filtered, live view of someone else's data — it removes an enormous amount of copy-paste from an organisation.

BaseBrainers designs multi-base Airtable architectures, including sync topology, permissions, and reporting layers. If your bases have started multiplying faster than your plan for them, tell us what you are dealing with.