How to Safely Make Changes in Airtable Without Breaking Production

If your Airtable base is something people rely on daily, making structural changes directly in the live base is risky. Changing a field type, modifying an automation, or updating an interface can break something mid workday.

Airtable's App Sandbox lets you make changes in a separate development environment while your team keeps working in the production version. When you are done, you review a list of changes and choose which ones to push to production.

Plan Availability

App Sandbox is available on Business and Enterprise Scale plans only. It is not available on Free or Team plans.

You need Workspace Owner or Creator permissions to create a sandbox. To apply changes from sandbox to production, you need Creator permissions in both the sandbox and the production base.

How to Create a Sandbox

  • Open your Airtable home screen

  • Open the base where you want to create the sandbox

  • Click the dropdown arrow next to your base name in the top bar

  • Click + Create sandbox

Creating the sandbox can take several minutes for large bases. Once it is ready, a Production / Sandbox toggle appears in the top bar. Click Sandbox to switch to the development environment.

You can only have one active sandbox per base at a time.

Split-screen Airtable sandbox and production workflow showing safe testing before deployment

What Gets Locked When a Sandbox Exists

Once a sandbox is active, structural changes cannot be made in production, even by Owners and Creators. Production effectively behaves like an Editor environment for structural changes. People can still view and edit records normally, but adding fields, changing field types, modifying automations, and editing interfaces can only be done inside the sandbox.

The one exception is views. Personal and collaborative views can still be created and edited in production while a sandbox is active. Only locked views are restricted to the sandbox.

This means if you create a sandbox and your team is used to adding fields or creating locked views themselves, they will be blocked from doing that for the duration. Communicate this before creating a sandbox.

How Views Behave in the Sandbox

Views work differently from the rest of the base in a sandbox:

Personal views do not appear inside the sandbox at all. You cannot create personal views in a sandbox. Importantly, if your base has any personal views used as dependencies, for example as an automation trigger or view filter, the sandbox cannot be created. Those dependencies need to be removed or converted first.

Collaborative views can be created and edited in both sandbox and production. However, they can only be deleted from the sandbox while it is active.

Locked views can only be created, edited, deleted, and reorganized inside the sandbox while one is active.

How Automations Behave in the Sandbox

This is the part most people do not expect. By default, automations in the sandbox skip any action that sends notifications or connects to external systems. This includes:

  • Send email

  • Send Slack message

  • Send Microsoft Teams message

  • Run script (because scripts may connect to external systems)

  • Append row to Google Sheet

  • Create or update a Google Doc

  • Create or update a Jira issue

  • Create or update a Salesforce record

  • Post to Twitter/X, Facebook, HootSuite

  • Create or update a Google Calendar event

  • Create or update a Microsoft Outlook event

  • Send an SMS with Twilio

  • Create or update a GitHub issue

The automation runs, but these specific actions are skipped silently.

To test an automation in full, including the external actions, use the Test automation button inside the sandbox. Manual tests run the complete automation, including all skipped actions.

Alternatively, you can toggle off Skip actions in sandbox on individual automations. This option is found just below the automation's trigger in the Automations tab. When toggled off, that automation runs in its entirety including external actions when triggered automatically.

Records Created in Sandbox Stay in Sandbox

Records you create or edit inside the sandbox do not carry over to production when you apply changes. Only structural changes, such as fields, automations, interfaces, and views, can be applied.

This means you can safely create test records in sandbox to verify your formulas and automations are working, without worrying that test data ends up in your live base.

Extensions in the Sandbox

Extensions settings can be edited simultaneously in both production and sandbox. However, there is an important risk here: when you apply extension changes from sandbox to production, those changes overwrite any edits to extension settings that were made in production since the sandbox was created.

If anyone edited extension settings in production while the sandbox was active, those edits will be lost when you apply. Review extension changes carefully before applying.

Applying Changes to Production

When your development work is done:

  • In the sandbox, click the dropdown arrow next to the Production / Sandbox toggle

  • Click Review changes

  • A list of every structural change made in the sandbox appears

  • To apply all changes, click Apply changes

  • To apply only specific changes, hover over individual items and use the checkboxes to select them before applying

This selective apply is useful when you want to ship part of your work but hold back something that needs more testing.

To apply changes, you need Creator permissions in both the sandbox and the production base. If you have sandbox Creator permissions but not production Creator permissions, you will see a permission error in the review modal.

Deleting a Sandbox

To delete a sandbox without applying its changes:

  • Open the base with the sandbox enabled

  • Click your base name

  • Click the ... icon next to the sandbox name

  • Click Delete sandbox, then confirm

When you delete a sandbox, all unpublished changes are moved to your workspace trash. They can be restored from trash as a separate base, but they are not restored as a sandbox of the original base.

Deleting the sandbox returns production to normal - structural changes can be made directly in production again.

Unsupported Features in Sandbox

Some things cannot be changed while App Sandbox is enabled:

  • Gantt views: changes to Gantt views are not supported in the sandbox

  • AI linked record matching in linked record fields

  • Two way sync tables: these are static and read only inside the sandbox

  • Field type changes that depend on pending sync or AI Field Agent changes: you need to apply those pending changes to production first before the field type conversion can proceed

What About Permissions? Does Everyone Get the Same Sandbox Access?

No. The sandbox is treated as a separate base for permissions. Workspace collaborators automatically have the same access level in the sandbox as they do in production. But base level collaborators do not carry over. They need to be invited to the sandbox separately.

This means you can invite external developers or contractors into the sandbox without giving them production access, or give a team member sandbox Creator access without upgrading their production permissions.

Invitation emails currently do not differentiate between Production and Sandbox, which can be confusing. Airtable is aware of this and working to improve it.

When You Are Not on Business or Enterprise

If you are on the Team plan and cannot access App Sandbox, the alternatives are:

Take a manual snapshot before making changes. Click the clock icon in the top bar, go to Snapshots, and take a snapshot. This gives you a restore point. The tradeoff is that restoring a snapshot creates a new base with a new app ID, which can break external integrations. So it is a recovery mechanism, not a development environment.

For more on how snapshots work and the plan-level retention differences, see How to Back Up Your Airtable Bases (And Restore Them Safely).

Duplicate the base into a test workspace. Create a duplicate, make your changes there, verify everything works, then replicate the same changes in production manually. More effort than Sandbox but achieves a similar outcome.

Make changes in off-peak hours and one at a time. Make one structural change, verify nothing broke, then proceed to the next. This limits the blast radius if something goes wrong.

For managing who has the permissions needed to make structural changes in the first place, see How to See and Manage User Permissions in Airtable.