Salesforce sandbox seeding means loading data into a sandbox so your tests, training sessions and user acceptance testing (UAT) run against data that looks like production.
Most sandboxes need it. Developer and Developer Pro sandboxes copy your metadata and none of your data, so they arrive empty.
Below is the seeding process we'd follow, in seven steps. The sample data plan and data masking need the most care, so they get the most space.
What is Salesforce sandbox seeding?
Data seeding puts records into a sandbox. The seed data can be a slice of production data or test data you create for one test.
Sandbox seeding isn't the same as a refresh. A refresh updates the sandbox's metadata from its source org, and it only brings data along when the sandbox is a clone or uses a sandbox template.
That's why sandbox seeding normally comes straight after one.
Why seed a sandbox instead of copying production?
Salesforce's own developer guide says development environments, such as scratch orgs and developer sandboxes, need a set of stock data for testing.
Apex tests generally create their own test data. UI tests, API tests and UAT need baseline data, though, and scale testing often needs a very large data set.
Your Salesforce org's edition decides how many sandboxes of each type you get. Enterprise Edition includes 25 Developer sandboxes and one Partial Copy sandbox, while a Full sandbox comes with Unlimited and Performance editions.
Seeding the smaller sandbox types is how development teams get production-like data into all of them.
Flosum's Data Migrator page puts the cost side plainly: seeding lower-tier sandboxes is a common way to avoid over-buying Full Copy sandboxes. You can also seed data on demand between refreshes, so you're not stuck waiting out the refresh interval.
Which sandboxes need seeding?
Not all Salesforce sandbox environments start the same way. Here's what each sandbox type copies from production, with figures from Salesforce's sandbox storage limits.
So developer sandboxes are the ones that need you most. Partial Copy can't be created without a sandbox template that names the objects to copy, and a Full sandbox can use one if you want to narrow things down.
Scratch orgs need seed data too. The Salesforce CLI command data import tree imports data from one or more JSON files into an org.
Step 1: Decide what the sandbox is for
Be specific. "Testing new features" isn't a goal, but "testing the new lead assignment rule for the EMEA team" is.
That one sentence tells you a lot. Your test data needs leads, accounts and the users the rule assigns to, and not much else.
Training new users is a different animal, because there you want representative data that looks like an ordinary Tuesday.
Step 2: Write a sample data plan
It's tempting to skip this step, but without a seeding strategy the next refresh turns into guesswork. A sample data plan is a short list of which production data goes into the sandbox, one row per object.
Each row answers five questions: which object, which records (and by what filter), roughly how many, which parents need loading first, and which fields get masked and how. The developer guide's advice to use consistent datasets for each type of test is exactly what a written plan gives you.
Say you're testing a change to case routing. The plan could be as small as this (the filters and volumes are examples, so set yours from the goal in step 1).
Before you load anything, hold the plan up against the storage limit. A Developer sandbox only holds 200 MB of data, or 400 MB with the storage upgrade.
Step 3: Map relationships and load order
Salesforce data is relational. A contact needs its account, and a case needs its contact.
Write down that chain for every object in your plan, then load from the top: accounts, then contacts, then cases. Get it backwards and the lookups come in empty, or the load fails outright, and data integrity goes with it.
Step 4: Mask sensitive data
Copy real production data into a sandbox and every developer, tester and contractor with access can now read your customer data.
That exposure risk is a data security problem, and data masking is the fix. Mask sensitive data before or during the load, never after, so real values never land in your test environments at all.
Salesforce describes four ways to do it: anonymization, pseudonymization, pattern-matching, and deletion. Anonymization swaps a value for an unrelated one, like a made-up name.
Pseudonymization does the same thing consistently, so one customer gets the same stand-in on every record.
Pattern-matching keeps the shape of the value, which matters more than you'd think. A masked phone number that no longer looks like a phone number will trip your validation rules.
Deletion is the simplest of the four: clear the fields the test doesn't use, such as free-text notes.
One field to never forget is email. Mask contact and user addresses so test activity can't email real customers.
We go deeper on methods in Salesforce data masking and data masking for Salesforce security, and on data privacy and regulatory compliance in Salesforce data compliance.
Step 5: Load the data
You've got three realistic options. Here's how they compare, based on what Salesforce and Flosum document for each.
Option 1: Manual seeding with Data Loader
Data Loader is Salesforce's own client app for bulk inserts, updates, deletes and exports from CSV files. If you haven't used it before, start with our Data Loader guide.
- Export the Salesforce data in your plan from the production environment, then mask the files.
- Log in to Data Loader with your sandbox credentials.
- Choose Insert and pick the first object in your load order.
- Select the CSV and map its columns to Salesforce fields.
- Run it, then read the success and error files.
- Repeat for the next object, swapping the production parent IDs in each child file for the new sandbox IDs.
That last step is the fiddly one, and it's time consuming. Every child file needs IDs that didn't exist until the parent load finished, which is the same problem you hit in any data migration process between a source org and a target org.
Option 2: Automated seeding with a tool
A data seeding tool saves the plan as a template and takes care of load order, ID mapping and data masking in one job.
With three objects, Data Loader is fine. With twenty objects and a weekly refresh, you'll want the template, with a lot less manual work and less room for human error.
Option 3: Copy a subset with a sandbox template
If you have a Partial Copy or Full sandbox, a sandbox template picks which objects Salesforce copies when you create or refresh it. A Partial Copy sandbox can't be created without one.
It's the least hands-on of the three, but the copy doesn't mask anything, so step 4 still applies before anyone opens the data.
Step 6: Check the seeded data
Don't hand the sandbox over yet. Run a report per object and compare the counts with your plan.
Then open a few child records and make sure their lookups point to the right parents.
Search the masked fields for anything that still looks like real data, emails especially. Last, fire the flows and validation rules you're actually testing on a handful of records.
Step 7: Reseed after every refresh
A refresh rebuilds the sandbox from its source org, and the org ID changes every time. The table above shows how often each sandbox type can refresh.
This is where step 2 earns its keep. Keep the plan and load order somewhere the whole team can find them, and the next data seeding run is a rerun instead of a rebuild.
Our data migration best practices cover documenting repeatable loads like this.
How does Flosum Data Migrator seed a sandbox?
Flosum Data Migrator turns Salesforce sandbox seeding into a job you save once. You define the data set, filter it with SOQL and reseed any sandbox from it on demand, with parent-child relationships preserved and masking applied in transit.
Every Data Migrator migration and seeding job is logged, versioned and auditable, so security and compliance teams get an audit trail of what data moved, when and who approved it.
Prebuilt seeding templates cover CPQ, Revenue Cloud, nCino, Field Service, Health Cloud and Financial Services Cloud, and data seeding can run inside your CI/CD workflows. Flosum says its masking keeps referential integrity across related objects in support of data privacy regulations like GDPR, HIPAA and CCPA.
Data Migrator is one of Flosum's Cloud Apps. According to Flosum's deployment architectures page, it runs either on Flosum-managed AWS (AES-256 at rest, TLS 1.2 or later in transit) or on a virtual machine you own in AWS, Azure or GCP.
That's two of the three ways to run Flosum; the third is Salesforce-native.
If you'd rather seed at the moment a sandbox is created, Flosum Sandbox Management can load masked production data during provisioning, with personally identifiable information (PII) masked.
It also disables flows, so automations don't fire unintentionally on the new records. The full solution, from reusable templates to reseeding after a refresh, is on our Flosum sandbox seeding page.
Sandbox seeding best practices
Before you call it done, check for the three slips this seeding process is there to prevent.
No written plan means nobody can repeat the load, and parents loaded after children means broken lookups. Masking run as a separate job is the third, because sooner or later someone forgets it and sensitive information reaches the sandbox.
Each of those is a process gap rather than a tooling one. Sandbox seeding is one step in the wider release process, and Salesforce DevOps covers how it sits alongside version control and deployments, with Flosum DevOps as the platform side.
FAQs
Want to see a sandbox seeded with masked data on your own org? Book a demo to see how Flosum Data Migrator reseeds any sandbox from one saved template.
Thank you for subscribing
