Sandboxes for small teams: you do not need five of them
A simple sandbox strategy when you are not an enterprise — dev, partial copy, and when to just use a scratch org.
Salesforce talks about Developer, Partial Copy, and Full sandboxes like everyone has a release train. If you are a 40-person company with one person configuring the org, you need a lighter plan.
Minimum viable setup
For most mid-market teams:
- Production — obvious.
- One sandbox for changes — Partial Copy if you have it, Developer Pro if data volume matters less. This is where all config and code land before release.
- Scratch orgs for devs — when you have Salesforce development (Apex/LWC), spin short-lived scratch orgs from your repo. Tear down when the feature ships.
That is it for a while. You do not need a separate "UAT sandbox" that mirrors prod until you have multiple teams stepping on each other.
Rules that save you
- No direct edits in production for anything except emergencies. Define emergency: "revenue stopped," not "rep wants a picklist value today."
- Change sets or CI/CD — even a simple Git repo with metadata retrieve/deploy beats clicking through Setup with no history.
- Refresh calendar — partial sandbox refreshed quarterly or before big projects. Stale sandboxes with ex-employees as active users waste everyone's time.
When to add another sandbox
Add a second long-lived sandbox when:
- Support and sales config changes collide weekly.
- You are running a major Salesforce implementation parallel to BAU fixes.
- Compliance wants UAT sign-off documented separately from dev experimentation.
Scratch orgs vs sandboxes
Scratch orgs are great for isolated feature work. They are bad as your only "test environment" if your bugs only show up with real data volume. Partial copy exists for that reason.
Messy sandbox habits cause production outages — usually from an untested Flow or a trigger that assumed sandbox data. Book a health check if you are not sure what is deployed where.