Salesforce Summer '26: 10 Changes Worth Understanding

Every Salesforce release note runs to hundreds of pages, and most of it won't touch your org. Summer '26 is different in one respect: it contains a small number of changes to default behaviour that can alter how existing code runs, and those deserve attention even from teams who normally skim.

Below are the ten changes we think matter most for mid-market teams, grouped by who needs to care. For each one we've said what it is, why it matters, and what to actually do about it. The full release notes are linked at the end — this is a filter, not a replacement.

The three security changes that can affect running code

These are the ones to read even if you read nothing else. They change defaults, which means code that worked before can behave differently after.

1. Apex now defaults to user mode

In API version 67.0, SOQL, SOSL, DML and Database operations enforce user mode by default. That means object permissions, field-level security and sharing rules are respected unless you explicitly say otherwise.

Why it matters: this is the right default and a genuine security improvement. But if you have Apex that quietly relied on system-level access — reading a field the running user can't see, updating a record they don't own — it may now return less data or throw where it previously succeeded.

What to do: this is a regression-test job, not a reading job. Run your test suite against a sandbox on the new API version and look specifically at anything touching sensitive fields or cross-owner records. Note that the change applies to classes compiled at API 67.0 and above, so existing classes don't shift until you bump them — which gives you control over the timing, if you use it deliberately.

2. Classes without a sharing keyword now default to "with sharing"

Previously, an Apex class that didn't declare with sharing or without sharing ran without sharing. That default has flipped.

Why it matters: for years the safe advice has been "always declare it explicitly." Teams that followed that advice are unaffected. Teams that didn't now have classes whose behaviour changes depending on when they were compiled, which is exactly the kind of thing that produces confusing bugs six months later.

What to do: search your codebase for classes with no sharing declaration and add one deliberately. It's mechanical work and it removes ambiguity permanently.

3. WITH SECURITY_ENFORCED no longer compiles

The WITH SECURITY_ENFORCED clause has been retired and replaced by WITH USER_MODE .

Why it matters: this isn't a deprecation warning — affected code won't compile. If you use it anywhere, that's a blocker rather than a nice-to-have.

What to do: search for it now. WITH USER_MODE is the replacement and is genuinely better: it handles polymorphic fields properly and reports field-level security violations more comprehensively.

For AI leaders: Agentforce grows up

4. Agentforce Builder and Agent Script go GA — and become the default on 13 July 2026

The new builder is generally available and becomes the default from that date, with one-click upgrades for legacy agents and configurable model selection in Agent Script.

Why it matters: the date is the point. If you have agents built in the previous tooling, the platform moves underneath you whether or not you've planned for it.

What to do: upgrade in a sandbox before the date rather than after, and re-run your agent test cases. Salesforce has also open-sourced the Agent Script toolchain — parser, linter, compiler and language server — under Apache 2.0, which matters if you want agent definitions in version control and reviewed like code. For most teams that's the right way to manage them.

5. Multi-agent orchestration arrives in beta

Orchestrator agents can now connect to specialised subagents, with Salesforce describing the pattern as a single front door backed by specialists behind it.

Why it matters: it directly addresses the biggest practical problem with agent design. One agent scoped to do everything performs poorly; several narrow agents perform well but confuse users who don't know which to talk to. Orchestration is the sensible resolution.

What to do: if you already have one working agent, this is how you add a second without degrading the first. If you have none, build one narrow agent well before reaching for orchestration — the pattern solves a problem you don't have yet.

6. Custom Scorers let you grade agent conversations against your own KPIs

In beta, you can score sessions against measures like sentiment, tone, product interest, escalation trigger and politeness, alongside the standard metrics, and deploy them through the Metadata API.

Why it matters: this is the missing piece for anyone running an agent in production. "Did it deflect the case" is easy to measure; "was it any good" has been much harder. Custom scorers make quality something you can actually track over time rather than sample by hand.

What to do: if you have a live agent, define two or three scorers that reflect what you'd tell a new hire to care about, and review them weekly. This is the practical answer to the "who monitors it in month six" question.

7. Agentforce voice extends across digital and mobile channels

Voice capability now spans digital and mobile surfaces, and the mobile SDK adds React Native support with a single TypeScript codebase across iOS and Android.

Why it matters: if you've been treating agents as a web-chat feature, the surface area just widened considerably — and so did the governance question about what an agent is allowed to say when nobody is reading a transcript.

For architects: the platform shifts

8. Salesforce-hosted MCP servers reach GA

There are now pre-built Model Context Protocol servers for SObject CRUD and SOQL, Data 360 queries and Tableau analytics, plus the ability to build custom servers from Apex actions, flows, Apex REST endpoints, prompt templates and Agentforce agents.

Why it matters: this is how external AI tooling talks to your org in a structured, governed way rather than through bespoke integrations. Strategically it's one of the more significant items in the release, even though it will show up on few admins' radar.

What to do: treat it as an access-control question first. An MCP server is a door into your data; decide deliberately what goes through it and who can use it, before someone stands one up because it was easy.

9. SOAP login() retires in Summer '27 — start now

The SOAP login() method retires next summer for API versions 31.0 through 64.0, with migration to OAuth required.

Why it matters: a year sounds like plenty until you discover the integration using it was built by someone who left, and nobody is certain what it connects to. Legacy middleware, data-loading tools and older point-to-point integrations are the usual suspects.

What to do: inventory your integrations this quarter. Finding them is the slow part; migrating to OAuth is usually straightforward once you know what you're dealing with.

10. Data 360 gets code extensions and finer query control

You can now deploy Python scripts for batch transformations, string manipulation, custom computation and chunking logic on isolated containers, and a new SET OPTIONS SOQL clause lets you specify dataspaces and control how empty strings and nulls are handled.

Why it matters: the transformation work that previously forced data out to an external tool can increasingly stay inside the platform. The SET OPTIONS addition looks small but the null-versus-empty-string distinction is a classic source of quietly wrong results.

What we'd actually do this month

If you do nothing else: search your codebase for WITH SECURITY_ENFORCED , because that one stops compiling rather than merely warning. Then audit Apex classes with no sharing declaration , and regression-test anything security-sensitive against API 67.0 in a sandbox .

If you run agents, upgrade to Agentforce Builder in a sandbox before 13 July rather than discovering the switch after the fact.

And whatever your timeline, start the SOAP integration inventory now . It's the only item here with a hard external deadline, and it's the one most likely to be forgotten until it isn't.

The full release notes are published in Salesforce Help, and the developer-focused summary on the Salesforce Developers blog is the best starting point for the technical items above.

If you'd like a view of which of these actually apply to your org rather than to orgs in general, our free Org Health Check runs Salesforce's own diagnostics against your setup — including a security and permissions review — and gives you a written summary of what to address first. No cost, no obligation.