A Salesforce partial copy sandbox copies your metadata plus a sampled subset of records from objects you select, up to 10GB of data. It sounds like a reasonable middle ground between a full copy and a bare-bones dev sandbox. In practice, the sampling logic and object exclusions leave gaps that only show up once QA hits a workflow the sandbox never had data for.
That gap is the actual subject of this article, not the marketing pitch. Salesforce sells partial copy as "production-like data without the wait." It is faster to provision than a full copy, true. But faster provisioning and representative data are two different promises, and partial copy only keeps one of them.
What a partial copy sandbox actually includes
You define a sandbox template before provisioning, picking which objects to include and writing a SOQL-based sample rule for each. Salesforce then pulls matching records up to the 10GB cap, prioritizing the objects you flagged as most important. Metadata comes over in full, same as any sandbox type.
The catch sits in the sampling. If you tell it to grab the most recent 10,000 Opportunities, you get 10,000 Opportunities that skew toward whatever your reps closed last quarter. Seasonal deals, edge-case discount structures, and anything older than your sample window simply do not exist in that sandbox.
Related records follow a similar logic. Child records get pulled based on their relationship to the sampled parent, which means an Opportunity with 40 line items might land in your sandbox with three, because the sampling rule capped child volume to stay under the size limit. Your test data looks real until you open a record and count the line items.
The objects and records it leaves behind
Attachments and Files above a certain threshold get excluded by default unless you explicitly configure the template to include them, and even then large attachments eat your 10GB budget fast. Teams testing document generation or Salesforce Files workflows often discover this the hard way, mid-sprint, when a merge template renders blank.
Big objects and platform events do not come across at all in a partial copy. Neither do most audit trail records beyond a short window. If your org relies on Field Audit Trail or a custom big object for compliance tracking, your sandbox has none of it, and any test scripts that reference historical field values will fail silently or return nulls.
Cross-org integration data is another blind spot. Partial copy sandboxes get new, sandbox-specific IDs and endpoints, which is expected, but the actual payloads that a middleware tool would have logged in production never transfer. Testing an integration against a partial copy means testing against a shape of data, not the data itself.
Why teams get burned in QA and UAT
The failure pattern is consistent across the consultancies we work with. A release passes unit tests and functional QA in the sandbox, gets promoted, and then breaks in production on a record type the sandbox never sampled. A validation rule built around a specific record status throws unexpected errors because that status never appeared in the 10GB slice.
Reporting is the other repeat offender. A dashboard built and tested against sampled data looks fine until it runs against the full production volume and either times out or returns numbers that expose a rollup miscalculation nobody caught. Partial copy volume is a fraction of production, so performance issues tied to record count stay invisible until go-live.
I've sat in enough post-mortems to notice the pattern repeats regardless of team size or maturity. It is not a testing discipline failure. It is a data coverage failure baked into how partial copy sampling works, and no amount of extra test cases fixes a sandbox that structurally cannot hold the records that would trigger the bug.
Partial copy vs full copy vs scratch org
Each sandbox type trades data fidelity for speed and cost differently. Picking the wrong one for a given testing phase is where most of the pain in a release cycle originates.
| Type | Data fidelity | Refresh time | Best use |
|---|---|---|---|
| Full copy | Complete production mirror | Hours to days | Pre-release UAT, performance testing |
| Partial copy | Sampled subset, up to 10GB | Under an hour typically | Mid-cycle QA, integration smoke tests |
| Scratch org | No production data, built from source | Minutes | Unit tests, feature branch dev |
Full copy is the only type that guarantees the edge cases exist somewhere in the org. But full copy sandboxes are expensive to refresh often, so most teams cannot afford to run every sprint's QA against one. Partial copy fills the gap in theory, and it does for object-count and basic-workflow testing. It just cannot substitute for full copy when the bug you are chasing depends on rare data shapes.
How to make a partial copy sandbox actually useful
The fix is not abandoning partial copy. It is stopping the assumption that sampled production data equals representative data, and engineering around that gap instead of hoping the sample happens to include what you need.
This is the exact problem SproutEzee was built to solve. Instead of relying on whatever the sampling rule happened to pull, SproutEzee generates production-like data patterns directly in the sandbox, covering the record types, volumes, and relationship depth your partial copy sample missed. You define the coverage you need, not the coverage the sampling algorithm decided was statistically convenient.
Pair that with a masking pass through MaskEzee whenever a partial copy does include real customer records, and you cover both problems at once: the sandbox has enough varied, realistic data to catch edge cases, and none of it exposes PII to a QA team that does not need to see it. Skipping masking on a partial copy because "it's only a sample" is a common shortcut and a compliance risk regardless of the sample size.
When to skip partial copy entirely
Partial copy earns its place for fast-turnaround QA cycles where the team needs current metadata and a reasonable data volume without waiting on a full copy refresh. It works fine for testing a new validation rule against a handful of representative records or checking that a Flow doesn't throw governor limit errors.
It stops working the moment your test plan depends on rare record states, large attachment sets, historical audit data, or accurate performance benchmarking. At that point, either budget for a full copy refresh or seed the partial copy with synthetic data that fills the specific gaps you know exist. Guessing which approach applies, sprint by sprint, is how teams end up debugging in production instead of in a sandbox where it's cheap to fail.
The honest takeaway: partial copy is a scheduling tool, not a data-fidelity tool. Treat it as one and build your seeding strategy around the difference, and the surprises in UAT mostly disappear.
Frequently Asked Questions
What is the size limit for a Salesforce partial copy sandbox?
A partial copy sandbox is capped at 10GB of data, which includes both the sampled records and any Files or Attachments you configure the template to include. Metadata does not count against this limit and always transfers in full, regardless of org size.
Does a partial copy sandbox include Big Objects or platform events?
No. Big objects and platform event data do not transfer to a partial copy sandbox under any configuration. Teams testing features that rely on big object storage, such as archived transaction history, need a different environment or a synthetic data approach.
Why do child records look incomplete in a partial copy sandbox?
The sampling rule pulls parent records first and then fills in related child records only up to whatever remains of the 10GB budget. This often means an Opportunity or Case that had dozens of related records in production shows up with only a handful in the sandbox.
Is a partial copy sandbox safe to use without data masking?
No. A partial copy still contains real customer records unless you explicitly build synthetic data instead, so it carries the same GDPR and PII exposure risk as a full copy. Masking tools like MaskEzee should run on any partial copy that includes production-sourced records before QA teams get access.
When should a team use partial copy instead of full copy for testing?
Partial copy makes sense for routine sprint QA, integration smoke tests, and validation rule checks where speed matters more than exhaustive data coverage. Full copy is still the better choice for pre-release UAT, performance testing, or any scenario where rare data states could trigger a production bug.