A few years back we were supporting a mid-size retail client — think several hundred Sales Cloud users, a reasonably complex Apex layer, and a data migration coming up in Q3. Their admin had been doing all pre-production testing in a single Full Copy sandbox. Every developer, every admin change, every "just a quick Flow tweak" went into that one environment. By the time the migration team needed to do a proper performance test, the sandbox was so far out of sync with production schema that a refresh was unavoidable — but the 29-day interval hadn't elapsed yet. The team sat on their hands for two weeks waiting for the clock to run out.
That situation is entirely avoidable once you understand what each sandbox type is actually optimized for. The four types are not a tiered quality ranking; they're four different tools for four different jobs. Using the wrong one is either wasteful or actively dangerous, depending on which way you get it wrong.
Developer and Developer Pro: Your Daily Workbench
The Developer sandbox copies metadata only — schema, configuration, custom code, automation logic. No production records come across. Storage is capped at 200 MB for data and files, and you can refresh it as frequently as every 24 hours.
That last detail is the reason we provision a Developer sandbox for every engineer on a project, not a shared one. When a developer gets configuration into a bad state chasing down a trigger interaction or testing a Flow that fires recursively, they can reset to a clean production copy overnight and start fresh the next morning. No coordination required, no waiting on an admin to sort out the broken sandbox state.
The absence of real data is rarely a problem at this stage. When you're adding fields, writing Apex, building automations, or wiring up integrations — the work is schema-level. You're not validating search result relevance or testing how a validation rule behaves against five years of legacy records. Fabricated data in Developer sandboxes is fine for this purpose because you're testing logic structure, not data quality.
Developer Pro is identical in behavior — metadata only, daily refresh — but comes with 1 GB of storage instead of 200 MB. We reach for Developer Pro when a team is sharing a single sandbox across parallel feature tracks, or when the project has a heavy static resource footprint (large Lightning Web Component bundles, embedded file assets, that sort of thing). The upgrade is purely about headroom, not capability.
Partial Copy: The UAT Sweet Spot
On a project we ran for a telecom client — a Sales Cloud rollout with roughly 80,000 Account records accumulated over several years — the UAT team initially pushed for a Full Copy sandbox. The reasoning made sense on the surface: testers want real data, and a partial sample might miss edge cases. We talked them off that ledge.
A Partial Copy sandbox lets the admin define a Sandbox Template: which objects to include, how many records to pull, and what filters to apply. For that telecom project, we configured the template to bring across all Account records, 15,000 of their most recent Opportunities, and the associated Contacts and Cases. The sandbox refreshed in a few hours rather than the day-plus a Full Copy would have taken, the 5-day refresh interval meant we could reset weekly if UAT surfaced a configuration issue that needed to be fixed and re-tested, and the data was realistic enough that testers could work through their scripts against actual customer record shapes.
The one thing we always flag with Partial Copy is the relationship completeness issue. Because the data sample is random within the template constraints, you can end up with Contacts whose parent Account wasn't included in the sample, or Opportunities with no related Quote records. Test scripts that walk full relationship chains — Account to Opportunity to Quote to Order — need to be written knowing they might hit gaps. We handle this by either building the test scripts to tolerate missing relationships, or by adding a manual data setup step at the start of UAT to patch in the specific record chains the scripts depend on.
The 5-day refresh interval is genuinely the right cadence for UAT. Weekly resets keep the environment from accumulating junk test data and keep the schema in sync with production as configuration changes land. We've never had a client complain that 5 days is too slow for this use case.
Full Copy: Only When You Actually Need All of It
We use Full Copy sandboxes for exactly two scenarios: performance and load testing, and data migration validation. In both cases, the requirement is that the behavior of the sandbox must be indistinguishable from production — which means you need all the data, not a sample.
For a data migration project at a manufacturing client running Service Cloud, we needed to validate that a bulk import of 2.3 million Case records would complete within the maintenance window without triggering governor limits at volume. A Partial Copy with 15,000 Cases would have told us almost nothing useful. The Full Copy was the only honest test.
What you're trading for that fidelity is operational flexibility. The 29-day minimum refresh interval means your Full Copy sandbox is effectively locked for an entire sprint cycle once it's refreshed. Any schema changes that land in production during that period have to be manually deployed into the sandbox via Change Set if you need them. We've seen teams let that drift accumulate across a Full Copy sandbox lifecycle until the two environments were so diverged that the sandbox wasn't useful for testing anymore — which defeats the entire purpose.
The data security angle is also something we take seriously. A Full Copy sandbox contains everything production contains: customer PII, financial records, sensitive case history. We always work with clients to ensure Full Copy sandbox access is as restricted as the production access controls, not treated as a development playground. Not every developer who needs a sandbox for feature work should have access to a Full Copy environment.
The Refresh Is Destructive — Never Forget That
This catches teams out more often than the sandbox type selection itself. A sandbox refresh wipes everything that was in the sandbox and replaces it with a current copy of production plus the sandbox type's data. That means any configuration built in the sandbox that hasn't been promoted to production yet is gone. Test data that was created manually is gone. Scheduled jobs configured in the sandbox are gone.
Our practice before any refresh is a quick audit: has anything in this sandbox not been deployed to production yet? If yes, deploy it first via Change Set. If it's not ready to deploy, document it and be prepared to rebuild it after the refresh. We've learned this the hard way on behalf of at least two clients who lost a day's worth of Flow configuration to an accidental refresh.
One more thing worth knowing: after a refresh, usernames in the sandbox get .sandboxname appended automatically. A production user lan@fptelecom.vn becomes lan@fptelecom.vn.uat in the UAT sandbox. Any Apex code, Flow, or email template that references a specific username by its production value will break in the sandbox. We always grep for hardcoded username references before standing up a new sandbox environment, and we make sure SSO configurations and external system integrations are mapped to the sandbox-modified usernames separately.
How We Approach This on Every Project
Our default setup for a mid-size Salesforce implementation: one Developer sandbox per active developer, one Developer Pro for shared configuration work, one Partial Copy for UAT, and a Full Copy standing by for the data migration validation phase only. We don't provision the Full Copy until we're actually in the sprint that needs it, because the 29-day refresh lock-in starts the moment you create it.
The mistake we see most often is treating sandbox type as a prestige ladder — assuming Full Copy is "better" than Partial Copy, which is "better" than Developer. They're not better or worse; they're appropriate or inappropriate for the job in front of you. Match the sandbox type to the testing requirement, protect your refresh intervals, and treat every refresh as a destructive operation that deserves a checklist.
