Short answer
Use Developer sandboxes for building, a Partial Copy sandbox for testing with realistic data, and a Full sandbox for user acceptance testing and release rehearsal when your edition includes one. Never build in production, and never copy unmasked client data into a sandbox that more people can see than production allows.
The four sandbox types
| Type | What it copies | Refresh interval | Use it for |
|---|---|---|---|
| Developer | Metadata only, small storage | 1 day | One person building one change |
| Developer Pro | Metadata only, more storage | 1 day | Larger builds, integration work, test data loads |
| Partial Copy | Metadata plus a sample of records defined by a sandbox template | 5 days | QA and integration testing with realistic data |
| Full | Metadata and all data | 29 days | User acceptance testing, data migration rehearsal, performance checks |
Your edition and add-ons decide how many of each you have. Check Setup, then Sandboxes, before you plan the project.
A setup that works for most regulated firms
- One Developer sandbox per builder, named after the person or the work item, refreshed often.
- One shared integration or QA sandbox (Developer Pro or Partial Copy) where changes come together and integrations point at test endpoints.
- One UAT sandbox (Full or Partial Copy) that business users test in, refreshed before each UAT cycle.
- Production, which receives deployments only. No building, no "quick fixes" in Setup.
Client data in sandboxes
Partial Copy and Full sandboxes contain real records. For wealth, banking and insurance clients that means names, account numbers and sometimes tax IDs. Before anyone outside the production user base gets access:
- Mask or scramble personal data after each refresh (Salesforce Data Mask or a post-refresh script).
- Change integration endpoints and email deliverability so the sandbox can't email real clients.
- Limit sandbox logins to the people who need them, and remove them when the project ends.
Refresh checklist
- Tell everyone working in the sandbox; a refresh wipes their changes.
- Deploy anything unfinished from the sandbox to source control first.
- After refresh: run masking, reset integration credentials, set email deliverability, reactivate test users.
Official documentation
Frequently asked questions
How often can you refresh a Full sandbox?
Once every 29 days. Partial Copy sandboxes can be refreshed every 5 days, and Developer and Developer Pro sandboxes every day.
Is it safe to put real client data in a Salesforce sandbox?
Only with controls. Mask personal data after each refresh, stop the sandbox from emailing real people and limit who can log in. Sandboxes often have looser access than production, which is how data leaks happen.
Salesforce, HubSpot, Anthropic and OpenAI change their products often. Check the official documentation before you rely on a specific setting, limit or price.