Salesforce sandbox strategy

Almost every org we look at has a sandbox called dev. It was refreshed sometime last year. Three admins, two developers, and a consultant who left in October have all built things in it, some of which reached production and some of which didn’t. Nobody is sure which. When a release goes wrong, the postmortem usually blames the deployment tool — but the deployment tool was only shipping what the environments had already made ambiguous.

Sandbox strategy is where small Salesforce teams quietly lose the most time, and it’s also where most published advice fails them. Enterprise DevOps guides assume a Full sandbox, a dedicated release manager, and a budget for environment tooling. Teams of three to thirty have none of those, so they either copy the enterprise diagram badly or give up and share one org. There’s a middle path, and it’s cheaper than most teams think, because the sandbox allocations already bundled with their edition are usually enough.

This post covers the four sandbox types and what your edition actually includes, a reference topology for small and mid-sized teams, refresh discipline, the compliance problem with production data in sandboxes, where source tracking and scratch orgs fit, and how to align all of it with Salesforce’s three seasonal releases.

The four sandbox types, and what your edition actually includes

Salesforce offers four sandbox types, and the differences that matter are what gets copied, how much storage you get, and how often you can refresh. The numbers below come from Salesforce’s sandbox licenses and storage limits documentation and are current as of April 2026:

Sandbox type	What’s copied	Data storage	Minimum refresh interval	Typical role
Developer	Metadata only	200 MB	1 day	Individual dev/admin workspaces
Developer Pro	Metadata only	1 GB	1 day	Shared integration or QA org
Partial Copy	Metadata + sampled data	5 GB	5 days	UAT with realistic records
Full	Metadata + all data	Same as production	29 days	Staging, performance and release testing

Partial Copy sandboxes need a sandbox template that defines which objects to copy, and they take up to 10,000 records per selected object within the 5 GB cap. That sampling is what makes them useful for UAT and too small for volume testing. A Full sandbox is the only environment that replicates production data completely, which is why it’s the right place — and the only honest place — to rehearse a data migration or test a batch job at scale.

What you already own depends on edition. Per the same documentation, Professional Edition includes 10 Developer sandboxes; Enterprise includes 25 Developer sandboxes and 1 Partial Copy; Unlimited and Performance include 100 Developer, 5 Developer Pro, 1 Partial Copy, and 1 Full. Additional sandboxes can be purchased as add-ons. Read that list again if you’re on Enterprise: most teams of ten have twenty-five individual dev environments and a UAT org sitting unused in their contract while everyone crowds into one shared sandbox.

One principle drives everything that follows: use the smallest sandbox that does the job at each stage. Full sandboxes are expensive, slow to copy, and refresh-limited, so burning yours as a shared dev org is the single most common sizing mistake we see.

A reference topology: dev to production for teams of 3 to 30

The pipeline shape barely changes with team size — development, integration, UAT, staging, production. What changes is how many of those stages get their own org and which sandbox type backs each one. Every promotion between stages should run through whatever deployment mechanism you’ve standardized on; we’ve mapped that decision separately in our DevOps Center vs. change sets guide.

Teams of 3 to 10: collapse stages, never people

At this size the temptation is one shared sandbox for everything. Resist it — shared dev orgs are where “who changed this flow” conversations come from. Instead:

One Developer sandbox per builder. Anyone who changes metadata gets their own. They’re metadata-only, refresh daily, and your edition almost certainly includes more of them than you have people.
One shared integration org — a Developer Pro if you have one, a Developer sandbox if you don’t. Everyone’s work merges here first, so conflicts between two people’s changes surface in a sandbox instead of during a production deploy.
One Partial Copy for UAT and staging combined. With realistic sampled data, business testers can validate against records that look like their own. For a five-person team, splitting UAT and staging into separate orgs adds ceremony without adding safety.

That’s it: dev → integration → UAT/staging → production. Three tiers of sandbox, all typically within an Enterprise Edition allocation.

Teams of 10 to 30: separate the questions each stage answers

Mid-sized teams usually run parallel workstreams — an ongoing admin backlog plus one or two projects. The pipeline stretches to keep those streams from colliding:

Per-person Developer sandboxes, as before. This never changes.
One integration sandbox per workstream (Developer Pro), so the CPQ project’s half-finished automation doesn’t block the BAU stream’s Tuesday release.
A Partial Copy for UAT, refreshed on a published schedule so testers know how fresh the data is.
A Full sandbox for staging, if your edition includes one or you can justify the add-on. It’s the last gate before production, the place to rehearse deployments against production-scale data, and — as covered below — your best candidate for release-preview testing. If a Full sandbox isn’t in reach, a second Partial Copy as a dedicated staging org is a defensible compromise; you give up volume realism but keep the release-rehearsal gate.

Two rules keep either topology honest. First, changes only move forward through the pipeline; nobody builds directly in UAT or staging. Second, when a production hotfix does happen, back-promote it into the lower environments the same week, or your sandboxes begin drifting away from the org they’re supposed to represent.

Refresh discipline: treating refreshes as scheduled maintenance

A sandbox is only as trustworthy as its last refresh. Stale environments are how you end up testing against automation that no longer exists in production, then acting surprised when the deploy behaves differently. Refreshing is destructive, though — refreshing replaces the sandbox’s metadata and data from production, and anything not yet promoted or committed to version control is gone. So the answer isn’t refreshing constantly; it’s refreshing on a schedule everyone can see.

A cadence that works for most teams in this size range:

Developer sandboxes: refreshed by their owner at the start of each project or sprint, once their in-flight work is safely in version control or promoted.
Integration: refreshed after each release reaches production, so it restarts from the new baseline.
Partial Copy (UAT): refreshed per release cycle or monthly, whichever is shorter — the 5-day minimum interval is rarely the constraint.
Full (staging): refreshed close to its 29-day interval, timed around the release calendar (more on that below).

The mechanics have sharp edges worth knowing. The sandbox’s org ID changes on every refresh, which breaks anything hard-coded against it. A refreshed sandbox must be activated, and Salesforce deletes new sandboxes that aren’t activated within 30 days. Separately, sandboxes with no login activity for 180 days are deleted after email warnings — a policy that quietly removes the “spare” org someone was counting on.

Every refresh should end with the same post-refresh checklist, written down and owned by a named person: reconnect integration endpoints and named credentials, confirm email deliverability is restricted (Salesforce rewrites user email addresses on refresh precisely so a test org doesn’t email real customers — don’t undo that carelessly), restore the user accounts testers need, re-run any data seeding, and re-enable anything the refresh reset. Teams that skip the checklist rediscover it one incident at a time. It’s exactly the kind of recurring, unglamorous work that falls through the cracks of project-based staffing, which is why environment upkeep is a standing item in our managed services engagements.

Production data in sandboxes: seeding, masking, and the compliance bill

Here’s the uncomfortable part of Partial Copy and Full sandboxes: they contain real customer data, in an org with weaker access control than production, visible to every developer, contractor, and testing user you’ve let in. Under GDPR and similar regimes, personal data in a sandbox is still personal data. Regulators don’t recognize a “but it was only the test org” defense, and neither do the customers whose records leak.

The fix is to treat data handling as part of the refresh workflow, not an afterthought:

Mask before you invite. Salesforce Data Mask — an add-on product — anonymizes sandbox data by replacing values with random characters or similar mapped words, applying pattern-based masking, or deleting fields outright. Masking runs only in sandboxes and is deliberately irreversible there; production is untouched, so a refresh always restores clean source data. Third-party DevOps platforms offer comparable masking if you’re already paying for one.
Seed rather than copy where you can. Developer and Developer Pro sandboxes arrive with metadata only, which is a feature: you decide what data enters. A seeded, synthetic dataset that covers your edge cases beats a random production sample for most functional testing anyway — it’s deterministic, it’s small, and it contains nobody’s real phone number.
Scope the Partial Copy template deliberately. The sandbox template controls which objects get copied. Leave out objects you don’t need for UAT, especially anything with sensitive fields, and the compliance surface shrinks before masking even starts.
Gate the Full sandbox hardest. It holds everything production holds. Restrict access to the people running staging validation, and treat its refresh-then-mask sequence as a single atomic job — the dangerous window is a freshly refreshed Full copy that hasn’t been masked yet.

In practice, the masking step is the one teams defer, because it sits between “refresh finished” and “testers unblocked.” Put it in the checklist with an owner and it happens; leave it to good intentions and it doesn’t.

Source tracking and scratch orgs: when developer tooling earns its place

Two platform features change how sandboxes behave for development work, and teams in this size range often don’t know they exist.

Source tracking makes a sandbox aware of what changed in it. With it enabled, Salesforce DX tooling — the CLI, VS Code, DevOps Center — automatically tracks new, changed, and deleted metadata in Developer and Developer Pro sandboxes, so “what did I actually touch” stops being a memory exercise. It isn’t supported in Partial Copy or Full sandboxes, which is fine: those are testing orgs, not authoring orgs. Enable it org-wide from Dev Hub in production and it applies to sandboxes as they’re created or refreshed; enabling it inside an individual sandbox works too, but that setting doesn’t survive the next refresh, so bake re-enablement into the post-refresh checklist.

Scratch orgs are the step beyond: disposable, source-driven environments created from a configuration file, living 1 to 30 days (7 by default), then gone. They shine when the definition of your org lives in a Git repository — package development, ISV work, teams practicing genuine CI where every feature branch gets a fresh org. That last clause is the honest gate. If your team’s source of truth is still the sandbox itself rather than a repository, scratch orgs will frustrate you, because there’s nothing to build them from. For most admin-heavy teams of 3 to 30, the right sequence is: per-person sandboxes first, version control and source tracking second, scratch orgs only when package-based development actually arrives. Skipping ahead buys tooling you can’t feed.

Aligning your refresh calendar with Salesforce’s three seasonal releases

Salesforce upgrades every org three times a year — Spring in February, Summer in June, Winter in October — and the upgrades are mandatory. You can’t defer them, so the only variable you control is whether you see each release before production does.

That’s what the sandbox preview is for. Sandboxes live on either preview or non-preview instances, and preview instances receive the new release roughly 4 to 5 weeks early — in January, May, and September. Whether a given sandbox is preview or not depends on the instance it lands on, which you influence by when you create or refresh it relative to the preview cutoff Salesforce publishes before each release. Refresh at the wrong moment and your early-access org silently becomes a same-day-as-production org.

The strategy for a small team is simple and cheap:

Keep one sandbox on a preview instance permanently — ideally staging (Full or Partial Copy), because release regressions show up most readily against realistic data and automation.
Put the preview cutoffs on the team calendar each cycle, and freeze refreshes of the preview org across the window. Check the current cutoff dates before every release rather than assuming last cycle’s dates.
Spend the preview window on smoke tests, not exhaustive regression. Run your critical business processes end to end and check release notes for anything touching features you rely on. A few focused hours usually surfaces what matters.
Keep dev sandboxes on non-preview instances so developers build against the same API version production runs.

As of this writing, Spring ‘26 is live in production and the Summer ‘26 sandbox preview opens in May. If your staging org isn’t positioned for it yet, the refresh that fixes that belongs on this month’s calendar, not June’s.

An environment strategy you’ll still be following in a year

None of this requires enterprise tooling or a release manager. The whole model fits on an index card: a sandbox per builder, one integration org per workstream, a Partial Copy for UAT, a Full copy for staging if you can get one, refreshes on a published schedule, masking welded to the refresh, one org held on release preview. Teams of three run the compressed version; teams of thirty run the stretched one. The shape is the same.

What makes a sandbox strategy succeed isn’t the topology diagram, though — it’s whether the discipline survives contact with a busy quarter. The strategies that die are the ones that depend on heroics: the refresh someone was supposed to remember, the masking job that slipped, the preview window nobody watched. The strategies that live are boring. Written checklists with named owners. Calendar entries for cutoff dates. A rule, enforced without exceptions, that nothing gets built in UAT.

If your current environment setup is one shared sandbox and a prayer, don’t try to leap to the full topology in a week. Give each builder their own Developer sandbox this sprint. Add the integration org next sprint. Put the refresh calendar up the sprint after. Within a quarter you’ll have production deploys that behave the way staging said they would — which is the entire point, and a capability most teams your size still don’t have.

Understanding the basics

What is the difference between a Developer and a Developer Pro sandbox?

Both copy production metadata only — no records — and both can be refreshed once per day. The difference is storage: a Developer sandbox holds 200 MB of data, while Developer Pro holds 1 GB. Developer sandboxes suit individual workspaces; the extra room in a Developer Pro makes it the better base for a shared integration or QA org that needs a larger seeded dataset.

How often can each Salesforce sandbox type be refreshed?

Developer and Developer Pro sandboxes can be refreshed once per day, Partial Copy sandboxes every 5 days, and Full sandboxes every 29 days. These are minimum intervals, not schedules — refreshing replaces the sandbox’s contents from production, destroying unsaved work, so teams should refresh deliberately: developer orgs per sprint, UAT per release cycle, and Full sandboxes timed around release previews.

Do you need a Full sandbox for UAT?

Usually not. A Partial Copy sandbox — production metadata plus up to 10,000 sampled records per selected object — gives business testers realistic data for acceptance testing at a fraction of the cost. A Full sandbox earns its price where complete data matters: staging rehearsals of deployments and migrations, performance testing at production volume, and release-preview testing. Many Enterprise Edition teams run UAT well on the Partial Copy included with their contract.

Trying to right-size the sandbox strategy in your own org? Talk to us — untangling environments is what we do all day.

Salesforce sandbox strategy: a practical guide for teams of 3 to 30