Show me an org with a chaotic release process and I’ll show you an org with a chaotic sandbox strategy. The two are nearly always paired.

The good news: getting sandbox strategy right doesn’t require a giant project. It requires a clear answer to four questions: what each sandbox is for, who owns it, how it gets refreshed, and how changes flow between them.

A Working Sandbox PipelineDEVDeveloper ProPer-developerRefresh: anytimeQA / INTPartial CopyShared QARefresh: monthlyUAT / STAGEFull CopyBusiness signoffRefresh: pre-releasePRODThe real orgChange windowsNo surprisesEach environment has a job. Each refresh has a schedule. Changes only flow left to right.

Define what each sandbox is for

Most sandbox sprawl starts with vague purpose. Someone names a sandbox “Test1,” someone else builds a half-finished feature in it, and a year later nobody remembers what’s in there.

Pick a structure and stick to it:

• Dev sandboxes (one per developer/admin). Anything goes. Refresh whenever. The owner cleans up after themselves.
• QA / Integration (shared). Where multiple changes from multiple Dev sandboxes get assembled and tested together. Treat it as semi-shared: changes can be overwritten on the next refresh.
• UAT / Staging (Full or Partial Copy). Mirrors Production as closely as possible. Business stakeholders sign off here. No experimental work — if it lands here, it’s on its way to Production.
• Production. The only sandbox that matters in the end.

Refresh on a schedule, not on demand

The most common bug pattern I see in deployment failures: “it worked in QA.” Of course it did — QA was three months out of date with Production. Code that referenced a field that had since been deleted in Production passed QA tests fine.

Set a refresh cadence:

• Dev: refreshed by the developer when convenient (or after each release)
• QA: refreshed monthly
• UAT/Staging: refreshed before every release cycle, after Production stabilizes

Communicate the schedule. The first time a developer loses unmerged work to a refresh, they’ll learn to commit to source control. That’s a feature, not a bug.

Changes only flow one direction

Dev → QA → UAT → Production. Never the other way. “I fixed it in UAT and we’ll backport it later” is the start of the divergence that takes weeks to untangle. The fix gets made in Dev, gets retested through the pipeline, and lands in Production via the normal path.

This is also why source control matters more than your sandbox configuration. Sandboxes are runtime environments — source control is the single source of truth.

A few sandbox tactics worth knowing

• Use Sandbox Templates to control which records and metadata get copied into Partial Copy sandboxes. The default “whatever Salesforce decides” will surprise you.
• Use SeedData scripts or post-refresh automation to recreate test users, deactivate emails, and reset connection settings every refresh.
• Document the refresh process. The next person to do it shouldn’t have to reverse-engineer it.
• Tag every sandbox with its purpose in the description. “QA – shared, monthly refresh” is more useful than “Test1.”

The 30-minute fix

If you don’t have a sandbox strategy today, you don’t need to rebuild everything tomorrow. Start with this: open a doc, list the sandboxes you have, give each one a clear purpose and an owner, and set a refresh cadence. That’s usually a 30-minute exercise. The rest follows from there.