What Changed in Summer '26 for Salesforce DevOps Teams

The short version: Summer '26 ships API version 67.0, and for DevOps teams three items matter more than everything else combined. Apex database operations now default to user mode, classes with no sharing keyword now default to with sharing, and WITH SECURITY_ENFORCED no longer compiles. All three are scoped by the API version a class is saved at, which turns your pipeline's API version setting into a behavioural decision rather than housekeeping.

Which release is this, and when did it land?

Summer '26 is API version 67.0. Sandbox preview opened on 8 May 2026, and production rollouts ran on 15 May, 5 June and 12 to 13 June 2026, so if you are reading this you are already on it. The complete list lives in the release notes. What follows is the subset that touches deployment, metadata and API behaviour.

What actually breaks a pipeline in Summer '26?

Three things, in order of how fast they bite.

1. WITH SECURITY_ENFORCED is retired and no longer compiles. This one is loud and immediate: any deployment still carrying the clause fails the build. Replace it with WITH USER_MODE, as set out in the developer guide to the release.
2. Apex database operations default to user mode. At API 67.0 and later, DML and SOQL run with the current user's object permissions, field-level security and sharing rules unless you say otherwise.
3. Classes with no sharing keyword default to with sharing. The old default was the opposite. Code that quietly relied on system-mode access now quietly returns less data.

Triggers still run in system mode across all versions. That is a useful escape hatch to remember and a dangerous one to lean on.

Why is the sharing change a deployment problem, not a code problem?

This is the part most release round-ups miss. The new defaults apply to classes saved at API version 67.0 or later. Your org's behaviour therefore does not change on the day the release lands. It changes on the day your pipeline bumps an API version.

Which promotes three lines in your repository to functional changes:

• sourceApiVersion in sfdx-project.json
• the version element in your package.xml
• the per-class API version in each .cls-meta.xml

Three consequences follow, and none of them are theoretical.

• Your tests will not catch it. Apex tests run in a context you usually control, so a class can pass every assertion and still return fewer rows to a real user.
• A bulk API version bump is a release, not a chore. Treat "upgrade everything to 67.0" as a change that needs UAT with real profiles, not a tidy-up ticket.
• Partial bumps create split behaviour. Two classes in one call chain on different API versions will behave differently. If you are going to bump, bump a whole domain at a time.

The safe order is to declare sharing explicitly on every class first, then bump the API version. Explicit beats default, in both directions.

Which retirements belong on the backlog now?

• Platform API versions 31.0 to 40.0. Deprecated, with full retirement in Summer '28, at which point those calls fail. Everything needs to be on 41.0 or later.
• SOAP API login() on versions 31.0 to 64.0, retiring in Summer '27.
• Managed package session IDs authenticating anonymous Apex, enforced from Summer '27.

None of these are urgent this sprint. All of them are the kind of thing discovered by an integration failing at 2am eighteen months from now. Run the API version inventory while it is cheap.

What is genuinely new for CI/CD?

• Data 360 logic in the pipeline. DevOps data kits move code extensions and data transforms from sandbox to production with the associated code extensions included, so a pipeline can promote Data 360 logic the way it already promotes Apex and LWC.
• Agent evaluation as metadata. Custom Scorers deploy through the Metadata API using aiAgentScorerDefinitions, which puts agent quality gates under source control where they belong.
• A scratch org flag you will trip over. Integration tests now require ApexIntegrationTests in the features array of the scratch org definition. Add it before your next pipeline run fails for no obvious reason.
• DevOps Center going native. Salesforce Ben reported in June 2026 that the next generation of DevOps Center drops the managed package for a native capability, with a DX MCP server for driving the pipeline from an agentic IDE. Worth watching. Not worth replatforming for yet.

What should you do this week?

1. Search the repository for WITH SECURITY_ENFORCED and replace it. This is a build break, not a warning.
2. List every class with no explicit sharing keyword, and decide each one deliberately.
3. Freeze bulk API version bumps until step two is finished.
4. Inventory the integrations still calling API 31.0 to 40.0.
5. Add ApexIntegrationTests to your scratch org definition.

FAQ

Does Summer '26 change the behaviour of existing Apex?

Not on its own. The new user mode and sharing defaults apply to classes saved at API version 67.0 or later, so existing classes keep their behaviour until you bump their API version.

What replaces WITH SECURITY_ENFORCED?

Use WITH USER_MODE. The old clause is retired and no longer compiles, so any deployment still carrying it will fail.

When do old API versions actually stop working?

Versions 31.0 to 40.0 are deprecated with full retirement in Summer '28, and SOAP login() on versions 31.0 to 64.0 retires in Summer '27. Move integrations to 41.0 or later.

Do these changes affect Apex triggers?

No. Triggers continue to run in system mode across all API versions.

If your pipeline cannot tell you which classes lack an explicit sharing keyword, that is the gap worth closing before the next release. Serpent runs AI code review on every change, on every plan, and flags exactly this class of governance drift before it reaches production.