The Salesforce Winter '27 New Features That Aren't on Your Release Updates Checklist

Working through a Salesforce release usually starts and ends with the same list: which Release Updates enforce this cycle, who's affected, what breaks if you ignore them. That list matters, and Winter '27 has one worth checking before your org's upgrade weekend. But it's a compliance list, not a features list. It tells you what stops working if you do nothing. It doesn't tell you what you can now do that you couldn't do last release, which is the other half of what a release note is actually for.

This is that other half: the Winter '27 new features in Flow, Agentforce, and Experience Cloud worth knowing about now, during sandbox preview, rather than discovering by accident three releases from now when someone asks why nobody's using them yet. They're ordered here roughly by how many orgs each one touches, from the automation layer nearly everyone already uses down to a fix that only matters if you run a public-facing site.

The compliance list, briefly, if you haven't looked yet

Winter '27 release notes published August 19, 2026. Sandbox preview opened August 28. Production upgrades roll out across three weekends: September 4, October 2, and October 9, 2026, with the exact date for any given org listed on the Maintenance Calendar on Salesforce's Trust status site. A handful of Release Updates enforce this cycle, two of which change who can see Profile Names and who can edit Transaction Security Policies. That side of Winter '27 is covered in full, item by item, in Salesforce Winter '27 Release Notes: What Admins and Developers Need to Know and Winter '27 Is About to Change Who Can See What in Salesforce. Read it before enforcement day regardless of anything below.

Flow Builder gets closer to handling bulk work natively

The most requested kind of Flow feature has always been the same shape: let me do this to more than one record at once without writing Apex. Winter '27 makes this GA. A screen flow can now run as a mass quick action, configured on a list view or a related list, so it fires once against every record a user selects instead of once per record. Salesforce describes the underlying benefit plainly: run bulk operations without updating records individually or building complex workarounds. The flow receives the IDs of the selected records to work with. (When the action launches from a related list, the parent record's ID is reportedly passed along too, though Salesforce's own release note doesn't confirm that detail explicitly, so treat it as unverified until you've checked it in your own sandbox.) For any org that built a custom list-view button or a small Apex controller just to bulk-update a handful of fields across selected records, this is worth checking against that build: the more that controller does (per-record validation, rollback on partial failure, anything past a straight field update), the more likely it still earns its place. But for the simpler case it was usually built for, it changes the default answer to "do we need a developer for this" the next time the request comes in. Test record-count limits and failure behavior on a real list before retiring anything.

Flow Builder also picked up a way to classify and find flows: Flow Tags let an admin attach one or more tags to a flow, either when saving it or later from the Automation app, then view and filter flows by those tags, useful once an org has enough flows that finding the right one by name alone stops working. A beta Flow Test Mode adds a dedicated Test experience alongside Flow Builder's existing Build view, with support for saved, reusable test scenarios, mock inputs, and assertions that mark each scenario pass or fail, plus coverage tracking across every saved scenario that has an assertion attached. It's beta: opt-in, worth trying against a real flow in a sandbox, not something to plan a rollout around yet.

Agentforce gets a way to actually measure what an agent is doing

Once Flow's bulk-action gap is closed, the next-most-common layer to check is Agentforce: a smaller slice of orgs today, but a growing one. Once an agent is live, "is it working" stops being a question you can answer by reading a transcript occasionally. Winter '27 adds observability tooling built for exactly that problem. Custom Scorers, in beta, let a team define its own evaluation logic for an agent session, not just Salesforce's built-in quality metrics, but a pass/fail question tied to what the specific use case actually needs. A team might score whether the agent resolved a case without escalating it to a human, for instance, instead of relying only on a generic "did the agent respond helpfully" metric. That capability sits alongside Agentforce's broader analytics tooling, not in place of it. For any org past the pilot stage with Agentforce, this is what gives a team the option to build an actual basis for that trust, instead of just watching for obvious failures. It's a natural next step for anyone who went through the access and governance groundwork in the Agentforce readiness series; observability is the next layer once the access side is under control, not a replacement for it.

Experience Cloud sites on LWR can finally show a real report

Narrower still, and only relevant if your org runs a public-facing site: Lightning Web Runtime (LWR), the newer of Experience Cloud's two site frameworks, previously couldn't display a Lightning report at all. Anyone who needed a portal page to show one was stuck building on the older Aura framework instead, or working around the gap with a custom component. Winter '27 adds a component that puts an actual Lightning report onto an LWR page, with charts, tables, and record editing available directly on the page. Aura/LWR feature parity has been a multi-year, multi-gap project, and this closes one gap, not the whole list. If a missing report was specifically what's kept a site on Aura, though, it's worth testing whether that reason still holds.

What to actually do with any of this

Try each of these in a sandbox before deciding it matters to your org; none of it needs to ship to production on day one. What's worth carrying over from the compliance side of Winter '27 isn't a specific date, it's the habit: recheck Setup → Release Updates and the release notes themselves close to your org's enforcement date, not just once now. Salesforce revises scope and timing after first publishing a release regularly enough that both of the linked Release Updates pieces above flag it as a standing habit, not a one-off caution.

A release note is really two lists: what breaks if you ignore it, and what you can now do that you couldn't do last release. The first one gets read because it has a deadline attached. The second one is worth the same five minutes.

For the tooling side of Winter '27 prep, more broadly, see the Power User Toolkit overview.

Get Power User Toolkit on Salesforce AppExchange →