The sandbox that was never on a preview instance
It is the third week of September, the release manager asks for the regression pack to go into the main test sandbox, and the admin who opens it finds the current release still running. That sandbox is not on a preview instance and never has been. Nobody chose that. It was built four years ago by someone who has since left.
Preview happens on preview instances. Whether a sandbox sits on one is a property of the instance rather than a setting anybody can toggle, so the only way to change it is to refresh onto a different instance. Everything below follows from that, because the environment you test a release in has to be chosen long before the notes appear.
Our coverage of the seasonal release calendar and the preview window carries the dates. This guide is about the estate those dates land on. Most orgs do not have a sandbox problem in September. They have an estate that grew one request at a time, and the preview window is the first moment anyone has to explain it.
Name environments for the job they do
Start with what each environment is for, in words a project manager can repeat back. A development environment where one named person builds. An integration environment where work from several developers meets. A test environment where a business user runs a scenario end to end. A staging environment close enough to production to rehearse a deployment. A release-testing environment carrying the next version of the platform.
Naming matters more than it sounds. Teams that name environments after the sandbox type end up with a collection nobody can explain, because the type records what Salesforce provisioned and says nothing about who uses it or what may be deleted. Ask a room what happens in a sandbox called Full1 and you get four answers. Ask about one called release-test and the answer is in the name.
Purpose naming also settles requests. When a team asks for another sandbox, the question is which job on the list it does. A job nobody is doing yet means a new environment, with an owner and a refresh schedule attached. A job an existing environment already covers means a second copy that will drift inside a month. The same argument runs through Power Platform environment strategy and carries across platforms.
Which environments need production volume
The second decision is which environments need a copy of production data and which need only metadata. That looks minor on a design document. It drives refresh cost, refresh duration and how stale each environment is allowed to get.
Developers rarely need production volume. They need the configuration, a few records shaped correctly and the ability to reset quickly. A metadata-only environment refreshes fast, so a developer can start clean on Monday without asking anyone. Performance work, migration rehearsals and reporting over large record counts do need the volume, because the defect you are hunting only appears at scale.
The cost lands as time. A full copy takes far longer to refresh and usually carries a longer minimum interval between refreshes. Entitlements and intervals depend on your edition and your agreement, so confirm them from the sandbox list in your own org rather than from any article. An environment you can refresh only occasionally holds work that is expensive to lose, and that changes who may ask for a refresh.
The one environment to protect above the others
One environment carries a requirement none of the others do. The release-testing environment has to sit on a preview instance, and because placement changes only through a refresh, that requirement needs checking and keeping rather than assuming.
Protecting it means three things. Somebody owns it by name and knows it. Its instance is recorded where people already look, beside the rest of the release paperwork. And it is not the environment a project borrows in July because a deadline moved, since the refresh that hands it back can land it on a non-preview instance.
If you protect one thing in the whole estate, protect this one. An org survives a messy development sandbox without much drama. It cannot test a seasonal release at all without an environment running the next release, and the September remedy is a refresh that destroys whatever that environment held. Confirming the instance in June takes a minute.
Refresh timing is the argument nobody schedules
Refreshing the wrong environment at the wrong moment destroys work that exists nowhere else. A half-built flow. A permission set tuned over six weeks. Test data somebody assembled by hand. The connected app configuration your middleware points at. A refresh copies production over all of it and none of it comes back.
The release window is when several teams want a refresh at once. The project team wants a clean environment to rehearse a deployment. The release manager wants the preview environment ready. The data team wants a recent copy for a migration dry run. All three arrive in the same fortnight, and the intervals often will not permit a second attempt if the first one lands wrong.
Publish a refresh calendar before the season starts, with a named approver per environment and a rule that requests arrive a week ahead. The rule that saves the most pain is that nobody refreshes an environment they do not own. The change approval board that moves is the right venue, because a refresh removes work other people depend on.
What a copy of production brings with it
Copying production into a sandbox copies the personal data in it. Customer names, home addresses, phone numbers, case notes describing somebody's health or finances. That copy lands in an environment with a wider user list, a weaker password policy and often a contractor who reads records to debug. Masking is a legal obligation under most data protection regimes rather than a good practice, and it does not soften because the environment is called a sandbox.
Decide masking per environment rather than once for the estate. An environment only a few named admins can reach may keep readable data under something your privacy team signed off. One where partners, contractors and new joiners hold logins should not. Make masking part of the refresh procedure, because the gap between the refresh finishing and the masking running is the window where data sits exposed.
The recurring incident is an environment pointing at the wrong place. A refreshed sandbox inherits endpoints and credentials from the org it was copied from, and some may still address a production partner system. Named credentials, remote site settings, a custom setting holding a base URL, a connected app aimed at a live payment provider. The refresh cannot know which address is a test one.
Somebody usually finds out when test data reaches a live third party, a purchase order in a supplier's real system or a test contact receiving a real email. Build a post-refresh script that resets every outbound endpoint to a sandbox value and disables the integration users until a person re-enables them, and run it before anyone logs in. The list of outbound connections per environment is the same one you need to tell a connector from an integration.
Spend the preview window on what would hurt most
Decide in advance what you are testing. Covering everything is not possible for any org with real customisation, and a team that tries spends the first week deciding where to start. What works is a ranked list of the integrations and customisations that would hurt most if they broke, agreed with the people who own those processes before the preview instances are upgraded.
Get real users to look. Administrators test what they built and know where to click, which is why an admin pass rarely catches the layout change that stops a service agent closing a case without a second screen. Book two hours with people who use the org all day, hand them the scenarios they run every morning, and watch.
Record what you checked, in enough detail that next season starts from the last list instead of from memory. Release version, date, environment, who tested, what passed, what broke and what you chose to accept. That record is also the argument for a longer window next time. File it beside a release checklist for shared solutions.
Before the next preview upgrade, walk the estate once and answer these for every environment you own.
- The written purpose of this environment and the person who owns it.
- Whether it holds a copy of production data or metadata only.
- Which instance it sits on, and whether that instance takes preview.
- The refresh interval you have confirmed in your own org, not the one you assume.
- Who approves a refresh, and what is lost when one runs.
- Whether masking and endpoint resets run as part of the refresh.
- Where last season's test results are filed.
