A sandbox refresh is the act of re-copying a sandbox from production. Whatever was in the sandbox is overwritten with production’s current state — same metadata, same data (for Partial Copy and Full), same users. It’s how you keep a sandbox aligned with the live org over time.
How to refresh
- Log in to production as a user with the Manage Sandboxes permission.
- Setup → Sandboxes.
- Find the sandbox in the list. Click Refresh next to it (or activate the option in the row).
- Adjust settings if you want — sandbox template for Partial Copy, post-copy Apex class.
- Confirm. Salesforce queues the refresh.
- Wait. Same timing as the original create: minutes for Developer, hours for Full.
- Email arrives when the refresh completes. The sandbox is activated (replaces the old version) automatically once you log in for the first time and confirm — or sometimes immediately on completion, depending on configuration.
What refresh actually does
It’s effectively a rebuild. The existing sandbox is replaced by a new copy:
- Metadata is re-copied from production.
- Data is re-copied (for Partial Copy and Full).
- Users are reset to mirror production.
- Post-copy Apex runs again.
- Email deliverability is reset to No access.
- Anything created in the sandbox since the last refresh is gone — unless it’s been deployed back to production first.
That last point is the trap. Treat sandbox refreshes as destructive.
Refresh interval
Each sandbox type has a minimum time between refreshes:
| Type | Interval |
|---|---|
| Developer | 1 day |
| Developer Pro | 1 day |
| Partial Copy | 5 days |
| Full | 29 days |
You cannot refresh more often than that. A Full refreshed today can’t be refreshed again until day 30. Plan accordingly.
Why refresh
- Sync with production code changes. When prod has had a release, sandbox is now behind. Refresh to catch up.
- Clean state. Throw away accumulated test data and config experiments.
- New realistic data. For Partial Copy / Full, get fresh production data for UAT.
- Pre-release rehearsal. Refresh staging from prod just before testing a release.
What you lose
Everything not yet deployed to production:
- Apex classes, triggers, LWCs you added in the sandbox.
- Flows you built.
- Custom objects, fields, layouts.
- Validation rules, permission sets.
- Test data records.
Before refreshing, deploy everything you want to keep back to production (or to another sandbox), or store the metadata in Git so it can be redeployed afterwards.
Post-refresh checklist
- Re-enable email deliverability (Setup → Email → Deliverability).
- Re-point integration endpoints to non-prod.
- Apply data masking (Salesforce Data Mask) if Full / Partial.
- Re-authorise connected apps / named credentials.
- Update or pause scheduled jobs that shouldn’t run.
- Re-test post-copy Apex did its job.
- Communicate to all sandbox users that their work is gone if they didn’t deploy it.
Refresh vs Clone
Two adjacent operations:
- Refresh — sync a sandbox with production. Destructive.
- Clone — create a new sandbox from an existing sandbox. The source isn’t destroyed; the clone is a sibling.
Clone is the right call when you want a snapshot of the current state of a sandbox without wiping it.
Activation
After a refresh completes, the new sandbox is in Pending Activation. You “activate” it by logging in (or via the Setup UI), which replaces the old org with the new. Activate carefully — once activated, the old version is gone.
Verified against: Salesforce Help — Refresh a Sandbox, Salesforce DX Developer Guide, Metadata API Developer Guide. Last reviewed 2026-05-17 for Spring ‘26 release.