Salesforce Sandbox Seeding: The Complete 2026 Guide

Short answer: Salesforce sandbox seeding is the process of loading a targeted, realistic slice of production data into a sandbox, with every related record intact. You choose the objects and records, the tool brings parents and children along in the right order, and owners are mapped to users in the target. Done well, it gives Developer and Partial Copy sandboxes data that behaves like production, without the cost and wait of a Full sandbox refresh.

Most Salesforce teams test against data that looks nothing like what users work with. Three Accounts called "Test", one Opportunity with no Products, and a Contact owned by whoever ran the import. Features pass in the sandbox and fail in production.

This guide covers everything you need to fix that in 2026:

What sandbox seeding is, and why it matters more now than five years ago
Exactly what each sandbox type copies, and where each falls short
Four seeding methods compared, from Data Loader to dedicated apps
A step-by-step walkthrough
Best practices, troubleshooting and FAQs

What is Salesforce sandbox seeding?

Sandbox seeding means copying a chosen subset of real records from one Salesforce org (usually production) into another (a sandbox, scratch org or test org), so testing happens on realistic data. It differs from a sandbox refresh, which copies metadata and, depending on type, all data or a random sample.

Good seeding has four properties:

Selective. You pick "Opportunities closed this year in EMEA", not a random 10,000 rows.
Relationally complete. A Contact arrives with its Account; an Opportunity arrives with its Price Book, Products, Quotes and Order Products.
Correctly owned. Owners and user lookups point at the right people in the target org.
Repeatable and reversible. You can run the same seed after every refresh, and remove it cleanly when it goes stale.

Why sandbox seeding matters more in 2026

Three things have raised the stakes:

AI features need real data to test. Agentforce agents, Einstein features and prompt templates reason over your records. An agent tested on three dummy Accounts tells you nothing about how it handles thousands of real ones with messy fields.
Release cadence is faster. Teams using DevOps Center, CI pipelines and scratch orgs create fresh environments weekly or daily. Each one starts empty and needs data quickly.
Privacy rules are stricter. GDPR, CCPA and industry rules make "just copy all of production" harder to justify. Selective seeding copies only the records a test needs, which shrinks the personal data spread across sandboxes.

Salesforce sandbox types: what data does each one copy?

Only a Full sandbox copies all production data. The other three start empty or with a sample, which is why seeding exists.

Developer: copies no data. 200 MB storage, refreshable every day. Used for building and unit testing.
Developer Pro: copies no data. 1 GB storage, refreshable every day. Used for larger development work and integration testing.
Partial Copy: copies a sample defined by a sandbox template, up to 10,000 records per object. 5 GB storage, refreshable every 5 days. Used for QA and user acceptance testing.
Full: copies all production data. Same storage as production, refreshable every 29 days. Used for staging and performance testing.

Source: Salesforce Help — Sandbox Types and Templates. Verify current limits before publishing.

Where each type falls short:

Developer and Developer Pro sandboxes are where most work happens, and they hold no data at all.
Partial Copy samples are not targeted. The Opportunity you need to reproduce a bug may arrive without its Products, and the 10,000-record cap cuts large related sets.
Full sandboxes are costly, slow to refresh, and copy every piece of personal data in production.

Four ways to seed a Salesforce sandbox, compared

For anything beyond one or two objects, a dedicated seeding app saves the most time; the manual methods break down once records depend on each other.

Sandbox templates (Partial Copy): copy a broad sample on each refresh. Relationships survive only within the sample, and you choose objects but not specific records. Users need no mapping because they are copied too. Best for a general sample in QA sandboxes.
Data Loader / CSV: lets you pick exact records with a SOQL export, but you rebuild relationships and user references by hand, and repeating it is tedious. Best for one or two unrelated objects.
Salesforce CLI data tree (sf data export tree / sf data import tree): keeps relationships for small record trees, selects records with SOQL, and stores them as files in source control. It does not map users. Best for small, fixed datasets in scratch orgs.
Dedicated seeding app (e.g. SmartSeed): follows relationships automatically, selects records with filters or SOQL, maps users, and saves configurations to re-run. Best for realistic, related data in any sandbox.

Why Data Loader struggles with related data: you export each object to CSV, insert parents first, capture the new IDs, rewrite every lookup column in the child files, then insert children. A five-object Opportunity tree means five exports, five imports and a spreadsheet of VLOOKUPs. One wrong ID and records arrive orphaned.

Why CLI data trees stay small: they work well for a fixed set of sample records checked into a repo. They are not built for pulling thousands of live production records with deep relationships.

How to seed a Salesforce sandbox, step by step

This walkthrough uses SmartSeed, a native Salesforce app that copies data from a source org to a target org. It runs as the logged-in user, so it can only read and write what that user is allowed to, and never grants itself extra permissions.

Step 0: Connect the two orgs (once). An admin creates a Named Credential in each org, one pointing at the other. SmartSeed never stores passwords; it refers to the credentials by name. Enter the two names as the Remote Alias and Callback Remote Alias, then press Test. Both directions must succeed: the callback lets the target report progress back to you.

Choose objects and fields. Create a schema item and pick the main object, for example Opportunity. Under Relationships, tick the parents (Account, Price Book) and children (Opportunity Products, Quotes, Orders) to bring along. Under Fields, required fields are locked on; choose the standard and custom fields you need.
Validate against the target. Save, then press Validate. SmartSeed checks the target org and separates "Fields not found" (the field does not exist there) from "Inaccessible fields" (it exists, but you lack permission). Green means ready; red blocks the transfer until fixed.
Group items into a bundle. Real data spans objects, so add several schema items to a bundle and use Reorder items to send dependencies first, such as Standard Price Book Entries before Opportunities.
Choose the records. For each item, filter the main object only: for example Close Date this year and Amount over 50,000. Combine filters with All, Any or custom logic like 1 OR (2 AND 3), or edit the SOQL directly. Press Get Data, then Select All. Related records follow along the relationships you chose.
Map users. Open User Mapping and run Auto-Match, which pairs users by name and email. Review the proposals, then fix the rest with the mass matcher.
Send and monitor. Pause target automation, then press Start Transfer. SmartSeed finds related records, sends them in pages, and the target creates them parents-first. Per object you watch Number of records, Sent and Created fill in. The run continues if you close the browser.
Review the run. Transfer History lists expected, inserted, updated, skipped and failed counts per object, with a Run Id for support.

Save the bundle and export it to .json. The file holds setup only, never record data, so it is safe to keep in version control and reuse after every refresh.

Sandbox seeding best practices

Pause automation in the target. Triggers, Flows and validation rules fire on every seeded record. A Flow that sends an email will send thousands, and a busy trigger can exhaust the governor limits the transfer needs. Switch them off in the target, seed, then switch them back on.
Copy the minimum. Every relationship multiplies volume: one Account can bring ten Contacts, each with its own Cases. Tick only what your test needs, and watch sandbox storage limits.
Minimise personal data. Seed the records a test needs, not whole tables. Where your policy requires it, mask sensitive fields before they reach the sandbox. SmartSeed does this in the source org, before anything is sent: you choose the fields, and email addresses are invalidated by default.
Map users before the first run. Unmapped owners default to the person running the transfer, and other unmapped user fields arrive empty. Empty is deliberate: a wrong name in "Approved By" would be indistinguishable from the truth.
Use upsert for recurring seeds. If you send the same records weekly, have an admin set a unique External ID as the upsert identifier. Matching records are updated instead of duplicated.
Plan clean-up. Stale test data skews results. SmartSeed records every record it creates, so it can delete only its own records, children before parents, and never touches data that was already in the target.
Seed after every refresh. A refresh wipes sandbox data. Keep your bundles saved and re-run them as part of the refresh routine.

Troubleshooting common seeding errors

Transfer fails with limit errors: automation is running in the target. Deactivate triggers and Flows, then re-run.
A lookup field arrives empty: the object it points to was not in the transfer. Add that object to the schema item.
Every record is owned by one person: user mapping was not set up before the run. Map users, then re-run.
Duplicate records after a second run: no upsert identifier is set. Configure an External ID as the upsert field.
"Requires Validation" will not clear: there are unsaved changes. Save first, then validate.
The target never reports progress: the callback connection is broken. Re-test the connection in both directions.
A "query too long" warning appears: the selection exceeds Salesforce's 100,000-character SOQL limit. Narrow the filter or split it into batches.

Frequently asked questions

What is the difference between a sandbox refresh and sandbox seeding? A refresh rebuilds the sandbox from production metadata and, for Partial Copy and Full sandboxes, copies data automatically. Seeding is a separate step that loads specific, chosen records into any sandbox, including Developer sandboxes that copy no data.

How do I get production data into a Developer sandbox? Use a seeding tool that follows relationships and maps users. Developer and Developer Pro sandboxes copy no data on refresh, so seeding is the only way to give them realistic records.

Is a Partial Copy sandbox enough for testing? Often not. It takes a template-based sample of up to 10,000 records per object, so specific records and their full related trees may be missing.

Do I need to deactivate Flows and triggers before seeding? Yes, in the target org. Otherwise they run on every seeded record, can send real emails, and can hit governor limits.

Will seeding change record ownership? Only if users are not mapped. With user mapping, owners carry over. Unmapped owners default to the user running the transfer.

Can I seed the same records again without duplicates? Yes, by setting an External ID as the upsert identifier. Matching records are updated rather than created again.

How do I remove seeded data? SmartSeed can delete what one schema item last copied, or everything it ever copied into a target org. It deletes only records it created.

Start testing on data that looks real

Realistic test data catches the bugs dummy data hides. Whatever method you choose, start small: your core Accounts, Contacts and Opportunities, with users mapped and automation paused.

SmartSeed is ready for you. Install it in a sandbox, get in touch, or take our Sandbox Data Readiness Scorecard to see how closely your test environments reflect production.

Salesforce Sandbox Seeding: The Complete 2026 Guide