Workspace Snapshot Load Jobs

A load job applies one workspace snapshot to one target workspace . It tracks the full run from setup through completion or failure.

For creating snapshots and the big-picture flow, see the Workspace Snapshots Overview .

What a load job does

When you load a snapshot, the system:

Builds a load plan — which sections and records from the snapshot will be copied
Applies conflict policy — what to do when the target already has a matching record
Runs steps in dependency order (fields before workflows, referenced records before dependents)
Updates status and progress until the job finishes

Each run is a separate load job with its own ID, status, and error details.

Starting a load job

Open Organization settings → Workspace Snapshots and select a snapshot (created locally or imported).
Choose Load into workspace .
Pick the target workspace .
Review the load plan — add or remove sections/records if the UI allows.
Set conflict policy (see below).
Start the job.

Tip: Prefer loading into a new or empty workspace when cloning a full setup. Use keep existing when merging into a workspace that already has config you want to preserve.

Job status

Status	Meaning
draft	Created but not queued yet — you can still edit load plan or policy
queued	Waiting to run (only one org load processes at a time)
processing	Actively applying snapshot data to the target
completed	All included steps finished successfully
failed	Stopped with an error — see error message on the job
canceled	Stopped manually while draft, queued, or processing

Only draft and queued jobs are fully editable. Once processing starts, the job runs to completion, failure, or cancel.

Progress

Progress is tracked by resource type (contact fields, workflows, AI agents, etc.). The job detail shows how many steps completed out of the total.

If a job fails partway through , earlier steps may already have created or updated records in the target. Read the error and progress before retrying.

Load plan

The load plan defines what this job will copy from the snapshot:

Which sections are included (workflows, forms, AI config, etc.)
Which specific record IDs within each section (when narrowed)

The job can only restore what is in the snapshot and included in the plan . Missing dependencies in the snapshot or plan often cause unresolved reference errors.

Conflict policy

When the target workspace already has a record that matches something in the snapshot (same name, slug, or natural key), the loader reports a conflict .

Resolution	Behavior
Keep existing	Leave the target record unchanged
Override	Replace target data with the snapshot version

You can set a default for all conflicts and per-record overrides when supported. Type mismatch conflicts cannot be overridden — the record types must align.

Common options

Option	Typical use
abort_on_unresolved	Stop the job if a required reference cannot be mapped (default: on)
activate_active_workflows	Whether to turn on workflows that were active in the source (default: off)

When a job fails

Open the load job and read the error message .
Check progress — see how far the job got.
Common causes:
Unresolved reference — a record in the plan depends on something not in the snapshot or load plan (e.g. an AI agent pointing at a voice that was not captured)
Conflict with no valid resolution
Invalid or missing target workspace

Fix the root cause (update source workspace, re-snapshot, expand load plan, fix agent references), then start a new load job. Re-running the same snapshot and plan without changes usually fails the same way.

At a glance

Concept	Description
Load job	One run: one snapshot → one target workspace
Load plan	Sections and records included in this run
Conflict policy	Keep vs override when target already has a match
Progress	Steps completed by resource type
Error message	Why a failed job stopped

Workspace Snapshots Overview — create, import, and load snapshots
Bulk Workspace Snapshot Load Jobs — load one snapshot into many workspaces