Salesforce Sandbox Refresh: What Changes, What You Lose, and How to Plan

Refreshing a Salesforce sandbox is one of the most common actions in a Salesforce DevOps workflow — and one of the most consequential. The refresh replaces the entire sandbox environment with a new copy from production. Everything in the sandbox that is not in source control, or that has not been deployed to production, is gone permanently.

Understanding exactly what happens during a refresh, what you lose, and how to plan around the platform's refresh intervals is foundational DevOps knowledge for any Salesforce team.

What a sandbox refresh does

A sandbox refresh creates a new copy of your production org and overwrites the existing sandbox with it. The sandbox receives the current state of production metadata — all your custom objects, Apex classes, flows, permission sets, profiles, and every other piece of configuration in production at the time of the refresh.

For Partial Copy and Full Copy sandboxes, the refresh also copies data records according to the sandbox template or the full production dataset respectively. Developer sandboxes receive metadata only.

Everything in the sandbox that existed before the refresh is overwritten. Work in progress — Apex code not committed to source control, custom fields built directly in the sandbox UI, flow modifications, test data — all of it is gone when the refresh completes.

What you lose in a refresh

The practical impact depends entirely on your team's version control discipline. If all code and metadata changes are committed to git and tracked through Salesforce CLI, a refresh is a routine reset that takes minutes to recover from. If your team has been building directly in the sandbox without committing, a refresh can mean significant work lost.

The specific categories of data that refresh removes:

• Any Apex code created or modified in the sandbox that has not been deployed to production or committed to source control
• Custom objects, fields, or metadata changes made directly in the sandbox Setup UI
• User accounts created specifically for sandbox testing (they are replaced with production users)
• Test data records created for QA or UAT purposes
• Environment-specific configuration — custom settings values, named credentials pointing at sandbox endpoints

How to preserve sandbox work before refreshing

The standard approach before any refresh: retrieve all modified metadata from the sandbox using Salesforce CLI and commit it to version control. The command is sf project retrieve start --target-org your-sandbox-alias --output-dir force-app. Review the retrieved metadata and commit everything you want to keep before initiating the refresh.

For test data, you have two options: re-seed via a post-copy Apex class that runs automatically after refresh (the recommended approach for consistent, repeatable test environments), or manually reload via Data Loader or a data import after the refresh completes.

Environment-specific configuration — any named credential or custom setting that differs from production — needs to be documented and re-applied after refresh. This is a common cause of issues after sandbox refreshes: the environment looks correct but external integrations fail because the endpoint configuration reverted to the production values.

Refresh intervals and planning

Salesforce platform refresh limits:

• Developer and Developer Pro: once per day
• Partial Copy: once every 5 days
• Full Copy: once every 29 days

The interval starts from the last refresh date, not from when you initiate a new one. If you refresh a Full Copy sandbox on the 1st, the next eligible refresh date is the 30th — regardless of when you actually trigger it.

Full Copy refresh timing should be treated as a release planning constraint. For teams doing quarterly releases, the Full Copy sandbox should be refreshed at the start of each release cycle — not mid-cycle when you want a clean environment for testing but have already used your 29-day window.

Sandbox Clone vs Sandbox Refresh

Sandbox Clone creates a new sandbox based on an existing sandbox state — not from production. This is useful when you want to branch at a known-good point. If your QA sandbox is in a stable state at the end of sprint 3 and you want to start sprint 4 testing without disrupting an ongoing QA test cycle, clone the QA sandbox rather than refreshing it.

Clone consumes one of your sandbox license allocations. Refresh updates an existing sandbox without using additional allocations. Use clone when you need to preserve the current sandbox state while starting fresh elsewhere. Use refresh when you want to reset to the current production state.

The refresh process

In Setup, go to Environments → Sandboxes. Find the sandbox you want to refresh and click Refresh. You'll be able to update the sandbox name (it remains the same), change the type, update the post-copy Apex class, and for Partial Copy sandboxes, update the template.

During refresh, the sandbox is unavailable. Developer refreshes complete in minutes to hours. Partial Copy takes 1-4 hours. Full Copy can take 24-48 hours. Salesforce sends an email when the refresh is complete. Plan refresh timing so it does not coincide with active development or QA work in that environment.