Skip to main content

Sandbox seeding

Sandbox seeding fills a sandbox with a realistic, right-sized subset of production data — so your team tests against data that behaves like the real thing, without copying sensitive values into a less-protected environment.

Seeding is a restore with three habits: a production snapshot as the source, a sandbox as the target, and anonymization on the way in.

Why seed instead of copying?​

  • Full-copy sandboxes are expensive and slow to refresh; partial copies are hard to scope by hand.
  • A seeded sandbox contains exactly the object tree you chose — with relationships intact, thanks to the level-by-level loading of the restore engine.
  • Anonymization keeps personal data out of the sandbox entirely, which your compliance team will appreciate.

Step by step​

  1. Start a restore from a recent production snapshot (see Restoring data).
  2. Scope the subset. Pick your root object with a filter that right-sizes the data — e.g. CreatedDate >= '2025-01-01' for a year of accounts — then tick the children your tests need (contacts, opportunities, cases…).
  3. Anonymize sensitive fields. On each object holding personal data, add anonymize rules: $Email for emails, $Firstname/$Lastname for names, $Number_10 for phone-like fields. See Data mapping and anonymization.
  4. Neutralize side effects. Use Ignore fields for fields that trigger integrations, and a Data mapping rule like * · OwnerId · * · * → <your user's Id> to keep assignment rules quiet in the sandbox.
  5. Pre-flight. Choose the sandbox as the target (sandboxes are listed first), pick the load mode — Insert for a fresh sandbox, or Upsert with per-object match fields for repeatable refreshes — and check the record counts.
  6. Launch and monitor. Watch the per-object results land; destination Ids link straight into the sandbox.

[SCREENSHOT REQUIRED: Seeding scope with anonymization badges visible on object cards]

Repeatable refreshes​

Set a match field (an External Id) on each object in the builder, and the same seeding job can be cloned and re-run after every sandbox refresh without creating duplicates — records are matched and updated in place.

tip

Save the scope as a draft (or keep a launched job to clone) so next month's refresh is two clicks, not an afternoon.