Whether a sandbox gets the next release early is decided by which instance it sits on, and that is fixed when the sandbox is created or refreshed — not by a setting you can toggle later. If you want to test on the preview version, you must create or refresh the sandbox during the window Salesforce publishes before each release. Miss it and you are testing after production has already upgraded.
How it works
Ahead of each release, Salesforce upgrades a subset of sandbox instances early. Sandboxes on those instances run the new version for roughly a month before production orgs get it. Sandboxes on non-preview instances stay on the current version until general availability.
Your sandbox’s instance is visible in Setup → Company Information, as the Instance field, and on the sandbox list in Setup → Sandboxes.
There is no “enable preview” checkbox. The only lever is when you refresh, because a refresh can place the sandbox on a different instance.
The window, and why it is easy to miss
Salesforce publishes a preview schedule for each release with a cutoff date. Create or refresh a sandbox before the cutoff and it lands on a preview instance. After it, it does not.
Two things trip teams up. The cutoff is weeks before the preview itself begins, so by the time people are thinking about the release it has passed. And a refresh takes time, a full sandbox can take considerably longer than a developer sandbox, so starting on the deadline is not the same as making it.
Put the cutoff dates in a shared calendar for all three releases at the start of the year. That single habit is most of what separates teams that preview-test from teams that intend to.
Which sandbox to put on preview
| Sandbox | Preview? | Why |
|---|---|---|
| Integration / SIT | Yes | Where release regressions actually show up |
| UAT / staging | Usually not | Must mirror production for sign-off |
| Developer sandboxes | One or two | Enough to try new features |
| Production support / hotfix | No | Must match production exactly |
The reasoning is that a preview sandbox is deliberately not like production, which is exactly what makes it useful for finding regressions and useless for validating a hotfix. Teams that put everything on preview lose the ability to reproduce a production bug, which is a bad trade for a month of early access.
So: at least one preview sandbox, and at least one that is not.
What to test in the window
The window is short, so spend it on what actually breaks.
- Release Updates due for enforcement. These have deadlines and usually a test mechanism. Highest value, every time.
- Integrations. Every inbound and outbound integration, exercised once. API behaviour changes are the most damaging and least visible category.
- Your heaviest automation. The objects with the most triggers and flows, at volume, not with one record.
- Anything using a retiring API version. Check the inventory rather than waiting for a failure.
- Custom UI. LWC and Visualforce against the new version, particularly anything using base components whose markup can shift.
What not to spend the window on: evaluating new features you might adopt later. That is a backlog activity and it will still be there after GA.
Practical cautions
Do not deploy from a preview sandbox to production. Metadata authored against the newer API version can fail against the older production version, and the failure is confusing. Keep the direction of travel one way until production catches up.
Refresh resets the data. Whatever seeding or configuration your sandbox carries has to be reapplied. If that is a manual process, the refresh cost is higher than the refresh time, which is an argument for scripting it once.
Sandbox refresh intervals apply. Developer sandboxes refresh frequently, full sandboxes far less often. A full sandbox you refresh for preview may be one you then cannot refresh again for some time — check the interval before you spend it.
Check the instance after the refresh. It is the only way to know you actually got preview, and it takes one look at Company Information.
If you missed the window
You have options, none as good as preview:
- A scratch org on the preview release, where your project supports it, gives you a place to test the new version without a sandbox refresh.
- Read the Release Updates page and act on the deadlines regardless. Most of the risk is there and it does not require a preview org.
- Test immediately after GA in a non-production sandbox, and be ready to respond rather than to prevent.
The honest position: missing preview is a missed opportunity, not a disaster, provided you are working the Release Updates list. Teams that skip both are the ones that get hurt.
Frequently asked
Can I request that my sandbox be moved to a preview instance?
Instance placement is not something you select directly. A refresh during the window is the supported route. Support cases asking for a move are not the mechanism.
How long does the preview period last?
Roughly a month between preview instances upgrading and general availability, and the exact dates are published per release.
Will my sandbox stay on preview for future releases?
Do not assume so. Check the instance each cycle rather than relying on last time’s outcome.
Does a preview sandbox affect production at all?
No. It is a separate org on a separate instance, and production upgrades on its own schedule.
Can I test Release Updates without preview?
Many Release Updates can be activated early in any sandbox from the Release Updates page, which lets you test the specific change without the whole new version. That is often the most valuable testing available and it does not need preview at all.
Reference: Sandbox Preview, Release Updates and Sandbox Types and Templates, Salesforce Help; Salesforce Release Notes.
