With the Winter ‘26 release notes and pre-release orgs now available, we’re beginning to get a sense for what the next round of Salesforce features will be. Here’s a quick roundup of some things that Salesforce Developers can look forward to.
As usual, a summary like this is just a taste of what’s in store (especially when summarizing 999 pages of release notes). Be sure to take a look for yourself at products and features directly in line with what you’re using.
1. Trusted Mode Increases LWC Browser API Access
Note: As of the week commencing September 15, the Trusted Mode feature is no longer listed in this release, with the release note change simply stating it “needs some adjustment”. So we’ll have to wait a bit longer for this feature, but you can read below to learn more about what this may mean in another upcoming release.
For time immemorial (since 2015), UI development on Salesforce has been saddled with one form or another of limitation to access browser APIs. There’s a history here. Previously, Visualforce had used the security of an iframe to create a secure partition between a page’s own functionality and the rest of the Salesforce app.
Upon the launch of Aura and later Lightning Web Components (LWC), the iframe was disposed of in order to create a more seamless web page experience. But this opened a serious security risk: in a UI where the Salesforce engineer, the ISV engineer, and the customer’s UI developer were all playing in the same DOM, what would prevent them from stepping on each other? Or worse, should one wind up having malicious code, how could this be mitigated?
Initially, with Locker service (a homegrown solution), and later with Lightning Web Security (LWS), Salesforce’s UI security wizards managed to obfuscate away the most worrisome browser APIs and make a safe sandbox for all of our components to play together nicely.
But this doesn’t mean all is happy. Many of the web’s more popular libraries use these very browser APIs, meaning third-party libraries that rely on them don’t work well with Locker or LWS.
Enter “Trusted Mode”.
Trusted mode allows you to run third-party JS libraries in your org without Locker service or LWS. This is an interesting move to a different part of the spectrum of shared responsibility for Salesforce. No doubt, each Salesforce customer will need to evaluate whether or not to use this, but if your company has adopted and vetted a third-party library for security and you want to use it as is, it should now work.
Using trusted mode will mean:
- Unrestricted browser API access, such as direct access to the
window,document, andelementobjects. - Full DOM manipulation, including Salesforce-managed elements and shadow DOM.
- Improved performance as there is no LWS layer.
- Enhanced compatibility for global libraries – where third partly libraries rely on global state, they will work as intended.
There is a proper ritual to enable this, including turning on Trusted Mode in the first instance and then explicitly naming the static resources that will be enabled to run in this mode. So it is highly unlikely that you’ll accidentally end up with JS code running in trusted mode.
So if you have a performance-heavy frontend LWC and you want to improve its performance, you now have a new alternative to work with.
2. Progress for Single Component LWC Local Development
The new local development server environment is pretty slick. Being able to experience an LWC in the browser, make a change, and see it appear instantly is a gratifying experience…if for no other reason than it is the norm for development in so many other web frameworks.
But sometimes you want to just focus on working with a single component without all the faff of the rest of the UI. The single-component command was made available as a beta in the last release, but it was limited in features.
As of Winter ‘26, it now supports the ability to access public Lightning Data Service wire adapters, @salesforce scoped modules, and Apex controllers.
3. ApexDoc Comes Home
ApexDoc has been the standard for generating Apex class and trigger documentation for some time. But it has always existed as an open-source project.
In Winter ’26, ApexDoc has now become a first-class citizen for Apex. As of writing, details are sketchy. How to actually add the ApexDoc comments is straightforward and well-documented. Presumably, this is a key feature in documenting Apex classes for use as Agent actions, in addition to developers using them for creating their own documentation. But how the human-readable documentation will be generated is not documented yet; surely more will be forthcoming as the GA release date approaches.
4. Unified Testing Results
There’s been work done to make testing more universal in Winter ‘26. Flow testing has existed for some time now for record-triggered flows. And Apex has always had tests required to deploy into production. But previously, these had to be chased down in different places. Apex tests were available in the Apex Test Execution and Apex Test History setup menu items, along with via APIs (which surfaced them to many other places like VS Code, the CLI, and Dev Console). Flow tests were accessible only in the Flow Builder (for relevant flow types).
Now you can find Flow and Apex test results in the new Application Test Execution Setup Menu item. Flow tests have also been surfaced to a new API. This renders Flow tests available to be run and results to be inspected by tooling.
This leads us to our next feature…
5. Flow Tests – Run and Results from the CLI
Now, in addition to running Apex tests from the Salesforce CLI, there are now commands to be able to run Flow tests and retrieve their results. Flow tests are not universal – they only work on record-triggered and data cloud-triggered flows for the moment. But Flow continues to grow in its importance in building automations on Salesforce. Being able to run automated testing for Flow is a definite step in the right direction to help bring better DevOps practices to building your flows.
By default, Flow tests run asynchronously and return a test run Id which can be used to retrieve a result. You can also set a wait time (although this wasn’t working in my prerelease version of the CLI), or simply run tests synchronously, if you prefer.
Intriguing is the --code-coverage flag. For the moment, this only seems to return code coverage for Apex classes. But the fact that it lives also on the sf flow run test command begs the question whether Salesforce plans to have a code coverage calculation in the future for flows. This will be one to watch out for.
6. Simplified Project Package References
Packaging is a key component of building applications. This is especially important for AppExchange partners, who are required to use them. But even customers can make use of them. Previously, if you had a multi-level dependency, you had to painstakingly name the entire dependency tree of every package. Failure to do so would prevent package installation.
Take this example from the Summer ‘25 documentation where pkgA depends on pkgB, which depends on pkgC. Note the multilevel package dependency reference for pkgC.
{
"packageDirectories": [
{
"path": "pkgA-wsp",
"default": true,
"package": "pkgA",
"versionName": "ver 1.3",
"versionNumber": "1.3.0.NEXT",
"ancestorVersion": "1.1.0.RELEASED"
},
{
"path": "pkgB-wsp",
"default": false,
"package": "pkgB",
"versionName": "ver 2.3",
"versionNumber": "2.3.0.NEXT",
"ancestorVersion": "2.0.0.RELEASED",
"dependencies": [
{
"package": "pkgA@1.1.0.RELEASED"
}
]
},
{
"path": "pkgC-wsp",
"default": false,
"package": "pkgC",
"versionName": "ver 0.1",
"versionNumber": "0.1.0.NEXT",
"dependencies": [
{
"package": "pkgA@1.1.0.RELEASED"
},
{
"package": "pkgB@2.0.0.RELEASED"
}
]
}
],
}
Now, you can simplify the multilevel package dependency reference. This includes the addition of a new parameter in the package reference JSON called calculateTransitiveDependencies. This will definitely ease the cognitive load for orgs with more complex package dependencies, which can definitely be the case for orgs that have adopted wall-to-wall package-based development models. This will also mean that the addition of new dependencies or a change in dependencies will require less picking through package references to ensure that each ancestor correctly names its package hierarchy.
Using the example above, here’s what the new dependency for pkgC would look like:
{
"path": "pkgC-wsp",
"default": false,
"package": "pkgC",
"versionName": "ver 0.1",
"versionNumber": "0.1.0.NEXT",
"calculateTransitiveDependencies": true,
"dependencies": [
{
"package": "pkgB@2.0.0.RELEASED"
}
]
}
7. Goodbye Instance URLs
Salesforce has slowly been marching us away from its once-fabled instance URLs (na1, anyone?). These domain names map to the actual Salesforce instance (shared application) that your org (also known as a tenant) runs on.
Before the rollout and then the forced change to MyDomain URLs, integrations with Salesforce regularly used these…and sometimes hard-coded them. This creates problems, especially when an org migrates to a new instance.
Winter ‘26 is where this ends.
The Update Instanced URLs in API Traffic release update promises to begin enforcing API requests that use orgs’ proper MyDomain URL domains. For details and information to ensure your org complies with these changes, make sure you take a look.
8. Roles and Subordinates Changes in Apex Managed Sharing
With all the news of compromised Salesforce orgs recently, no one wants to score a security own goal. So here’s one to get on top of. When performing Apex managed sharing, there’s an important change in the use of the Roles and Subordinates sharing group. Previously, you might have used a Sharing Group with a type called RolesAndSubordinates. This was a special sharing group that ensured access to certain records was inherited down a role hierarchy (in addition to the default behavior of record access rolling up the role hierarchy).
In Winter ‘26, there will be a change in orgs, where orgs without digital experiences enabled will see this group changed dynamically to “Roles and Internal Subordinates”, which excludes Experience Cloud users.
This is not a trivial change, but it is being rolled out as a release update. It was first made available earlier this year. If you’re not aware of it, definitely check the Enable Secure Roles Behavior and Update Sharing Group References release update. To accompany the release update, there are further details in a knowledge article about it.
Summary
This release is packed with updates designed to keep developers efficient, effective, and in control. So, be sure to test them in your sandbox and share your favorites with your team (or in the comments below)!
Read More:
- Top 10 Salesforce Winter ’26 Features for Admins
- 10 New Salesforce Flow Features in Winter ‘26
- 12 Winter ’26 Updates Salesforce Marketers Need to Know
- Sales Cloud: Top Salesforce Winter ’26 Features
- Service Cloud: Top 10 Salesforce Winter ’26 Features
