---
title: 'How to Set Up Airtable Two-Way Sync Between Bases'
description: 'A practical guide to Airtable sync — one-way sync, two-way sync, filters, sync limits, and architecture patterns for when to split data across bases.'
canonical_url: 'https://www.business-automated.com/tutorials/how-to-setup-airtable-two-way-sync'
md_url: 'https://www.business-automated.com/tutorials/how-to-setup-airtable-two-way-sync.md'
last_updated: 2026-06-20
---

Most growing [Airtable](/airtable-consultant) systems hit a moment where one base is no longer the right answer. The marketing team wants their own workspace. The finance team's data is sensitive and shouldn't live in the same place as the project pipeline. A central Clients table needs to appear in five different team bases without copying records around. This is where Airtable Sync comes in.

Sync lets one table live in two places. One-way sync makes a read-only mirror; two-way sync makes both copies editable. Used well, sync turns a single base into a multi-base architecture without losing the relational links between teams. Used poorly, it creates conflicts, performance issues, and a mess that's worse than what you started with.

This guide walks through how sync actually works, the difference between one-way and two-way, and the architecture patterns we use in client projects.

## What Airtable Sync Actually Does

Airtable Sync copies a table — or a filtered slice of one — from a **source base** to a **destination base**. The synced table in the destination shows up as a regular Airtable table, with all the same fields, the same data, and any of its records visible to anyone with destination-base access.

Updates flow from source to destination automatically every few minutes. With **two-way sync**, edits made in the destination also flow back to the source on the same schedule.

| Sync type     | Edits in destination? | Edits in source? | Plan required |
| ------------- | --------------------- | ---------------- | ------------- |
| **One-way**   | No (read-only)        | Yes              | Team+         |
| **Two-way**   | Yes                   | Yes              | Business+     |

The key thing to understand: sync is **table-level**, not base-level. You choose specific tables to sync, not the entire base. A single base can be both a source (some tables synced out) and a destination (other tables synced in) at the same time. That flexibility is what makes complex architectures possible.

> **Quotable fact:** A single source table in Airtable can be synced into up to twenty destination bases on the Business plan and unlimited destinations on Enterprise — making sync the standard mechanism for distributing reference data across an Airtable estate.

## Setting Up a One-Way Sync (Five Minutes)

Most people start with one-way sync. It's simpler, available on more plans, and covers 80% of real use cases.

**In the source base:**

1. Open the table you want to sync.
2. Click **Share view** on the view you want to expose. The view's filters and visible fields will define what gets synced.
3. In the share panel, toggle on **Allow data in this view to be synced to other bases**.
4. Copy the generated sync URL.

**In the destination base:**

1. Click **Add or import** → **Sync data from… → Airtable base**.
2. Paste the sync URL.
3. Pick which fields to include (you can sync a subset of the source view's fields).
4. Name the destination table and create it.

Within a minute, the synced table appears in the destination. Every five minutes (or on manual refresh), Airtable checks the source view and updates the destination — adding new records, removing records that no longer match the filter, and updating changed fields.

The destination table has a small **sync indicator** in its tab, and synced fields show a lock icon. You can add **non-synced fields** to the destination table — these are local to the destination and won't propagate. This is how teams add their own status, notes, or assignment fields to a synced table.

For Airtable's official setup walkthrough, see the [Sync documentation](https://support.airtable.com/docs/sync-overview).

## Setting Up a Two-Way Sync

Two-way sync requires the Business plan or higher and must be explicitly enabled per sync configuration.

**In the source base:**

1. Open the share-view panel as you would for one-way sync.
2. Toggle on **Allow data in this view to be synced**.
3. Toggle on **Allow editing of synced data**. This is the two-way toggle.
4. Choose which fields are editable from the destination (you can keep some fields read-only).

**In the destination base:**

1. Set up the sync exactly as you would for one-way.
2. The destination table will show synced fields as editable — and edits flow back to the source on the next sync cycle.

The "edits flow back" part is where most teams need to think carefully. If two destinations both edit the same synced record between sync cycles, the last write wins. There is no merge logic, no conflict UI, no warning. We treat two-way sync as a tool for **single-owner-per-record** workflows: one team owns each record at any given time, even if multiple teams can see it.

## When to Use One-Way vs Two-Way Sync

| Use case                                                            | Sync type       | Why                                                       |
| ------------------------------------------------------------------- | --------------- | --------------------------------------------------------- |
| Central Clients table read by project bases                         | One-way         | Project teams don't change client records                 |
| Master Product Catalog shared with regional bases                   | One-way         | Catalog is owned centrally                                |
| Sales team handing off won deals to a Delivery base                 | Two-way         | Delivery team updates status; sales needs to see updates  |
| Finance Invoices base reading project data                          | One-way         | Finance shouldn't edit project state                      |
| Distributed teams jointly managing a shared task list               | Two-way         | Every team needs to update task status                    |
| HR base feeding employee records to operational bases               | One-way         | HR owns the employee record; ops just reads it            |

The pattern: use one-way sync as the default and only upgrade to two-way when there's a genuine business need for the destination to write back. Two-way sync adds operational complexity (conflict risk, ownership questions) that should be paid only when needed.

## Filtering Synced Data at the Source

A common mistake is syncing entire tables when only a slice is needed. Airtable lets you filter at the source so the destination only sees the relevant records.

The filter is the **view's filter** — whatever the source view shows is what gets synced. Build a view that filters to just the records you want to share (e.g. `Status = "Active"` and `Region = "EMEA"`) and sync that view, not the full table.

This is more efficient (fewer synced records, faster sync, lower record counts in the destination) and safer (the destination physically cannot see records that don't match the filter, even by accident).

Common filter patterns:

- **By status:** Only sync active projects, not archived ones.
- **By region or team:** EMEA records to the EMEA base, AMER to the AMER base.
- **By stage:** Sync only deals that have hit "Won" to the Delivery base.
- **By sensitivity:** Sync only fields and records cleared for the destination audience.

## Architecture Patterns That Work

After enough client builds, a few recurring patterns hold up well.

### Hub-and-Spoke

One central "hub" base holds the canonical data — Clients, Products, Team Members. Multiple "spoke" bases sync the relevant slices in for local use. Each spoke base also has its own private tables that never sync.

```
                  ┌──────────────┐
                  │   Hub Base   │ ← canonical Clients, Products
                  └──────┬───────┘
            ┌────────────┼────────────┐
            ▼            ▼            ▼
       Marketing      Sales        Delivery
         Base          Base          Base
```

Use **one-way sync** for the hub-to-spoke flow. Spokes are read-only consumers of hub data. If a spoke needs to flag something for the hub (e.g. "this client is now inactive"), use a local field that syncs nothing and triggers an automation back to the hub.

### Stage Handoff

A pipeline of bases, each owned by a different team. Won deals flow from a Sales base to a Delivery base. Completed projects flow from Delivery to Finance.

```
   Sales Base ─→ Delivery Base ─→ Finance Base
```

Use **two-way sync** at the handoff points, with a status field that controls when records appear in the next stage. Once a deal is marked "Won," it appears in the Delivery base; once a project is marked "Complete," it appears in the Finance base.

### Public-Facing Mirror

A public catalog or directory sits in its own base, separated from internal operations. The internal team works in a private base. A filtered one-way sync pushes "publishable" records to the public base.

```
   Internal Base ─→ Public Base (one-way, filtered)
                       ↓
                  Shared view / interface / portal
```

This is the safest way to expose public data — there is no way for a destination viewer to accidentally edit the source, because the destination is read-only by design.

## Sync vs API vs Automation: Choosing the Right Tool

Sync is one of three ways to move data between Airtable bases. The other two are the Airtable API and native automations.

| Method        | Best for                                          | Cost                              | Speed                |
| ------------- | ------------------------------------------------- | --------------------------------- | -------------------- |
| **Sync**      | Continuous mirroring of a table                   | Free within plan limits           | 5-min cycles         |
| **API**       | Custom logic, transformations, conditional moves  | Counts against API rate limits    | Real-time            |
| **Automation**| Event-driven copies (e.g. "when status changes")  | Counts against automation runs    | Near real-time       |

Sync is the right answer when you want a **whole table** kept in sync. The API or an automation is the right answer when you want to **copy specific records** based on logic — for example, "when a deal is marked Won, create a project record in the Delivery base." For the API approach, see our [personal access token guide](/tutorials/airtable-personal-access-token-guide).

## Limits and Gotchas

Sync is powerful but it has rough edges. Things to plan for:

**Field type mismatches.** A formula field in the source becomes a formula reference in the destination — but you can't edit the formula in the destination, and changes to the formula in the source replace whatever was there. Plan formula fields carefully before syncing.

**Linked records don't sync as links.** If you sync a table that has linked record fields, the destination receives the **primary field text** of the linked records, not actual links. To preserve the link, you must sync **both tables** into the destination and recreate the relationship locally, or use a different reference key.

**Sync delay matters for automations.** If an automation in the destination triggers on a synced record being updated, it fires when the next sync cycle pulls in the change — up to 5 minutes after the original edit. Don't rely on sync for time-sensitive flows.

**Two-way sync has no conflict resolution.** If the source and a destination both edit the same record between sync cycles, the most recent edit wins silently. Build your workflow so this can't happen — clear single ownership of records at any given time.

**Attachments increase sync cost.** Attachment fields sync, but they count against attachment storage in the destination as well. For large attachment-heavy tables, consider syncing a thumbnail or URL field instead and linking out.

## Common Mistakes

**Syncing too much.** Engineers and consultants love to sync everything "just in case." Each sync costs storage, sync-cycle time, and complexity. Sync only what the destination actually needs.

**Two-way sync where one-way would do.** Two-way sync is opt-in for a reason. If you don't have a clear write-back use case, leave it off. It's much easier to upgrade one-way to two-way later than to recover from conflicts caused by accidental two-way writes.

**No documentation of sync graph.** A few months in, no one remembers which bases sync from which. Maintain a one-page "sync map" in a meta-base or shared doc that shows the source and destination of every sync, who owns each, and what the filter is.

**Treating sync like a backup.** Sync is not a backup. If you delete a record in the source, it disappears from every destination. For proper backups, see our [Airtable backup guide](/tutorials/airtable-backup-complete-guide).

## Where to Go Next

Sync is the architectural primitive that lets you split a single base into a system of bases without losing relationships. Once you understand sync, the bigger question is how to structure those bases — that's covered in our [base vs table vs workspace guide](/tutorials/airtable-base-vs-table-vs-workspace).

For permissioning multi-base systems, see the [permissions guide](/tutorials/how-to-setup-airtable-permissions). For programmatic data movement instead of sync, our [Make automation guide](/tutorials/automate-airtable-with-make-guide) covers the alternative approach where you push records between bases based on business logic rather than mirroring tables.

Airtable's [Sync overview documentation](https://support.airtable.com/docs/sync-overview) is the official reference and worth reading once when you're setting up your first multi-base architecture.


## Sitemap

See the full [sitemap](/sitemap.md) for all pages.