Sometimes you need the actual data — instances, not just the structure — from one tenant inside another. Refreshing a sandbox with a snapshot of production, seeding a new customer's tenant with reference rows, or producing a frozen-in-time copy for an auditor are all cases the tenant-sync wizard covers.

For copying structure only, see Promoting a schema.

When to use it

Goal Source Target Mode
Refresh a sandbox with prod data Production Sandbox replace
Seed a new tenant with reference data Templates tenant New tenant additive
Snapshot for audit / forensic copy Production Audit-2024-Q4 replace, with cutoff date
Migrate a tenant to a new org Old tenant New tenant replace

The tenant-sync wizard

A Tenant sync job records the copy. From the organization page → Sync jobs → + New tenant sync job:

  1. Source tenant — where the data lives.
  2. Target tenant — where it should land.
  3. Schemas to include — pick the subset of schemas whose instances you want copied. Filtering lets you carry CRM data without dragging Inventory along.
  4. Cutoff date (optional) — only copy instances whose createdOn is at or before this date. Useful for forensic snapshots.
  5. Mode — additive (add to existing target rows, skip duplicates by UId) or replace (wipe target rows for the included schemas, then copy). Replace is destructive — use it deliberately.
  6. (Optional) Dry run — reports counts per model without committing.

Save and Run. The wizard streams progress per model: instances copied, instances skipped, instances rejected.

What the wizard does and does not do

It copies:

  • Instances and their property values across the included schemas.
  • File attachments on instances, into the target tenant's file storage.
  • Audit fields (createdOn, createdBy, updatedOn, updatedBy) preserved from the source.

It does not copy:

  • Schema structure — the target tenant must already have the schemas (use Promoting a schema first if needed).
  • Bookmarks, dashboard widgets, saved queries — these are per-user configuration.
  • API keys.
  • Cross-tenant files — they live outside the tenant boundary.

If the target tenant lacks a model that the source has, the wizard skips those instances and reports them in the output.

A safe replication sequence

For a production-to-sandbox refresh:

  1. Confirm schema parity — the sandbox should be on the same schema version as production. Run a schema sync first if not.
  2. Pick the right mode — replace if the sandbox should mirror prod exactly; additive if you want to layer prod data on top of sandbox-only test rows.
  3. Choose a cutoff — if the sandbox should be reproducible from a specific date, set one. Otherwise leave it empty for "now".
  4. Dry run — read the counts. Make sure nothing unexpected is included.
  5. Run live — go.
  6. Validate — log in to the sandbox, spot-check a few instances against prod, confirm file attachments render.

Sensitive data and sandboxes

A tenant sync copies values verbatim — including emails, phone numbers, financial details, anything else flagged as personal data. When you copy production into a developer sandbox, those developers can now read all of it.

If your organization needs scrubbing before promotion (replace names with fakes, hash emails, blank out free-text notes), do it as a separate step on the target after the sync. Build a Yellow script or use the AI assistant to walk the relevant models and rewrite the sensitive properties.