Workspace Snapshots Overview

Workspace snapshots let you save configuration from a workspace and apply it to another workspace . Use them to onboard new subaccounts, clone a proven setup, share templates between organizations, or promote config from staging to production.

Snapshots capture workspace configuration — not contacts, conversations, messages, or other operational data.

What is a workspace snapshot?

A snapshot is a point-in-time bundle of selected workspace settings and resources from a source workspace .

How you get it	What it means
Created in your org	Captured from a workspace you own — shows which source workspace it came from
Imported from another org	Copied into your org from someone else’s snapshot (by snapshot ID) — useful for templates, partners, or white-label setups

Once a snapshot is in your organization , you can load it into any workspace in that org — whether you created it locally or imported it from elsewhere.

Typical things you can include:

Workspace settings
Contact custom fields, tags, and smart lists
Pipelines and workflows
Message templates and campaigns
AI configuration (agents, voices, folders)
Calendars and active schedules
Forms, websites, widgets, dashboards, and related assets

You choose which sections to capture and can optionally limit specific records within a section.

Creating a snapshot

Go to Organization settings → Workspace Snapshots .
Click Create snapshot .
Select the source workspace .
Name the snapshot.
Choose sections (and individual records if needed).
Save.

Tip: Capture everything the target workspace will need. If you only snapshot part of a setup, the load step can only restore what was captured.

Importing a snapshot from another organization

You do not have to create every snapshot yourself. If another organization shares a snapshot with you, you can import it into your org:

Go to Organization settings → Workspace Snapshots .
Choose Import snapshot (or equivalent).
Enter the snapshot ID they gave you.
If the snapshot is password-protected , enter the password.
Optionally set a name for the copy in your org.
Confirm import.

The system creates a copy of that snapshot under your organization. It is marked as an imported snapshot. You can then load it into your workspaces the same way as any snapshot you created locally.

Sharing snapshots out: When you create a snapshot, you can share its ID (and password, if enabled) with another org so they can import it. Password protection helps control who can pull in your template.

Note: Import brings the snapshot data into your org — it does not automatically load into a workspace. After import, run a load job to apply it to a target workspace.

Loading a snapshot

Loading copies snapshot data into a target workspace using a load job . A load job runs through resource types in order (fields before workflows, dependencies before dependents, etc.).

Open the snapshot you want to use.
Choose Load into workspace (or equivalent).
Pick the target workspace .
Review what will be included (load plan).
Set conflict policy if the target already has similar records.
Start the load.

Load jobs

A load job tracks one load operation from start to finish.

Field	What it means
Status	e.g. draft, processing, completed, failed
Progress	Steps completed out of total (by resource type)
Load plan	Sections and record IDs included in this run
Conflict policy	How to handle records that already exist in the target
Error message	Shown when the job fails — explains what stopped the load

When a job completes , configuration from the snapshot is applied to the target. When it fails , earlier steps may already have created or updated records — check the job detail for progress and error text before retrying.

Conflicts

If the target workspace already has a record that matches something in the snapshot (same name, slug, or other natural key), the loader treats it as a conflict .

Option	Behavior
Keep existing	Leave the target record as-is
Override	Replace target data with the snapshot version

You can set a default for all conflicts and overrides for specific records when the UI supports it.

Dependencies

Many config records reference other records (e.g. a workflow linked to a pipeline). The load process remaps IDs so references point at newly created or matched rows in the target workspace.

If a record in the load plan depends on something that was not captured or not included in the load , the job may fail with an unresolved reference error. Fix by:

Including the missing related records in the snapshot or load plan, or
Re-capturing the snapshot from a source workspace with consistent data

Re-running the same load without changing the snapshot or plan usually produces the same result.

Best practices

Snapshot from a workspace that is clean and finalized
Include all sections and records the target will need
When sharing across orgs , use password protection if the template should not be public
After importing from another org, review the snapshot before loading — then load into an empty or new workspace when cloning a full setup
Prefer loading into an empty or new workspace when cloning a full setup
Use keep existing when merging into a workspace that already has config you want to preserve
After a failed job, read the error message and adjust the snapshot or load plan before retrying

At a glance

Concept	Description
Source workspace	Where a locally created snapshot was taken from
Target workspace	Where a load job applies the snapshot
Snapshot	Stored capture of selected config
Imported snapshot	Snapshot copied into your org from another organization
Load job	One run that applies a snapshot to a target
Load plan	What sections/records this job includes
Conflict policy	Keep vs override when target already has a match

Workspace Snapshot Load Jobs — single snapshot → single workspace
Bulk Workspace Snapshot Load Jobs — one snapshot → many workspaces