Sandbox Workspace
A Sandbox workspace is a separate workspace linked to a paying ("parent") workspace, for testing new setups, automations, or configurations in a clean environment.
Key characteristics
- One per paying workspace — each paying workspace owner can create only one.
- Starts completely empty — nothing is copied from the parent workspace on creation.
- Same limits and credits as the parent, but not shared — e.g. if the parent has a limit of 1,000 automations, the sandbox also gets 1,000, for 2,000 available in total across both.
- Fully isolated — activity in the sandbox doesn't affect the parent's data, usage, or limits.
Typical uses: testing new automations or workflows, trying configurations before applying them to production, validating changes without risking live data.
Syncing a sandbox from production
Production-to-sandbox data sync may be available as a paid add-on.
A sync pulls a representative slice of production's structure and data into the sandbox, so it mirrors production without carrying its full volume.
What gets copied: structure (spaces, types with their attributes and icons, workflows with states/transitions/conditions), a sample of objects per type with their attribute values, automation rules, and sites (apps).
Configurable per sync, via checkboxes framed as what to include rather than what to skip: Sync objects (checked by default — unchecking it syncs structure only), Sync automations, and Sync sites (both unchecked/opt-in by default, since copying them is a heavier action).
Confirmed against SyncSandbox.tsx: only "Sync objects" defaults to checked. "Sync automations"
and "Sync sites" default to unchecked — the component's own code comment calls this deliberate,
since copying automations and sites is heavier than copying just structure. The backend flags are
still named skipObjects/skipAutomations/skipSites (inverted from the UI's checked state), but
the sync-configuration screen itself presents them as positive "Sync X" checkboxes to include, not
"skip X" checkboxes to exclude.
Object limit: up to 50 objects per type, not 50 total — a workspace with many types can sync more than 50 objects overall.
Behavior notes:
- Synced automation rules are always created disabled, so nothing fires unexpectedly.
- The workspace owner or an admin can run a sync.
- Every space in the parent workspace is copied — including ones the syncing user can't open — with each copied space carrying over its original permissions. Access in the sandbox still follows those permissions, so a sync doesn't expose anything the user couldn't already see.
- A sync wipes the sandbox's existing data first, then copies fresh data from production.
Confirmed against SyncSandboxDataPolicy (OWNER or ADMIN, not owner-only) and
SandboxSyncService.allSpaces(), whose own doc comment says every space is copied regardless of
the syncing user's access, with permissions copied alongside — the original migrated text had
this backwards, describing an access-based space filter that doesn't exist.
Mockup, not a screenshot — confirmed against pages/Settings/SyncSandbox.tsx, rendered as a "Sandbox" section row on the sandbox workspace's Settings > General page (only visible there, gated by the manageSandboxData permission).
Mockup, not a screenshot — confirmed against SyncSandbox.tsx. Note the checkboxes are framed positively ("Sync X" = include), with only "Sync objects" checked by default; "Sync automations" and "Sync sites" are unchecked/opt-in, since the component's own code comment calls copying them a heavier action than copying structure.