Airtable Sync: Setup, Two-Way Sync and Limits

What is Airtable Sync?

Airtable Sync connects a source dataset to a table in another base. A source view defines the records made available; the destination uses that shared information in its own work.

With one-way sync, shared fields are edited at the source. Fields added locally belong to the destination and do not sync back.

For example, an operations team can use the client directory maintained in a sales base without manually copying company details every week. The purpose is to distribute reliable reference data, while making it clear where corrections belong.

Native Sync is available on current paid plans with different limits. Before choosing an architecture, check the workspace's actual entitlements, especially if it uses a legacy plan.

Sync, linked records or integration: which do you need?

These mechanisms solve different problems:

If sales and delivery are part of one continuous process, first consider one base with Interfaces for each role. Splitting that process into bases adds connections to maintain.

Separate bases can still make sense when applications have genuinely different ownership, access requirements or lifecycles. The design question is which data they need to share.

How to sync two Airtable bases

1. Define the dataset before opening the sync settings

Write down what the receiving team needs, who owns each field, and what should happen when a record is archived. Use a dedicated source view rather than a personal working view whose filters change throughout the day.

For a client directory, this might mean client ID, company name, account owner and account status. Internal sales notes do not automatically belong in delivery.

2. Enable the source view for syncing

Open the source grid view, choose Share and sync, then Sync data to another base. Enable Allow data in this view to be synced to other bases. Use Sync this view, or provide the syncable share link to the person configuring the destination.

These controls are described in Airtable's view sharing documentation.

3. Create the destination table

In the receiving base, use Add or import, choose Airtable base, and select the source view or its share link. Review the fields and sync settings before creating the table. The person configuring the destination needs Creator or Owner permissions there.

Start with a small dataset whose expected result you can check. A successful connection is only the first part of a successful setup.

4. Decide what happens when records leave the source

Review whether unavailable source records should be removed from the destination or retained. Removing a destination record can also remove local information and links attached to it. This includes records filtered out of the source view, not just records explicitly deleted.

For historical project work, an explicit archived status may be more suitable than a filter that makes the client disappear. Retention must still match the access and data retention rules of the business.

5. Test the receiving team's actual workflow

Check a new client, a corrected company name, an archived client and a record that leaves the source view. Then confirm that the receiving team can find the right client and continue its work.

Also test with the permissions of an ordinary user. A configuration that works for the builder may expose the wrong fields or leave a required action unavailable to the team.

Example: share a client directory between CRM and delivery

Consider this illustrative agency setup, not a reported client result. Sales maintains a CRM base; an operations team already owns a separate delivery application. They need the same client references, but they do not own the same information.

Sync the selected CRM client dataset into a Clients table in delivery. Link the local Projects table to those clients. Project managers select an existing client instead of retyping company details on each project.

Airtable supports relationships between records within the receiving base. This gives the local project model a shared reference without turning every project field into a synced field.

Keep a business identifier when other systems also need to recognize the client. A name alone is a weak matching rule: companies can be renamed, and two clients may have similar names.

The arrival of a client does not, by itself, mean a project should be created. A separate business event, such as an accepted engagement, should authorize that action. Our Airtable automation guide covers that execution layer.

When should you use two-way sync?

Use two-way sync when an authorized team must correct shared fields from its own base. Airtable's native two-way sync requires Business or Enterprise Scale, with editing enabled at both ends.

Limit editable fields to those the receiving team should maintain. Creating or deleting records requires additional configuration; enabling edits alone does not authorize every operation.

API writes to synced fields are not supported for native two-way sync. A third-party frontend that writes through the API therefore needs a different write path. In the agency example, if delivery only reads the CRM directory, one-way sync remains sufficient.

Consolidate multiple sources with consistent definitions

Multi-source sync brings several datasets into one destination table and is available on current Team, Business and Enterprise Scale plans, with varying limits.

It can help a group consolidate project lists maintained by separate operating units. First align what their fields mean: a date called “Delivery” could represent a commitment in one base and actual completion in another.

Define identifiers, status meanings, field mappings and source provenance before treating the result as a management report. Aggregation does not establish that apparently similar records represent the same business entity.

If Sync linked tables is enabled for a sync, Airtable does not support adding multiple sources to it. Check this compatibility before designing a network of dependent bases.

External tools: check the direction and the write path

Native sync integrations bring supported external data into Airtable in one direction. Their availability depends on the connector and workspace plan. Do not assume that changing an imported calendar item in Airtable updates the external calendar.

Google Sheets needs a separate distinction: Airtable's built-in Sheets import is a snapshot, not a live sync. Its automation for newly added rows does not keep later edits to existing rows aligned.

For an ongoing external integration, define these rules before choosing a tool:

• Which system owns each field?

• Which identifier matches records across systems?

• How are repeated updates prevented from creating duplicates?

• What happens to deletions and conflicting edits?

• How does someone detect and replay a failed update?

Use the Airtable API guide when the requirement needs a programmed integration. The Sync API is a separate mechanism for pushing CSV data into Airtable; it is not a general two-way connector.

Troubleshoot the dependency before rebuilding the table

Airtable's sync troubleshooting guide is a useful starting point. Diagnose the cause before replacing a table that other tables or Interfaces already depend on.

Regenerating a source share link can affect every destination using it. Identify dependent bases and their owners before doing so.

Start with one shared dataset

A useful first sync has a named owner, a limited field list, clear edit permissions and tested removal behavior. Confirm that the receiving team can complete its real task, then extend the design if another dataset needs the same treatment.

If the architecture requires circular syncs, repeated copying or several competing client directories, reconsider where the reference data belongs. HyperOps can help design and implement an Airtable business system around those responsibilities.

Frequently asked questions about Airtable Sync