A.I. Foil
Voltar ao blog
Tiago Freitas

Two Salesforce Pages Disagree on the Winter '27 Sandbox Cutoff by One Hour. Use the Earlier One.

Two Salesforce Pages Disagree on the Winter '27 Sandbox Cutoff by One Hour. Use the Earlier One.

What is the August 27 cutoff, and why does one hour matter?

To land a sandbox on a Winter '27 preview instance, the create-or-refresh request has to finish by 2026-08-27. Salesforce Help publishes the cutoff as 6:00 PM PT. The Salesforce Admins release countdown publishes 5:00 PM PT. Two Salesforce-owned surfaces, one hour apart, three days out. Plan against 5:00 PM PT.

5:00 PM PT is 00:00 UTC on 2026-08-28, which is 21:00 in São Paulo on the 27th. The 6:00 PM reading buys you one more hour and is the only one of the two that can be wrong. There is no upside to taking it.

The rest of the calendar is stable across every source recorded so far: preview instances upgrade on 2026-08-28 and 2026-08-29, testing opens 2026-08-30, and the release notes went live on 2026-08-19.

Why does missing the cutoff fail silently?

A late request does not error. It completes, provisions the sandbox, and marks it Available. The sandbox just gets routed to a non-preview instance running the current release. No warning banner, no failed job, no email that says anything is wrong. Everything looks green.

You find out during test planning, three weeks later, when the Flow Test Mode or the Setup with Agentforce screen someone scoped work against is not in the org. By then the preview window is closed and the only remaining option is testing in production after the upgrade, which is not testing.

This is why the guidance is refresh today, not on the 27th. An in-flight copy at the deadline is treated as a miss, and a Full sandbox on a large org routinely takes hours, sometimes into the next day.

Can you even refresh? Check the lockout before you promise anyone a preview org

Salesforce enforces a minimum interval between refreshes of the same sandbox: 1 day for Developer and Developer Pro, 5 days for Partial Copy, 29 days for Full. A Full sandbox refreshed on or after 2026-07-29 cannot be refreshed again before the 08-27 cutoff. There is no override.

Open Setup, Sandboxes, and read the Last Refresh column before anything else. This is the single check that most often kills the plan, and it kills it for the orgs that need preview the most, since a Full sandbox is what the regression suite runs against.

If the Full is locked out, the fallback that still works: create a new Developer or Developer Pro sandbox before the cutoff. It carries metadata but not data, so it will not cover volume-dependent behaviour. It does cover deploy validation, Flow changes, and auth changes, which is most of what Winter '27 puts at risk.

Which weekend does the org upgrade to production?

Preview instances upgrade 08-28 and 08-29. Production is where the secondary sources fall apart. Three write-ups published within three weeks of each other give three different answers: 09-04 / 10-02 / 10-09, or 08-29 / 10-03 / 10-10, or a vague "across the October release weekends". Read the date off Salesforce Trust by instance name.

The disagreement is now wide enough that reconciling it is wasted effort. Look up the client's instance on Salesforce Trust and quote that, nothing else. Do not put a production weekend in a client email sourced from a roundup post, including this one.

One detail worth raising early: under the earlier reading, the gap between preview and the first production wave can be one week, not the six weeks people assume. And on a multi-org client, instances can sit six weeks apart. A single shared test plan across those orgs is wrong the moment you write it. The plan has to be per instance.

What should you inventory before the refresh, not after?

Winter '27 retires the OAuth 2.0 username-password flow for connected apps. grant_type=password stops returning an access token, and the release update cannot be opted out of. Sources conflict on when: at each org's own Winter '27 upgrade, or 2027-02-20. Read the release update inside the client's org and plan for the earlier date.

The difference between those two dates is roughly five months of migration runway, so do not settle it from a blog. Setup, Release Updates, in the client org states the enforcement date for that instance. Planning for September and being granted February is recoverable. The reverse is an outage.

Now the part that makes this annoying: no platform log records the grant type of a past login. There is no field to filter on. The inventory is indirect, and it is two passes.

First, find which callers authenticate through OAuth at all. LoginHistory retains 6 months:

SELECT LoginTime, UserId, Application, LoginType, ApiType, SourceIp, Status
FROM LoginHistory
WHERE LoginTime = LAST_N_DAYS:90
  AND LoginType = 'Remote Access 2.0'
ORDER BY LoginTime DESC
LIMIT 200

Second, cross-check against Setup, Connected Apps OAuth Usage, which lists every app holding tokens with its user count. Sort by integration users and ignore the interactive ones.

Neither pass proves a caller used grant_type=password. They narrow the list to the handful of integration users and connected apps you then grep for in middleware config. On a ten-year-old org that grep is the slow part, usually slower than the refresh itself, because half the integrations were built by a vendor who is no longer under contract.

Three replacement flows, pick by who the caller is: client credentials for server-to-server with a designated integration user, JWT bearer when you want certificate-based auth with no stored secret, web-server flow with PKCE when the call has to run as a real user. Put the secret in a Named Credential, not in Apex, not in a custom setting. Separately, the SOAP login() call retires 2027-06-01, so any middleware still calling it goes on the same list.

Is a preview sandbox worth it if the org is not doing Agentforce?

Sometimes no. If the org has no Agentforce topics, no Data 360 configuration, light Flow usage and no username-password integrations, skipping preview costs you little. You test after the org upgrades, and the exposure is one weekend of watching error logs.

The case for preview is specific rather than general. Winter '27 ships 17 Flow changes, including the largest Flow Builder visual overhaul since launch and a native Flow Test Mode enabled in Process Automation Settings. If a team runs heavy Flow automation, custom LWC on Flow screens, or the auth retirements above touch their integrations, the preview window is the only place to find out cheaply.

There is also a middle option people forget: a pre-release org. Signup opened 2026-08-13. It is free, it has none of your metadata, and it is enough to answer "does this feature do what the release note says" without spending a refresh slot. Use it for feature evaluation and keep the sandbox slot for regression against real metadata.

What to do in the next three days

Six steps, in order, all of them checkable:

  1. Setup, Sandboxes: read the Last Refresh date on every sandbox. Anything Full refreshed on or after 2026-07-29 is locked out until after the cutoff.
  2. Start the create or refresh today, targeting completion well before 2026-08-27 17:00 PT (21:00 in São Paulo). The deadline is on the finish, not the submit.
  3. If the Full is locked, create a Developer Pro before the cutoff as the fallback preview org.
  4. Look up each org's instance on Salesforce Trust for its production upgrade date. Multi-org clients get one test plan per instance.
  5. Run the LoginHistory query and open Connected Apps OAuth Usage. Build the list of integration users to check for grant_type=password and SOAP login().
  6. Open Setup, Release Updates in the client org and read the enforcement date Salesforce states for that instance. That date beats every secondary source, including this post.

Step 5 is the one that outlives this release. The sandbox deadline passes on Thursday and stops mattering. An undocumented integration authenticating with a username and a password keeps mattering until someone writes it down.