Releases · Intermediate · For developers, admins and QA · 8 min read

Salesforce Winter '27: what changes for developers, admins and QA

The headlines of Winter '27 are about AI agents. This is the rest of the release: the platform changes that affect daily work, grouped by who has to act on them.

Winter '27 is API version 68.0. Most of what Salesforce announced for it concerns Agentforce, and you will find that covered everywhere. This overview is about the quieter part: limits, permissions, flows, testing tools and the retirements that now have dates.

Each item says whether it is generally available, a beta or a developer preview. That label matters: betas and previews are not for production, and some of them are not even available there. Everything below comes from the official Salesforce Winter '27 Release Notes; read the entry for a feature before relying on it, because release notes are amended after publication.

What changes without anyone doing anything

Start here. These arrive with the upgrade, whether or not your team has read a single release note.

• Apex heap limits go up — from 6 MB to 10 MB for synchronous transactions and from 12 MB to 25 MB for asynchronous ones, automatically, in every org that runs Apex.
• Profile filtering is enforced. A user sees only their own profile name unless they hold the View All Profiles permission.
• Accessibility changes for page headers and modal windows are enforced. Above 200% zoom the page header scrolls with the page instead of covering it, and modal content stays inside the viewport.
• Flows retry on a record lock. A flow that meets a lock while its transaction is starting now waits 10 seconds and tries again instead of failing with UNABLE_TO_LOCK_ROW.

For developers: Apex

Heap limits (generally available). The new 10 MB and 25 MB ceilings need no opt-in. To see what an org currently enforces:

System.debug(Limits.getLimitHeapSize());

One transitional detail: if you build in a Winter '27 sandbox and deploy to a production org that is still on Summer '26, code can pass in the sandbox and run out of heap in production. For that case, nonproduction orgs have a setting under Apex Settings in Setup, Enforce the Summer '26 Apex heap limit, which holds them to the old values. From Spring '27 the higher limits apply everywhere regardless of it. And a larger heap is headroom, not a design: it does not make a query selective or a loop cheaper.

Recompile only what is invalid (generally available). Instead of recompiling every class in the org, you can ask for the classes and triggers that actually have errors, from Setup or through a new Tooling API endpoint in version 68.0:

POST /services/data/v68.0/tooling/apexCompileResults HTTP/1.1
Authorization: Bearer <session-id>
Content-Type: application/json

{}

The response lists each invalid class with the line, column and message of every problem. In a large org this is a quick health check to run after a deployment.

Integration tests with real callouts (developer preview). Apex tests have always required mocks for HTTP. Integration tests remove that restriction: a class and its methods annotated @IntegrationTest can call real endpoints, including External Services behind Named Credentials, and their data is committed, not rolled back — so @BeforeClass prepares it and @TearDown has to delete it. The preview is limited to scratch orgs with the feature switched on:

{
  "orgName": "My Company",
  "edition": "Developer",
  "features": ["ApexIntegrationTests"]
}

Only one integration test runs at a time, asynchronously, and a mock registered with Test.setMock() still takes precedence over the real endpoint. Worth a trial in a scratch org; not something to build a pipeline on yet.

Warnings for very old Apex. Classes and triggers saved at API versions 9.0 to 19.0 now produce a compiler warning, because those versions are scheduled for retirement in a future release. Move them to 20.0 or later — in practice, to a current version — while it is still a warning.

For developers: LWC and APIs

• LWC API version 68.0 has no version-specific changes. Salesforce itself calls that a good moment to bring existing components up to date. Upgrade one version at a time and fix warnings as you go.
• Third-party web components (generally available). The lwc:external directive, which renders a third-party custom element natively in an LWC template, leaves beta unchanged.
• A latest alias in REST URIs (generally available). /services/data/latest/sobjects/Account is routed to the newest version the org supports. It is convenient for scripts and exploration. For a production integration we would keep a pinned version, so that behaviour changes when you decide, not when the org is upgraded.
• Field-to-field comparison in SOQL (beta). A new FORMULA() function allows arithmetic in a WHERE clause, so two fields can be compared without a helper formula field. It works in sandboxes, Developer Edition and scratch orgs on API 68.0, and is not available in production.

For admins: security and access

Flows that cannot be escalated (generally available). Until now, a flow set to run in user context inherited system context whenever it was called by something running in system context — another flow, Apex, another automation. A new run option, User Context–Enforces User Permissions, guarantees the running user's access level no matter what calls the flow. It is available for screen flows and autolaunched flows on API version 68.0 or later, under Save → Show Advanced → How to Run the Flow. It is set per flow, so nothing changes until someone changes it.

Profile filtering (enforced). If a role genuinely needs to see other users' profile names, assign View All Profiles. Then check anything that reads a profile name on behalf of a standard user.

Manual shares can survive an owner change (generally available). Changing a record's owner has always deleted its manual shares. A new option in Sharing Settings, Keep manual shares when transferring records, retains them. It is off by default.

A dedicated permission for Setup Audit Trail (release update). View Setup Audit Trail lets you grant access to the audit trail without the broader View Setup permission. Existing access is preserved automatically; new profiles and permission sets need it assigned explicitly. Enforcement is in Spring '27.

For admins: everyday work

• Freer inline editing in list views. Two optional User Interface Settings: Remove list view inline edit dependencies on page layout and Make inline edits in list views with multiple record types. Both are off by default.
• Screen flows on many records at once. A flow quick action can be added to a list view or a related list as a mass action; the flow receives the IDs of the selected records.
• Flow Builder housekeeping. An edit history for tracking changes to a flow over time, and a filter that finds unused resources.
• Field history tracking for users is generally available, and record preview from Lightning reports arrives as a beta.

For QA: new tools, and what to retest

Flow Test Mode (beta). Debugging and testing a flow used to live in different places. Test Mode puts them together for autolaunched and record-triggered flows: set up inputs or a triggering record, run the scenario, save it, and run it again after every change. Add assertions and a saved scenario reports pass or fail. Enable it in Process Automation Settings.

Mock outputs for actions and subflows (beta). In those test scenarios, an Action or Subflow element can return a predefined result, so the test checks the flow's logic without calling an external system.

What this release puts on the regression list:

Dates for the project plan

Several retirements now have a release attached. None of them is urgent this month; all of them are cheaper to schedule than to discover.

Connected apps keep working after Summer '27, but without fixes or support. Migration starts from the app's page in App Manager with Migrate to External Client App. For the API versions, the work is finding who still calls them: old middleware, exports and scripts nobody has opened in years.

In short

• Developers: enjoy the heap, clear the old-API warnings, try integration tests in a scratch org.
• Admins: review profile filtering, decide on manual shares, move sensitive flows to the enforced user context.
• QA: try Flow Test Mode in a sandbox and run the five regression checks above.
• Everyone: put connected apps and old API versions on next year's plan now.
• Treat betas and previews as things to learn, not things to ship.