Bulk Workspace Snapshot Load Jobs

A bulk load applies one workspace snapshot to many target workspaces in a single batch. The system creates a child load job for each target and tracks overall batch status .

For single-workspace loads, see Workspace Snapshot Load Jobs . For snapshots in general, see Workspace Snapshots Overview .

Start a bulk load — snapshot and target workspaces

What bulk load does

When you start a bulk load:

  1. A bulk workspace snapshot load parent record is created for your organization
  2. The system fans out one child load job per target workspace
  3. Each child job runs the same load plan against the same snapshot
  4. Parent batch status rolls up from all child jobs

Use bulk load to onboard many subaccounts, roll out a template to a partner list, or promote the same config to multiple staging workspaces at once.

Starting a bulk load

  1. Open Organization settings → Workspace Snapshots and select a snapshot.
  2. Choose Bulk load (or equivalent).
  3. Select target workspaces (up to 100 per batch).
  4. Choose bulk conflict mode (see below).
  5. Confirm the shared load plan if prompted.
  6. Start the batch.
Bulk conflict mode — keep existing vs override all

All targets in the batch share the same snapshot, load plan, and bulk conflict mode. Each workspace still gets its own child load job for progress and errors.

Bulk conflict mode

Bulk load uses a single mode for every target in the batch:

Mode Maps to per-job policy
keep_existing Default resolution: keep existing records when there is a conflict
override_all Default resolution: override target records with snapshot data

Per-record conflict overrides are not set at the bulk level — each child job inherits the mapped policy from the bulk mode.

Batch status

The parent bulk load record has a batch_status that summarizes all child jobs:

Status Meaning
queued Batch created; child jobs may still be queueing
processing At least one child is draft, queued, or processing
completed Every child job completed successfully
partial_failed Some children completed, some failed or were canceled
failed No successful children, or fan-out failed entirely
Bulk load detail — batch status and fan-out summary

The fan_out_summary on the parent lists each target workspace, whether its child job was queued, and any fan-out error if creation failed.

Child load jobs

Each target workspace gets its own workspace snapshot load job , linked to the bulk load via bulk_workspace_snapshot_load .

Child load jobs for a bulk batch

Open a child job to see individual progress, status, and error messages for that workspace. One target failing does not automatically roll back others — check each failed child separately.

Child jobs follow the same lifecycle as a normal load job: draft → queued → processing → completed / failed / canceled .

Limits and concurrency

  • Maximum 100 target workspaces per bulk load
  • One processing load job per organization at a time — extra jobs stay queued until the current org load finishes
  • Bulk load respects the same org queue as single load jobs

When a bulk load partially fails

  1. Open the bulk load detail and check batch_status and fan_out_summary .
  2. List child load jobs filtered by this bulk load.
  3. For each failed child, read that job’s error message (same troubleshooting as a single load job).
  4. Fix snapshot, load plan, or source data as needed.
  5. Run a new bulk load or individual load jobs for workspaces that still need the config.

Re-running the same bulk batch without fixing underlying issues usually reproduces the same failures.

Shared options with single load jobs

Option Typical use
load_plan Same sections/records applied to every target
abort_on_unresolved Stop a child job if a reference cannot be mapped (default: on)
activate_active_workflows Whether to activate workflows that were active in source (default: off)

At a glance

Concept Description
Bulk load One snapshot → many target workspaces in one batch
Child load job Per-workspace load job created by the bulk fan-out
batch_status Rolled-up status across all children
fan_out_summary Which targets queued successfully vs failed at creation
bulk_conflict_mode keep_existing or override_all for every target