Two-way sync dependencies

Two-way sync allows existing records to be edited in one or more destination tables and synced back to a single-source-of-truth table. In this article, we will walk you through some of the more advanced concepts related to this feature. Specifically, considerations relating to who has editing rights as well as some best practice tips and notes.

Security and Permissions

Since the two-way sync feature allows for collaboration across Airtable surfaces, it’s important to think about which fields will be editable for users not collaborating in the original source base. Below, we’ll cover various scenarios to help you better manage who can update what. In general, there are three settings to be aware of when considering which information will be editable in a destination:

1. Sync source settings - A sync source view’s configuration can be set to not allow edits in destinations, allow all fields to be editable, or only allow specific fields to be editable.
2. Sync destination settings - A destination’s sync configuration can be set to restrict anyone from editing, allow editors or higher to edit synced records, or only allow creator/owners to edit.
3. Individual field/table editing permissions - Field permissions are covered in this support article. If a synced field is editable in the source and destination settings, additional editing permissions can be applied to specific fields that will further lock down editing access.

The table below outlines various combinations of settings to better understand the resulting behavior in a sync destination.

Tips and notes

Below we’ll cover some helpful best practice tips, limits, and functionality notes. These are worth digging into and fully understanding as they will help you create more efficient workflows that involve two-way sync.

Records can only be created in the source view

• 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 destination 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.

Fields created in destination syncs do not sync back to the source

• Explanation: New fields can be created in destination 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 destination before it’s added in the source base. 
    • Example: If you create a field named “Date field” in destination base C, then a field created in source base A named “Date field” would sync over to the destination as another date field, but will be named “Date field 2”
  • Field names won’t match if they are changed in destinations, 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 destinations. Additionally, consider using a naming structure for destination bases to help prevent field names syncing in a way that doesn’t match.

Customized fields in destination bases become non-editable

• Explanation: We cover synced field customization in this support article. Fields that are customized in a destination will no longer match the source. This causes any customized fields in a two-way sync destination 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.

Sync update parity behavior

• Explanation: When setting up multiple destination syncs, it’s important to remember that syncs may not occur automatically or instantaneously in destination tables. Data edited in destination base B, will occur in the source base A in close to realtime. However, destination base C may not have synced recently whether that destination is set to sync manually or automatically. If a destination base has not synced, any new information added may present conflicts if something is edited in base C. 
• Workaround: In a destination table, it’s best practice to configure the base to sync automatically. This will cause the base to sync with the source every 5 minutes or so. Additionally, manually syncing the base before each editing session is a good idea, just to make sure everything is up-to-date.
  

"Side-chaining" two-way syncs is not possible

• Explanation: For security reasons, tables in destination 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 destination 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 destination 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 destination, then it’s fine to sync from any of the base destinations (bases B, C, or D).

Multi-source syncing is possible, but there are considerations

• Explanation: For syncs that utilize multi-source syncing, the expected behavior may not be apparent. 
• 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 destination, 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.