Business and Enterprise Scale plans | |
There are additional important concepts related to App sandbox permissions outlined in this support article section.
| |
Platform(s) | Web/Browser, Mac app, and Windows app only |
App sandbox allows builders to create a sandbox for their base—a safe environment where they can make changes to tables, fields, automations, etc., without impacting their production base. While a sandbox exists, other collaborators can still view and edit data in the ‘production’ version of the base. Structural changes made in the sandbox can later be reviewed and applied to production when ready.
Enabling App sandbox for bases in Airtable
To enable App sandbox for a specific base:
Open your Airtable home screen.
Open the base where you want to enable the App sandbox.
Click the dropdown arrow next to your base’s name.
Click + Create sandbox.
Creating sandboxes may take several minutes for large bases.
If the option to click + Create sandbox is unavailable, try reloading the page first. Then, check that you have the appropriate permissions at the workspace level. If neither of these steps solves your issue, then contact our Support team.
Click Sandbox in the “Production / Sandbox” toggle that appears in the top bar.
Changes to fields, relationships, views*, automations, and interfaces must be made in your base’s sandbox and cannot be made in production when a sandbox is created.
While data can be viewed and edited in production, the production experience becomes similar to being an editor—meaning options to edit a base structure—like adding a new field, are not available.
Note
Views are treated differently when App sandbox is enabled. Personal and collaborative views can be created and edited in production, but locked views can only be created, edited, and deleted in App sandbox.
Viewing and applying changes made to your base while using App sandbox
App sandbox allows you to review a list of changes made in your sandbox and the ability to apply those changes back to production.
To review changes made to your base while using App sandbox:
Open your Airtable homepage.
Open the base with App sandbox enabled.
Click Sandbox in the “Production / Sandbox” toggle that appears in the top bar.
Click the dropdown arrow next to the “Production / Sandbox” toggle.
Click Review changes.
To apply changes from your sandbox to production:
Open your Airtable homepage.
Open the base with App sandbox enabled.
Click Sandbox in the “Production / Sandbox” toggle that appears in the top bar.
Click the dropdown arrow next to the “Production / Sandbox” toggle.
Click Review changes.
Click Apply changes.
Note
To select individual changes, use the checkboxes that appear when hovering on individual changes.
Using views in App sandbox
Personal, collaborative, and locked views behave differently in sandbox than in production when App sandbox is enabled.
Personal views
Personal views will not appear in your base’s sandbox.
New personal views cannot be created in your base’s sandbox.
App sandbox cannot be enabled for bases with personal views that are a dependency for other Airtable functionality like automation triggers or view filters. In these instances, App sandbox will fail when you attempt to enable it.
When App sandbox is enabled for a base, personal views can be created, edited, deleted, and reordered in production—not in your base’s sandbox.
Colleagues who are not builders making changes in your base’s sandbox can continue using personal views while you are making larger changes in your base’s sandbox.
Collaborative views
When the App sandbox is enabled, collaborative views can only be deleted in sandbox
You can create, edit, and reorganize collaborative views in both your base’s sandbox and production experience.
Locked views
Creating, editing, deleting, and reorganizing locked views in production is unavailable while App sandbox is enabled.
When App sandbox is enabled for a base, you must create, unlock and reorganize locked views in your base’s sandbox.
Using automations in App sandbox
How are automations different when using App sandbox?
Automations function in similar ways while using the App sandbox as they do in bases without the App sandbox enabled, with one key difference: When an automation contains any actions that send notifications (e.g., emails or Slack messages) or integrate with external systems—like Jira or Salesforce—all actions in that automation are "skipped," meaning that they do not run automatically.
How do I ensure my automations work in my base’s sandbox as they do in production?
You can run automations in your sandbox in their entirety—including sending notifications and data to external systems—by using the "Test automation" functionality. When you manually test an automation in your sandbox, all actions run, even when sending notifications or data to external systems.
Alternatively, you can configure an automation to run in its entirety by toggling the "Skip actions in sandbox" toggle off when viewing that automation in the “Automations” tab. The toggle can be found immediately below the Automation's trigger.
Which automation actions are skipped when using App sandbox?
Run script (Scripts may integrate with external systems)
Send email
Send Slack message
Send Microsoft Teams message
Append row to Google Sheet
Create response to Google Form
Create or update an event in Google Calendar
Create or update a Google Doc
Create or update an issue in JIRA
Create or update a record in Salesforce
Post a tweet to Twitter/X
Create a post on a Facebook page
Create or update an event in Microsoft Outlook
Schedule a post with HootSuite
Create or update an issue in GitHub
Send a SMS with Twilio
Deleting App sandboxes
Workspace Creators can delete sandboxes for any base in that workspace. When App sandbox is removed, production reverts to normal base behavior so that structural changes can be made in production again.
After deleting your sandbox, all changes—including unpublished changes—are moved to your workspace trash. While those changes can be restored from your workspace trash as a separate base, they are not restored as a sandbox of the base they were previously associated with.
To delete App sandbox:
Open your Airtable homepage.
Open the base with App sandbox enabled.
Click on your base’s name.
Click the … icon next to your sandbox’s name.
Click Delete sandbox, then Delete sandbox a second time to confirm.
Understanding App sandbox permissions
Sandbox is effectively treated as a separate base as it relates to permissions. Inviting collaborators occurs through the usual share modal, though permissions apply only to that environment – Sandbox OR Production. This means that users can be independently granted Sandbox-only Creator, Editor, Commenter, or Read-only permissions, allowing for granular access.
Additionally, emails sent to notify invited collaborators do not currently differentiate between Production and Sandbox. Our team is aware of this potentially confusing limitation and is working to improve clarity to that end.
When sandbox is enabled, structural edits are not allowed in the production base. This is true even for users who otherwise would normally be able to make changes to the base at their respective permission level.
The section below outlines the various permissions needed to perform different actions in a sandbox environment:
Creating a sandbox
Workspace Owners or Creators can create a sandbox environment.
Accessing a sandbox
Initially, workspace Owners/Creators can invite collaborators to a sandbox.
Sandbox collaborators can invite other users to that sandbox up to their permission level.
Production access is not required to collaborate in sandbox.
When sandbox is enabled, Creators accessing the Production version of the base will find that the base structure and configuration is locked.
An option to request access to the sandbox environment will be present in the top nav bar.
Building in a sandbox
Users with sandbox Editor permissions can adjust view configurations in a sandbox.
Sandbox Creator permissions are required for making any other types of configuration changes in a sandbox.
Applying changes to production in a sandbox
To apply changes from Sandbox to Production, Creator permissions in Sandbox and Production are required.
Sandbox Creators without the necessary Production permissions are notified of the permission issue in the change review modal if they try to apply changes.
FAQs
Can more than 1 sandbox exist for the same base simultaneously?
No. App sandbox only supports 1 sandbox per base. When App sandbox is enabled for a base, the existing version of the base is referred to as "Production," and builders with access to both sandbox and production can freely move between their production and sandbox.
Does my sandbox have the same collaborators as my production experience?
Yes, workspace collaborators are the same while base collaborators are not.
Your sandbox exists in the same workspace as the production experience, and workspace collaborators have the same access to your sandbox as they do in production. Additional collaborators can be added to your sandbox without needing to be added to production production and vice versa.
Can I manage production sharing even when sandbox is enabled?
Yes, managing production sharing, including things like shared view links, can still occur in production, even when App sandbox is enabled.
How does applying changes to views made in my sandbox affect my production experience?
Sandbox changes overwrite corresponding view settings in production.
Changes are applied at the granular level of view name, description, column order, filter, sort, grouping, color, and view section location.
For example, updating the filter setting in your sandbox overwrites the filter setting in production but does not impact your sort setting.
How is changing a field type different when App sandbox is enabled?
Airtable typically allows builders to change any field type to another field type and will attempt to convert any existing data to the new type.
When App sandbox is enabled, field type changes are generally allowed unless they are conversions whose result depends on:
Synced tables with pending configuration changes that have not been applied to production, or
AI Field Agents with pending configuration changes that have not been applied to production.
To make field type changes like these, you must first apply the pending changes to the sync or field agent to production.
These conversions are restricted since the resulting values rely on asynchronous operations that need to run after the pending change is applied before the conversion can occur. This restriction does not apply to column type changes to formulas, lookups, or calculations.
What Airtable features are not supported when App sandbox is enabled?
Note
You can use App sandbox with bases that use the features noted below, but making changes that involve these features is unsupported.
Making changes to extensions, Gantt views, and AI-linked record matching in linked record fields is not supported when the App sandbox is enabled.
How is two-way sync impacted when App sandbox is enabled?
Two-way sync tables are static and read-only in your base’s sandbox when the App sandbox is enabled.