- Getting started with Airtable
- Introduction to Airtable basics
- Contacting Airtable Support Updated
- Airtable home screen
- Glossary of Airtable terminology
- Airtable technical requirements
- Feature differences between Airtable on desktop and mobile
- Airtable keyboard shortcuts
- Using Markdown in Airtable
- Adding descriptions in Airtable
- Finding Airtable IDs
- Airtable Automations
- Automations Overview
- Automation feature walkthroughs
- Integrated automation walkthroughs
- Airtable automation walkthroughs
- Linking existing records using automations
- Conditional groups of automation actions
- Repeating groups of Airtable automation actions
- Creating recurring records using automations
- How to delay Airtable automation runs
- Prevent automations from triggering by mistake
- Use automations to timestamp status updates
- Automation Triggers
- Airtable Triggers
- Airtable automation trigger: When record matches conditions
- Airtable automation trigger: When a form is submitted
- Airtable automation trigger: When record created
- Airtable automation trigger: When record updated
- Airtable automation trigger: When record enters view
- Airtable automation trigger: At scheduled time
- Airtable automation trigger: When webhook received
- Airtable automation trigger: When a button is clicked
- Airtable automation trigger: When email received Updated
- Integrated Triggers
- Airtable Triggers
- Automation Actions
- Airtable Actions
- Airtable automation action: Send email Updated
- Airtable automation action: Create record
- Airtable automation action: Update record
- Airtable automation action: Find records
- Airtable automation action: Sort list
- Airtable automation action: Run a script Updated
- Airtable automation action: Generate with AI
- Integrated Actions
- Airtable automation actions: Slack
- Airtable automation actions: Google Workspace
- Airtable automation action: Send MS Teams message
- Airtable automation actions: Outlook
- Airtable automation actions: Jira Cloud
- Airtable automation actions: Jira Server / Data Center
- Airtable automation actions: Salesforce
- Airtable automation action: Create post in Facebook Pages
- Airtable automation actions: GitHub Issues
- Airtable automation action: Hootsuite post
- Airtable automation action: Send Twilio SMS
- Airtable Actions
- Airtable Bases
- Using Airtable Cobuilder
- Airtable bases overview
- Creating and managing Airtable bases
- Structuring bases in Airtable
- Moving bases between workspaces in Airtable
- Creating and managing tables in Airtable
- Creating Airtable base share links
- Importing third-party data into Airtable
- Using insights in Airtable
- Troubleshooting Airtable base performance
- Airtable Betas
- Collaborating in Airtable
- Airtable Enterprise Support
- General Enterprise information
- External badging in Airtable
- Using app library and components in Airtable Updated
- Ask an Expert beta overview
- European data residency at Airtable
- Airtable user groups overview
- Airtable Enterprise API
- Creating and managing data retention policies in Airtable
- eDiscovery APIs in Airtable
- Airtable and data loss prevention
- Accessing Enterprise audit logs in Airtable
- Set up Jira Server / Data Center to connect with Airtable
- Admin panel pages
- Airtable admin panel overview
- Users - Airtable enterprise admin panel
- Airtable admin panel user details
- Groups - Airtable admin panel
- Workspaces - Airtable Enterprise Admin Panel
- Bases - Airtable admin panel
- Interfaces - Airtable admin panel
- Data sets - Airtable admin panel
- Managed apps - Airtable admin panel
- Components - Airtable admin panel
- Reports - Airtable admin panel
- Settings - Airtable admin panel Updated
- Managing Enterprise organizations
- Managing Enterprise admins in admin panel
- Using Organizations
- Organization branding for apps in Airtable
- Enterprise Hub in Airtable
- Enterprise Hub: Org unit assignment with user groups Updated
- Deactivating, removing access, and reactivating users in the admin panel
- Managing user access to workspaces and bases
- Airtable Enterprise Key Management Updated
- Custom terms of use New
- Enterprise SSO
- General Enterprise information
- Airtable Extensions
- Airtable Fields
- Fields Overview
- Attachment
- Date-based fields
- Formula
- Getting Started with Formulas
- Formula Foundations
- The essentials of Airtable formulas
- Formula writing tips for beginners
- Troubleshooting formulas
- Basic calculations
- Conditional statements
- Logical arguments
- Working with dates
- Displaying DATETIME_FORMAT using the date field in Airtable
- Working with date functions in Airtable
- Calculating the difference between dates in Airtable
- Supported DATETIME_DIFF unit specifiers in Airtable
- Supported DATETIME_FORMAT format specifiers in Airtable
- Using the DATETIME_PARSE() formula in Airtable
- Working with timezones
- Record functions
- Text functions
- Numeric functions
- Common Solutions: Beginner
- Common Solutions: Intermediate
- Common Solutions: Advanced
- Long Text Field
- Linked Record Field
- Linking records in Airtable
- Limiting linked record selection to a view in Airtable
- Dynamic filtering in linked record fields
- Linking to one, many, or a subset of Airtable records
- Converting existing fields to Airtable linked records
- Reordering record links in Airtable
- Understanding linked record relationships in Airtable
- Number-Based Fields
- Other Fields
- Rollup, lookup, and count fields
- Select and user fields
- Integrating with Airtable
- API
- Getting started with Airtable's Web API
- Creating personal access tokens
- Airtable Webhooks API Overview
- Service accounts overview
- Airtable Web API - Using filterByFormula or sort parameters
- Airtable API Deprecation Guidelines
- Airtable API: Common troubleshooting
- Managing API call limits in Airtable
- URL length limitations for web API requests
- Integration services
- Third-party integrations via OAuth overview
- Troubleshooting disconnected OAuth integrations in Airtable
- Options for integrating with Airtable
- Third-party integrations - Common troubleshooting
- Low-code integrations - Common troubleshooting
- Integrating Airtable with external calendar applications
- Visualizing records from Airtable in Tableau
- Visualizing Airtable records in Microsoft Power BI & Power Query
- Integrating HubSpot with Airtable
- Using Zapier to integrate Airtable with other services
- Using Zapier's Multi-Step Zaps to find and update records
- Using IFTTT to integrate Airtable with other services
- Integrating with AWS Lambda & DynamoDB
- Developer tools
- API
- Airtable Interface Designer
- Interface Designer overview articles
- Interface layouts
- Interface elements
- Adding and removing elements in interfaces
- Adding layouts to interfaces
- Formatting elements in interfaces
- Interface element: Button
- Interface element: Calendar
- Interface element: Chart
- Interface element: Filter
- Interface element: Gallery
- Interface element: Grid
- Interface element: Kanban
- Interface element: Number
- Interface element: Record picker
- Interface element: Text
- Interface element: Timeline
- Learning and Resources
- Managing Airtable
- Airtable Policy
- Airtable Records
- Airtable Sync
- Airtable Views
- Airtable Workspaces
- Print
- Share
- DarkLight
- PDF
Similar to other surfaces throughout Airtable, you'll want to consider permissions settings when enabling sync for a shared view. But there are even more considerations to understand related to the Airtable sync feature, especially when enabling Two-way sync behavior. Learn about these considerations in this article.
General permission restrictions
Synced tables offer the same restrictions as share links, specifically password and domain restrictions.
If a password is set, the creator of the synced table will be required to provide the password.
If a domain restriction is set, only users with the specified email domain will be able to create a synced table based on the data in the shared view.
While these permissions can help to secure your Airtable information, it's important to know that setting restrictions or changing permissions can cause existing synced tables to "break" and no longer sync. Collaborators may be required to reconfigure their synced tables to resume syncing. These scenarios are described in more detail below.
General permission scenarios
A password is set or changed on a syncable view share link - The chosen password will be needed by the sync destination creator in order to set up the sync. If a password is added or changed after a sync has been successfully setup, then all all synced tables that sync from the view will break.
An email domain restriction is set or changed on a syncable view share link - If the destination creator does not have the matching email domain attached to their Airtable account, they will not be able to set up the sync. Additionally, if a destination creator sets up a synced table and is removed from the destination base, then the sync will break and require reconfiguration before the sync is reestablished. If a domain restriction is added or changed after synced tables have been set up, existing syncs that are created by users with an email domain that does not match the new restriction will break.
A sync source creator with proper domain is removed as a collaborator from the destination base - If the email domain restriction is turned on for a syncable share link and a destination creator with the proper domain is removed from the destination base, then the sync will break. Another creator on the destination base with the correct email domain will need to reconfigure the sync.
A new syncable view share link URL is generated - All tables syncing from the view will break. It will be necessary to reconfigure the sync in the destination base again.
Sync is disabled for the view share link - All tables syncing from the view will break. It will be necessary to reconfigure the sync in the destination base again.
Two-way sync permission scenarios
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:
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.
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.
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.
Click here for a table that outlines various combinations of settings to better understand the resulting behavior in a sync destination:
Source permissions | Destination permissions | Destination result |
---|---|---|
Two-way editable (All editable fields enabled) | Not restricted (Editors and up) | Collaborators with editor permissions or higher can edit synced records. |
Two-way editable (All editable fields enabled) | Semi-restricted (Creators and up) | Only collaborators with creator/owner permissions can edit synced records. |
Two-way editable (All editable fields enabled) | Fully restricted (No one allowed) | The destination table is not editable, similar to a one-way sync. Creators can adjust a sync's settings to turn two-way sync on in the future. |
Two-way editable (Only certain fields editable) | Not restricted (Editors and up) | The destination table will allow edits by editors, creators, and owners in the fields made editable in the sync source configuration. |
Two-way editable (Only certain fields editable) | Semi-restricted (Creators and up) | Destination will only allow edits by creators or owners in the fields made editable in the sync source configuration. |
Two-way editable (Only certain fields editable) | Restricted (No one allowed) | The destination table's permissions settings override the editability set in the source. This means the sync functions similar to a one-way sync. The destination table will not be editable unless the destination permissions setting is changed. |
Not two-way editable | N/A | Destination table is not editable (One-way sync) |
Note
In general, individual field permissions that have been set in the source table will not transfer to a destination. To restrict access to certain fields either select specific editable fields in the sync source configuration or work with destination base owners to ensure that only certain individuals have permissions to edit specific fields in the destination. There is one exception: if a certain field permission in a source has been set to allow nobody to edit the field, then the field will also be uneditable in any destination.
Sync configuration permissions
![](http://cdn.airtable.document360.io/d0ee2ee4-3f78-47c7-b388-85e40be9fb89/Images/Documentation/two_way_sync_choose_source_09192022.jpeg)
End users are only able to choose shared views in bases where they have editor-level permissions or higher. For users with access to only certain bases or workspace collaborators who have commentor or read-only permissions this means that when creating a synced table in a base, every syncable shared view in their organization's larger Airtable ecosystem will may not be available for them to choose from.
Notes on this change:
This is so that users without edit permissions in the source base are not able to set up a backdoor way for them to edit the source. 
Example: If a read-only collaborator is able to select a sync source that allows edits from destination bases, then they will be able to perform edits in the target base which will then propagate to the source.
Read-only collaborators explicitly given share linksare still able to do the above but the additional step acts as a safeguard.
This adds a step to set up a sync for collaborators with read/commentator access only. Users will have to explicitly ask a user with editor or higher permission access in the source base for a share link in order to sync from the source view.
Existing syncs will not be affected.