Runbook - App Sandbox Activations for Mission-Critical Airtable Systems

Step-by-step guide for app sandbox activations in mission-critical Airtable systems.

Runbook for enterprise environments (large bases, heavy automations, external integrations).

0) Change Governance (Mandatory for Mission-Critical Systems)

0.1 Internal Change Request (Request & Solutions System)

• Create an internal Request & Solutions ticket before any Sandbox activation
• Classify the change as:
  • Special Procedure
  • Planned Production Change
  • Potential Operational Impact
• Include in the request:
  • System name (e.g., Invercorp / Singular Agile)
  • Airtable Base/App ID
  • Organization ID
  • Scope of changes (schema, automations, interfaces, etc.)
  • Risk level (Mission-Critical System)
  • Maintenance window (date, time, timezone)
  • Rollback and validation plan
• Explicitly state:
  • “This procedure involves App Sandbox activation, which may temporarily affect system operability and structural editing in production.”
• Obtain internal approval from:
  • Chapter Lead / Technical Lead
  • Project Owner / Stakeholders
  • Operations (if client-facing system)

1) Pre-Activation Planning (T-14 to T-7 days)

1.1 Architecture & Dependency Mapping

• Create an inventory of:
  • Tables + critical linked relationships
  • Critical views (especially those used by stakeholders daily)
  • Interfaces (client-facing and internal ops)
  • Extensions (anything powering monitoring/reporting)
  • Synced tables (especially two-way)
  • Automations (grouped by internal vs external actions)
  • External integrations (APIs, n8n, Make, Zapier, custom services)
• Identify “blast radius” components:
  • High-impact automations
  • Client-facing dashboards
  • Regulatory/financial workflows
  • Any workflows tied to external SLAs

1.2 Sandbox Activation Blockers (Must fix before you attempt)

• Remove/refactor personal views referenced by:
  • Automations
  • Filters
  • Any dependency chain (this can block Sandbox enablement)
• Identify locked/collaborative views underpinning critical filters/sorts

1.3 AI, Matching, and Gantt Constraints

• Finalize AI field configurations (no pending changes)
• Finalize AI-linked record matching rules
• Plan significant Gantt configuration changes outside the Sandbox period

1.4 Plan Capacity & Timing

• Confirm base scale (rows + attachment GB)
• Allocate extra time: Sandbox creation may take several minutes or longer for large bases
• Select an off-peak maintenance window
• Prepare a structured validation checklist for the post-apply phase

2) Pre-Activation Hardening (T-7 to T-1 days)

2.1 Automation Safety Strategy (Critical in Sandbox)

• List automations with external actions (email, Slack/Teams, SMS, webhooks/APIs, scripts interacting externally, Google Workspace, Jira/Salesforce/GitHub, etc.)
• Confirm the team understands:
  • External-facing automation actions are skipped by default in Sandbox
• Decide how you will test:
  • Prefer “Test automation” runs
  • Only run end-to-end flows if external systems can tolerate test events

2.2 Integration Testing Plan (Sandbox is a separate base)

• Document all integration endpoints (Production)
• If validation against Sandbox is required:
  • Prepare separate Sandbox configs in n8n/Make/Zapier/custom backends
  • Ensure no production data is accidentally triggered
• Confirm stakeholders understand:
  • External tools connected to Production will not automatically reference Sandbox

2.3 Sync Table Plan

• Document all two-way syncs
• Confirm stakeholders understand:
  • Two-way sync tables are effectively static/read-only in Sandbox
• Define what “acceptable testing” looks like without live sync behavior

2.4 Support Readiness (Enterprise without Premium Support)

• Open a pre-activation Support ticket 1 day before the window
• Include:
  • Organization ID
  • App/Base IDs
  • Approx. record counts + attachment volumes
  • Maintenance window (date, time, timezone)
  • Intended change scope
• Define escalation wording if incident occurs:
  • Reply to the ticket with: “URGENT - Production Impact”
  • Include explicit impact (blocked workflows, client-facing disruption, external SLAs at risk)

Optional:

• Book an Ask an Expert (AAE) session to review approach before first activation

3) Activation Day - Create Sandbox (T-0)

3.1 Pre-Flight (30-60 minutes before)

• Confirm maintenance window started and stakeholders notified
• Freeze structural edits in Production during the Sandbox lifecycle
• Confirm “known good state”:
  • No pending AI changes
  • No urgent schema changes in progress
  • No personal view dependencies remain
• Confirm incident lead + escalation path ready (support ticket exists)

3.2 Create Sandbox

• In Production base: Base menu -> ”+ Create sandbox”
• Allow sufficient time for creation to complete (large bases may take minutes+)
• Confirm Sandbox is created successfully before proceeding

4) Make Changes in Sandbox (Only)

4.1 Structural Change Execution

• Perform ALL configuration changes in Sandbox:
  • Schema updates (tables/fields/relationships)
  • Automations (logic, triggers, conditions, actions)
  • Interfaces
  • Extensions
• Avoid editing production structure while Sandbox is active
• Keep a written change log (what changed, why, who)

4.2 Testing Approach

• Validate views and interfaces in Sandbox
• Validate automations:
  • Prefer “Test automation” runs
  • Confirm intended behavior without external actions firing
• If end-to-end tests are required:
  • Carefully disable “Skip actions in sandbox” for specific automations only
  • Confirm external systems can tolerate test events

5) Apply Changes to Production (Controlled Deployment)

5.1 Review Changes

• Production/Sandbox -> “Review changes”
• Validate the change list carefully:
  • Applied items overwrite corresponding Production configuration

5.2 Apply in Batches (Recommended)

Batch 1: Schema

• Apply schema changes first
• Validate critical workflows immediately after

Batch 2: Automations

• Apply automation changes second
• Validate key automation runs and logs

Batch 3: Interfaces/Extensions

• Apply interfaces and extensions last
• Validate dashboards and client-facing views

Stop Rule:

• If validation fails or impact is detected, halt further applies and execute incident process

6) Post-Apply Validation (Production)

6.1 Validate Mission-Critical Surfaces

• Interfaces and client-facing dashboards
• Critical views and filters
• High-impact automations + logs
• Integration points (confirm nothing unintended is firing)
• Sync behavior (and reconcile expectations)
• Record counts consistency where relevant

6.2 Watch for Schema Drift

• Confirm no new fields/options/views were added in Production during Sandbox lifecycle
• If drift exists:
  • Reconcile before finalizing
  • Document differences

7) Close the Window

• Confirm success criteria met
• Communicate completion to stakeholders
• Delete Sandbox when stable to restore normal structural editing in Production
  • Note: Sandbox copy moves to workspace trash as a separate base for reference

8) Incident Playbook (If Something Goes Wrong)

• Immediately assess severity:
  • Production workflow blocked?
  • Client-facing processes affected?
  • External SLAs at risk?
• Escalate via the pre-activation ticket:
  • Reply with “URGENT - Production Impact”
  • Provide concrete symptoms, timeframe, and affected components
• Contain impact:
  • Pause further applies
  • Revert by not applying additional changes
  • Implement targeted corrective changes as a follow-up batch
• Document root cause + preventive actions

9) Continuous Improvement (After First Activation)

• Run a retrospective:
  • What caused delays?
  • Which validations were missing?
  • Where did users get confused?
• Improve your checklist + templates
• Consider Premium Support if you routinely run mission-critical windows needing faster SLA guarantees