ChatGPT
Claude
PerplexityEvery article about Salesforce sandboxes opens with the same table. Four types, what each copies, how often it refreshes. Useful once, and it leaves out the decision that actually causes trouble.
Your sandbox does not choose which Salesforce release it runs. The instance it was provisioned on chooses, and you influence that only by the timing of a refresh. A team can pick the right sandbox type, size it correctly, seed it properly, and still find their UAT environment jumping a release mid-cycle because nobody checked a field called Release Type.
This page is about the decisions that sit underneath the table.
Sandbox strategy is an instance assignment problem before it is a type problem
Two sandboxes of the same type, in the same org, created two weeks apart, can be running different versions of Salesforce. That surprises people, and it follows directly from how Salesforce groups environments.
Sandboxes live on instances. Instances are divided into preview and non-preview. When a major release approaches, every sandbox on a preview instance moves to the new version together, and every sandbox on a non-preview instance stays where it is. Nothing about the sandbox type enters into it.
So a sandbox strategy has two layers, and most published advice covers only the first.
| Layer | What it decides | How you control it |
|---|---|---|
| Type | What gets copied, storage, refresh frequency | Choose at creation; governed by edition and entitlement |
| Instance group | Which Salesforce release the sandbox runs | Only by when you create or refresh it |
That second row is where projects get hurt, because its only lever is a date.
Preview instances upgrade six weeks ahead of the release
Salesforce documents the mechanic plainly. Sandbox preview is a six-week window ahead of a major release during which all preview sandboxes are upgraded to the next version. It is the first opportunity to test configuration against the release that is coming.
Winter ’27 makes the dates concrete. That preview window opened on 28 August 2026, and to be included a sandbox had to be active on a preview instance by 27 August, specifically before 6:00 PM Pacific, which is 01:00 UTC the following day.
Salesforce’s own Trailhead guidance names the reason this matters more than it sounds. Some release features are enabled automatically, and those become immediately visible to every user the moment the release reaches production. You do not opt into them. A preview sandbox is the only opportunity to see what they do inside your own configuration before your users do.
Read what that gives you and what it costs. A preview sandbox is six weeks of advance warning on anything the release breaks, which for an org with meaningful customization is the difference between finding a regression in September and finding it in front of users. A non-preview sandbox is six weeks of stability, which is what a project in the middle of user acceptance testing actually needs.
Neither is correct in general. What is incorrect is having both kinds and not knowing which is which, because then the release arrives in whichever environment the project least wanted it.
The Release Type field names which group a sandbox sits in
Salesforce’s instruction is to check whether the Release Type of the sandbox reads preview, meaning it will upgrade, or non-preview, meaning it will not. Its own guidance adds a reassuring note that usually no action is required, because most sandboxes are already on a preview instance.
That reassurance is accurate and it is also how teams get caught. Default behavior puts you on preview, which is right for an org doing continuous enhancement and wrong for an org three weeks from go-live. That default is a choice somebody else made.
Worth building into a project routine rather than remembering: record the Release Type of every sandbox alongside its purpose, and check it again after any refresh, since refreshing is precisely the operation that can move it. An environment register with four rows and three columns prevents the entire class of problem, which is a poor return on effort only if you have never lost a week to it.
Refresh timing is the only lever that moves a sandbox between groups
This is the sentence worth memorizing from Salesforce’s documentation: the only way to change the upgrade status of a sandbox is to move it to another instance by refreshing it.
Nothing in Setup toggles it, and no request moves an existing sandbox between instance groups once it is provisioned. A sandbox goes where the refresh puts it, and refresh timing is governed by the cutoff.
Three consequences for planning.
A refresh request that does not complete before the cutoff misses the window. Requesting on the final afternoon is a gamble on provisioning time, and provisioning a Full sandbox is not instantaneous.
Refresh cadence and release cadence collide on purpose. Salesforce ships three major releases a year, so any project running longer than a quarter has at least one preview window inside it. Treating the refresh calendar and the release calendar as separate plans is how a UAT environment changes version on day four of testing. How that interacts with an overall schedule is covered in the implementation timeline.
And a refresh is destructive to everything you added. That is the subject of the seeding sections below, and the reason refresh timing is a data decision as much as a release decision.
Requesting non-preview needs an org permission Salesforce grants by case
Here is the operational detail that separates a real sandbox strategy from a diagram, and almost nothing published covers it.
If you want a sandbox to stay on the current release through a preview window, Salesforce offers a Request Non-Preview option when you create or refresh before the cutoff. That option is not available by default. It is enabled through an org permission, and to get that permission you have to contact Salesforce Customer Support.
Once granted, the permission persists: the Request Non-Preview option becomes available for sandboxes created in that org during future preview request windows.
So the sequence matters. You cannot decide during a preview window that you want to opt out, because the permission request sits upstream of the cutoff and support cases take time. A team that wants release control needs that permission before it needs it, which in practice means raising the case in a quiet month rather than the week a go-live is at risk.
For an org that runs projects continuously, getting the permission once is cheap insurance. For an org that has never heard of it, the first time it matters is also the first time it is too late.
A four-environment path covers most mid-market projects
With the instance question settled, the type question becomes straightforward, and the honest answer is that most projects need fewer environments than they build.
A path that holds up: a Developer sandbox per builder for isolated work, a shared Developer Pro or Partial Copy for integration where changes meet each other, a Partial Copy or Full for user acceptance testing with representative data, and production. Four tiers, each with a named purpose and an owner.
Two failure modes bracket that.
Too few, where development and UAT share an environment. Testers then validate against configuration that changed under them during the test, and every defect report becomes an argument about which version was being tested.
Too many, where seven sandboxes exist and nobody knows which holds the current truth. Deployment order becomes folklore, and metadata drifts between environments in ways that surface only at go-live. What tooling does and does not solve here is examined in DevOps tooling versus AI-native delivery.
Entitlement constrains all of this, since sandbox allowances vary by edition and additional sandboxes are a purchase. What they add to a running total is broken out in what extra sandboxes add to the bill.
GetGenerative.ai keeps the environment register current without someone maintaining it
An environment register is the artifact this page keeps recommending, and in practice it is a spreadsheet that was accurate in week two.
Its cause is ordinary. Sandboxes get refreshed by whoever needs one, Release Type changes as a side effect, someone spins up a Developer sandbox for a quick test and it becomes load-bearing. Keeping a written record aligned with reality is unbilled work that competes with delivery, so it loses.
The Metadata Agent inside GetGenerative.ai reads the org directly, which changes what the register is. Rather than a document someone updates, environment and configuration facts come from what is actually deployed, so a design or a deployment plan is written against the org as it stands rather than as it was described. For a sandbox strategy specifically, that matters when a design assumes a field exists in UAT because it exists in dev.
What it does not do is make the release-timing decision. Whether this project wants six weeks of warning or six weeks of stability is a judgment about risk appetite and go-live dates, and it belongs to whoever owns the date. Teams who want that path scoped before a build starts can see how delivery gets planned.
Sandbox templates decide which records arrive, and the default is none
Seeding is where sandbox strategy stops being administration and starts affecting whether testing means anything.
Developer and Developer Pro sandboxes copy configuration only. No records arrive. That is correct for building and useless for validating, and it is the quiet reason a feature that worked in dev fails the moment a tester opens it against real data shapes.
Partial Copy and Full behave differently, and Partial Copy introduces the sandbox template: the artifact that defines which objects, and therefore which records, come across.
Framed by what arrives rather than by storage, the four types answer different questions.
| Type | What arrives | The question it can answer |
|---|---|---|
| Developer | Configuration only | Does this build work in isolation |
| Developer Pro | Configuration only, larger capacity | Do several builds work together |
| Partial Copy | Configuration plus a templated sample | Does this work against data shaped like ours |
| Full | Configuration plus all production data | Does this work at our volume, with our edge cases |
Read the right-hand column as a sequence of claims a project needs to make, in order. A team that validates only in the top two rows has proved the configuration is internally consistent and nothing more. A team that insists on the bottom row for everything pays for capacity and refresh time it did not need, and waits longer between resets than the project can afford. Templates are where seeding decisions actually get made, and they get made badly when nobody owns the object list.
Three questions make a template useful rather than arbitrary.
Which objects does the test plan touch, including the ones nobody thinks of as data? Record types, price books and queue assignments break tests as reliably as missing Accounts.
Which relationships must stay intact? A sample of Opportunities whose Accounts did not come across produces a sandbox full of orphans and a tester filing defects against the seeding rather than the build.
Which objects carry the awkward records? Edge cases are the point of representative data, and a clean sample is the one thing guaranteed not to find the bug.
How that data should be constructed, and what to do about personal information inside it, is a discipline of its own, set out in test data management. Salesforce Data Mask exists for the anonymization half of that problem and belongs in any seeding plan that copies production records.
Seeded data does not survive a refresh, so seeding has to be repeatable
Most sandbox failures are not about choosing the wrong type. It is treating a seeded environment as durable.
A refresh replaces the sandbox. Configuration comes from production, and everything added by hand since the last refresh is gone: the twelve test Accounts with deliberately broken addresses, the user that reproduces the sharing bug, the Opportunity sitting at exactly the approval threshold. If those were created manually, they are recreated manually, which means they are recreated inconsistently or not at all.
Treat seed data as code instead. A repeatable script or data set that runs after every refresh, versioned alongside the configuration it supports, owned by someone named. Then a refresh costs an hour of automated loading rather than three days of someone remembering what used to be there.
That discipline is what makes refresh cadence a decision instead of an event people dread. Teams that can reseed in an hour refresh often, which keeps environments close to production. Teams that cannot refresh as rarely as possible, which is how a UAT sandbox ends up six months behind the org it is supposed to represent. Where this all lands is the cutover sequence it feeds, and what gets validated in the seeded environment sits in the UAT guide.
Agent iteration in a sandbox is metered, which changes what the environment is for
Agents added a dimension to sandbox strategy, and the common assumption about it is wrong in a way that costs money.
A sandbox is not a free place to experiment with agents. Salesforce prices pre-production usage separately from production, and the discount is partial and uneven: agent actions cost less in a sandbox, prompts carry no sandbox discount at any tier, and a preview run counts as metered usage while the agent is still being developed. Testing through Agentforce Builder, Agentforce Grid and Testing Center is metered as well, batch runs included. Only building an agent is unmetered. Figures behind that split are set out in the split between production and pre-production rates.
Read the consequence for environment planning, because it inverts the usual instinct. The question is not where to move agent work so that it costs nothing, because nowhere does. The question is how to make each metered iteration count, which turns a sandbox from a safe space into a budgeted one.
Two things follow. Give agent work an environment with representative data from the start, since an agent grounded on a thin sandbox produces iterations that teach you little and bill you anyway. And hold that environment stable through the tuning period, because a release landing mid-tuning means re-running batch tests you have already paid for, which is a direct argument for non-preview status during an agent build. Pre-activation checks that depend on environment state are set out in the checks that depend on environment state.
Questions that decide a sandbox plan
How do I know which Salesforce release my sandbox will run?
Check the Release Type of the sandbox. Preview means it will be upgraded to the next major release during the preview window; non-preview means it stays on the current release. That value follows the instance the sandbox sits on, not the sandbox type, and Salesforce notes that most sandboxes are on preview instances by default.
What is sandbox preview in Salesforce?
A six-week window ahead of each major release during which all sandboxes on preview instances are upgraded to the new version, giving teams an early opportunity to test configuration. For Winter ’27 the window opened on 28 August 2026, with a cutoff of 6:00 PM Pacific on 27 August for a sandbox to be active on a preview instance.
Can I stop a sandbox being upgraded during preview?
Yes, with preparation. Salesforce offers a Request Non-Preview option when creating or refreshing a sandbox before the cutoff, but it is not available by default. The option is enabled through an org permission obtained by contacting Salesforce Customer Support, after which it remains available for sandboxes created during future preview windows.
How do I move a sandbox to a different instance?
By refreshing it. Salesforce states that refreshing onto another instance is the only way to change a sandbox’s upgrade status, and the refresh has to complete before the preview cutoff date to count. There is no setting that reassigns an existing sandbox.
How many sandboxes does a Salesforce project need?
Usually four tiers: an isolated Developer sandbox per builder, a shared environment where changes integrate, a Partial Copy or Full with representative data for user acceptance testing, and production. Fewer causes testers to validate against shifting configuration; more causes confusion about which environment holds current truth.
Does seeded sandbox data survive a refresh?
No. A refresh replaces the sandbox from production, so manually created test records, users and edge cases are lost. Seed data should be a repeatable script or data set, versioned with the configuration it supports, so reseeding after a refresh takes an hour rather than days.
