Salesforce offers four sandbox types. Developer and Developer Pro sandboxes copy your configuration but no data and can be refreshed daily. Partial Copy sandboxes add a sample of production data and refresh every 5 days. Full sandboxes copy all data and refresh every 29 days. Most companies need at least one developer-type sandbox for building and one data-bearing sandbox for testing and user acceptance, with a clear rule for what moves between them and when each one is refreshed.
What are the four sandbox types?
| Type | What it copies | Data storage | Refresh interval | Best for |
|---|---|---|---|---|
| Developer | Configuration and code only | 200 MB data, 200 MB files | 1 day | Building and trying changes, admin experiments |
| Developer Pro | Configuration and code only | 1 GB data, 1 GB files | 1 day | Development and QA that need loaded test data |
| Partial Copy | Configuration plus a sample of production data defined by a sandbox template | 5 GB data, files equal to production | 5 days | Integration testing and realistic QA |
| Full | Configuration and all production data | Same as production | 29 days | User acceptance testing, performance testing, training |
How many of each you get depends on your edition and contract. Salesforce's new Core, Advanced and Max editions list sandbox entitlements on their pricing pages, and those listings vary by cloud, so confirm what your contract includes before planning around a Full sandbox.
What sandbox setup does a typical team need?
Match the setup to how many people change the org and how risky the changes are.
- One admin making configuration changes: a Developer sandbox for building and a Partial Copy or Full sandbox for testing with real-looking data before go-live.
- A small team with a partner: a Developer sandbox per builder, a shared Developer Pro or Partial Copy for integration testing, and a Full sandbox for user acceptance.
- Larger programs with integrations and releases: individual Developer sandboxes, an integration sandbox connected to test versions of the ERP or other systems, a Full sandbox for user acceptance and training, and a documented path from one to the next.
How often should you refresh?
Refresh developer sandboxes whenever someone starts a new piece of work, so they build against current configuration. Refresh testing sandboxes at the start of each release cycle, after the previous release reaches production. Refreshing a Full sandbox mid-test wipes whatever testers set up, so schedule it and tell people.
- Keep a sandbox calendar: who owns each sandbox, what it is for and when it next refreshes.
- Write down post-refresh steps: update integration endpoints, deactivate scheduled jobs and emails that should not run, and reset test users.
- Check that integrations point at test systems, never at production, after every refresh.
How do you protect personal data in sandboxes?
Partial Copy and Full sandboxes contain real customer data, and sandbox access is usually broader than production access. Mask or remove sensitive fields after refresh, limit who can log in, and make sure email deliverability is set so test runs cannot send messages to real customers. Salesforce offers Data Mask for automated masking; smaller orgs sometimes use a post-refresh script. Either way, treat sandbox data under the same privacy rules as production.
What mistakes make sandboxes useless?
- Testing in a sandbox that has not been refreshed for months, so it no longer matches production.
- Building directly in production, which leaves sandboxes behind.
- Using Developer sandboxes for user acceptance, where testers have no realistic data to work with.
- Forgetting post-refresh steps, so a test run emails customers or writes to a live ERP.
- Giving everyone access to Full sandboxes that contain real personal data.
A clear sandbox setup is one of the first things we put in place in managed services engagements, because it is what makes every later release predictable.
