Two-way syncing in Airtable

1. In the source base, find the sync source view’s setting menu and

2. Next, click on Sync data to another base.

3. If the Allow edits from other bases option is not enabled, click the toggle to enable it. You will see field editability options. Configure those options as necessary for your use case.

4. Below those options, you’ll find the Allow creating new records or Allow deleting records toggles. These options are turned off by default, but can be enabled singularly or in tandem.

Source

• The source view’s table cannot be a target sync of another source. e.g. No “daisy-chaining” of syncs are allowed.

• The source view’s parent table must have table permissions set to “Editors and above”. Any other permission level will disallow record creation and deletion from synced tables.

• The source view must contain at least one editable field.

Target

• The target table’s sync configuration must enable the Edit source records option.

• The target’s permission setting must allow a user to create and/or delete rows. Granular permissions will be respected.

  • Example 1: A base collaborator with commenter permissions won’t be able to create or delete records in the synced table just like any other table in the base.

  • Example 2: A user may have access to both bases where the source and the target of the two-way sync reside. However, if they have creator permissions in the source, but only have read-only permissions in the target, then that user will not be able to create or delete records in the target table/base.

When a record is created from a synced target table, empty cells are populated in the source view in the following order of precedence:

1. Default values inferred from source view filters (if and only if the field upon which the filter is present is also editable from the target sync)

2. Source field default values.

It’s also important to note that:

• Filter default value inference is supported on filter operators such as “is”, “is empty”, etc (and such operators joined by “AND” conjunctions) where there exists only one unambiguous value that satisfies the filter condition.

• Filter default inference is not supported on filter operators such as “is any of”, “contains”, “has any of”, etc or compound filters joined by “OR” conjunctions, where multiple values exist that satisfy the filter condition.

• Records created within synced tables must meet the source view’s filters or the action will error. These filters are not visible to downstream users.

• The ability to create records in multi-source synced tables is not available

• Similar to two-way sync edits, the ability to create/delete records in synced tables is not available through Airtable’s API.

• The ability to create/delete records in synced tables with automations is unavailable.

• Form views are not supported in synced tables.

• It is not possible to set column default values in downstream synced tables.

• Record creation/deletion is supported in interfaces leveraging a table set up for two-way sync in this way. However, you’ll need to adjust any sync settings from the base layer.

• Consult the other limitations of two-way syncs listed below.

In another base, you can follow the normal flow of adding a new table that will sync with the source table that has been configured. Click the + Add or import button and choose the  Airtable base option below the Sync data from section.

From here, you can either select a view from a base that you collaborate in or use a sync share link that has been shared with you by another user. In either case, the source view you are syncing with must have two-way sync enabled to edit information in the target table.

Note

End users are only able to choose shared views in bases where they have editor-level permissions or higher. More information on this behavior is available here.

Click Next and then choose which fields, All fields or Specific fields, you would like to sync over from the source to this target table. Even though you might be able to see a field in the target table, it doesn’t necessarily mean that it will be editable. Editability is dependent upon the configuration made in the source as well as an upcoming step in the target sync’s setup.

Note

Under the “Advanced” section, you can choose which field from the source you would like to set as the primary field in this target table. By default, the primary field will match the source table’s primary field. More information about this option is available here.

Once the field selections have been set, click Next to move onto the final setup screen.

Before creating your synced table, there is a setting that allows you to choose who can edit source records. Click Change below the  Edit source records toggle to make adjustments based on your needs. This option is specific to the two-way sync feature.

Note

It’s possible that not all of the workspaces that you collaborate in will have two-way sync functionality. If you don’t see the option to set who can edit source records, then it’s likely the case that the target base you are trying to create the two-way sync in resides inside a workspace that does not support this feature currently. To remedy this, you may need to reach out to an admin to make a change inside Admin Panel, specifically, the global Synced view restrictions setting outlined in the accordion in this section of the support article about the Settings page in Admin Panel.

There are three options available for source editing:

1. Allow creators and above in this base to edit source records

2. Allow editors and above in this base to edit source records (Default)

3. Don't allow anyone in this base to edit source records

Two-way sync permissions have many considerations, we recommend consulting this article to dig into permissions dependencies more deeply.

Warning

The other two options in this section should not be changed. Changing the sync frequency to Only sync changes when requested or the record deletion option to Leave the records in this table will cause two-way syncs to break and render as a one-way sync. 

Once you’ve selected your desired settings, click Create table. It’s a good idea to check that the functionality of the table matches your expectations. If you need to adjust any parameters of this synced target table, then click the drop-down next to the table’s name and select the Update sync configuration option.

There are two surfaces within visualization layouts that allow end-users to edit records. You can choose to use one of these options independently, or both of these options together:

1. Click into record details - Setting up this option allows end-users to open up more details for a specific record. Builders can customize this record detail page as a sidesheet or fullscreen experience. Each field that you want end-users to be able to edit will need to be configured individually. From the customization screen for the record detail page, click a field that you want to make editable. Under the “Permissions” section change the setting to Editable.

   

2. Edit records inline - You can choose to also make inline editing possible for all available fields from the source. To do this click on the Edit records inline option and then toggle on the option that appears in the settings.

Note

If you see a message that "This field is synced from a source that doesn't allow it to be edited," then there are likely field editing permissions in the source base preventing the field from being set as Editable.

Individual interface elements can be set as editable as well. Under Permissions, choose the Editable option to allow editing for all available field from the source. In certain elements, like the record picker element, you can also choose to allow records to be edited. However, to accomplish this, each field that you want end-users to be able to edit will need to be configured individually. Click each field to change it's Permissions settings to Editable.

• Explanation: Like any other sync setup, the source table is meant to be the main source of truth for the information that is being stored within Airtable. For this reason, it is only possible to add new records to the source, not target tables.

• Workaround: There are several workarounds for this. Depending upon the way that your team is using two-way sync you might consider using Forms, Interface designer, or even setting up another sync. In most cases, creating a “record creation” form in the source table usually works as a solution.

• Explanation: New fields can be created in target tables, but they will not be “syncable” back to the source. New fields will merely enrich existing synced data like any other sync setup. A few things to note on this behavior:

  • Synced field names won’t match if the same field name is added to a target before it’s added in the source base. 

    • Example: If you create a field named “Date field” in target base C, then a field created in source base A named “Date field” would sync over to the target as another date field, but will be named “Date field 2”

  • Field names won’t match if they are changed in targets, even if they are changed back to match the naming in the source sync.

• Workaround: Create a form for other teams can use to request “global” changes be made to the source base instead of adding “enriched” fields that won’t sync back to the source or other targets. Additionally, consider using a naming structure for target bases to help prevent field names syncing in a way that doesn’t match.

• Explanation: We cover synced field customization in this support article. Fields that are customized in a target will no longer match the source. This causes any customized fields in a two-way sync target to no longer be editable. However, the field will still sync with the source and update similar to a one-way sync.

• Workaround: There are many potential workarounds for this depending upon the particular scenario you are encountering. If you find this to be a blocker, then please provide feedback to us in the form listed near the top of this article.

• Explanation: For security reasons, tables in target bases with two-way sync enabled will not be able to be “side-chained” with other bases. For example, let’s say base A is the source of the sync. Three target tables (inside bases B, C, and D) are connected to the source with two-way sync turned on. If you then wanted to set up any of these target tables to have two-way sync enabled in another base (base E), you’d be unable to do so. 

• Workaround: Sync the other base (base E) with the original source sync (base A) that was set up. Note that if base E only needs to be a one-way sync target, then it’s fine to sync from any of the base targets (bases B, C, or D).

• Explanation: For syncs that utilize multi-source syncing, the expected behavior may not be apparent. Additionally, multi-source syncs do not support two-way syncs that allow record creation and/or deletion.

• Example: Let's say there are 2 source bases (base A and base B). Base A has two-way sync toggled on, however, base B does not have 2-way sync enabled. In the target, base C, every source must have two-way sync enabled in order for the table to be editable. In this example, base C would function as only a one-way sync from both sources. To remedy this, an owner or creator from base B would need to turn on two-way sync in order to allow base C to utilize two-way syncing functionality.

When you configure a table sync, you can choose to manually or automatically sync changes to your base. Automatic syncing occurs in real-time ¹.

¹ Time-based formula fields (and all dependent columns) will not be instant – instead, they will periodically update. Table syncs with Field Type Customized Linked Records will not be instant – instead, they will periodically update.

Yes. Views containing more than 200,000 cells (e.g. 10k records x 20 fields) are not available for use as a two-way sync source.

Just as with one-way sync, in the target table, any changes will be attributed to “Table Sync.”

Yes. This option is covered here.

No. Just like in a one-way sync, that field will appear in, and be owned by, the target base.

Field type customizations are specific to the target base and won’t apply to source bases.

Yes, for more information consult this information.

Yes, however, you’ll want to consult this section of the support article to understand how to enable this functionality and its implications fully.