5 Ways to Create Test Data in Salesforce (+ When to Use Each)

Short answer: There are five main ways to create test data in Salesforce: manual entry or CSV import (Data Import Wizard, Data Loader), Apex test data factories, scripted or synthetic data (Salesforce CLI data trees, Snowfakery), a Partial Copy or Full sandbox refresh, and seeding real production records with a dedicated tool. Use Apex for unit tests, synthetic data for scratch orgs and volume tests, and seeded production data when you need records that behave like the real thing.

No single method covers every kind of testing. A unit test needs a handful of predictable records that vanish when the test ends. A load test needs a million rows. A user acceptance test needs data your sales team would recognise. Pick the wrong method and you either waste days building data or ship a feature that only worked on fake records.

Below, each method gets the same four answers: what it is, what it is best for, where it falls short, and when to use it.

1. Manual entry and CSV import (Data Import Wizard, Data Loader)

The simplest route: type records into the UI, or build a spreadsheet and import it. The Data Import Wizard runs in Setup and handles up to 50,000 records for common standard objects and custom objects. Data Loader is a desktop client for larger volumes and for objects the wizard does not support.

Best for: a few records to click through a new page layout, or a one-off load of a single object.
Limits: relationships are manual. To load Contacts under Accounts you insert the Accounts, export their new IDs, and rewrite the AccountId column before inserting Contacts. Every extra level adds another round of exports and lookups, and nothing is easy to repeat.
Use it when: you need one or two unrelated objects and will not need the same data again.

2. Apex test data factories

Apex unit tests cannot see org data by default, so they create their own. A test data factory is a reusable class with methods like createAccounts(5). Records created in a test are rolled back when it ends. Use @testSetup to build shared records once per test class, and Test.loadData() to load records from a CSV static resource.

Best for: automated unit tests and the 75% code coverage required for production deployment.
Limits: the data exists only while the test runs. It is as realistic as the developer who wrote it, and it does nothing for manual QA, user acceptance testing or demos.
Use it when: you are writing Apex tests. Always, for that job, and never as a substitute for realistic data elsewhere.

3. Scripted and synthetic data (Salesforce CLI, Snowfakery)

These methods generate data from files you keep in source control. The Salesforce CLI's sf data export tree and sf data import tree commands save a small set of related records as JSON and load them into any org. Snowfakery, an open-source tool from Salesforce's CumulusCI project, generates fake but realistic records from YAML recipes, from a dozen to millions.

Best for: scratch orgs in CI pipelines, consistent demo data, and large-volume or performance testing without touching personal data.
Limits: someone has to write and maintain the scripts or recipes as the data model changes. Synthetic data also misses the quirks of real data: odd picklist values, half-filled fields, legacy records.
Use it when: you need the same data in many fresh orgs, or volume without privacy risk.

4. Sandbox refresh (Partial Copy and Full sandboxes)

When you refresh a sandbox, Salesforce copies production metadata and, for two sandbox types, data. A Partial Copy sandbox takes a sample defined by a sandbox template, up to 10,000 records per object. A Full sandbox copies everything. Developer and Developer Pro sandboxes copy no data at all.

Best for: broad QA and staging environments where "roughly production" is good enough.
Limits: Partial Copy samples are not targeted, so the record you need to reproduce a bug may arrive without its children. Full sandboxes cost more, refresh only every 29 days, and copy every piece of personal data in production. Neither helps a Developer sandbox.
Use it when: you need a general-purpose copy of production and can wait for the refresh cycle.

5. Seeding real production data with a tool

A seeding tool copies a chosen set of production records, plus every related record they depend on, into any sandbox or test org. You pick the records with filters (for example, this year's Opportunities in EMEA), and the tool brings Accounts, Products, Quotes and Order Products along in the right order, mapping owners to users in the target.

SmartSeed works this way in three steps: choose objects and fields, choose records, then send and monitor. It runs as the logged-in user, so it only reads and writes what that user may, and it can later delete exactly the records it created.

Best for: user acceptance testing, bug reproduction, demos and AI feature testing, anywhere data must behave like production.
Limits: you are copying real records, so pick only what each test needs and follow your organisation's privacy rules. Target automation should be paused during the load.
Use it when: you need realistic, related records in a Developer or Partial Copy sandbox without waiting for, or paying for, a Full refresh.

For the full walkthrough, see our guide to Salesforce sandbox seeding.

Which method should you use?

Most teams use three or more of these together. Match the method to the kind of testing:

Apex unit tests: Apex test data factories (method 2).
Scratch orgs and CI pipelines: CLI data trees or Snowfakery (method 3).
Performance and large-volume testing: Snowfakery-generated synthetic data (method 3).
A quick check of one new field or layout: manual entry (method 1).
General QA in a staging environment: Partial Copy or Full sandbox refresh (method 4).
User acceptance testing, bug reproduction and demos: seeded production data (method 5).
Testing AI features such as Agentforce agents: seeded production data (method 5), because agents need the variety and mess of real records.

Best practices for any Salesforce test data

Pause automation in the target org before bulk loads. Flows, triggers and validation rules fire on every inserted record.
Keep personal data to a minimum. Generate it, mask it, or copy only the records a test needs.
Make test data repeatable. Store factories, recipes and seeding configurations so any team member can rebuild the same data after a refresh.
Clean up. Stale test data skews results. Know how you will remove each load before you make it.

Frequently asked questions

What is the easiest way to create test data in Salesforce? For a few records, enter them in the UI or import a CSV with the Data Import Wizard. For related records across several objects, a seeding tool is faster because it keeps the relationships for you.

Can Apex tests use real org data? Not by default. Since API version 24.0, tests run with SeeAllData=false, so they create their own data. Salesforce recommends keeping it that way so tests stay reliable.

What is Snowfakery? An open-source tool from Salesforce's CumulusCI project that generates realistic fake records from YAML recipes. It suits scratch orgs and large-volume tests.

Does a Developer sandbox include data? No. Developer and Developer Pro sandboxes copy metadata only, so you must load data with one of the methods above.

Is it safe to use production data for testing? It can be, if you copy only what each test needs, restrict sandbox access, and mask sensitive fields where your policy requires it.

Get realistic test data without the spreadsheets

SmartSeed copies real, related Salesforce records into any sandbox in three steps, with owners mapped and a clean way to remove them afterwards.

SmartSeed is launching soon. Please get in touch or take our Sandbox Data Readiness Scorecard to see how closely your test environments reflect production.

5 Ways to Create Test Data in Salesforce (+ When to Use Each)