Wat er in Summer '26 veranderde voor Salesforce DevOps-teams

Kort gezegd: Summer '26 brengt API-versie 67.0, en voor DevOps-teams wegen drie punten zwaarder dan al het andere bij elkaar. Apex-databasebewerkingen draaien voortaan standaard in user mode, klassen zonder sharing-keyword staan nu standaard op with sharing, en WITH SECURITY_ENFORCED compileert niet meer. Alle drie hangen af van de API-versie waarop een klasse is opgeslagen, waardoor de API-versie-instelling in je pipeline een gedragsbeslissing wordt en geen opruimklus.

Om welke release gaat het en wanneer kwam die?

Summer '26 is API-versie 67.0. De sandboxpreview ging open op 8 mei 2026 en de productie-uitrol liep op 15 mei, 5 juni en 12 tot 13 juni 2026, dus als je dit leest zit je er al op. De volledige lijst staat in de release notes. Hieronder alleen het deel dat deployment, metadata en API-gedrag raakt.

Wat breekt er in Summer '26 daadwerkelijk een pipeline?

Drie dingen, op volgorde van hoe snel ze toeslaan.

1. WITH SECURITY_ENFORCED is vervallen en compileert niet meer. Deze is luid en direct: elke deployment die de clausule nog bevat, laat de build falen. Vervang hem door WITH USER_MODE, zoals beschreven in de developer guide bij de release.
2. Apex-databasebewerkingen draaien standaard in user mode. Vanaf API 67.0 draaien DML en SOQL met de objectrechten, field-level security en sharing rules van de huidige gebruiker, tenzij je anders aangeeft.
3. Klassen zonder sharing-keyword staan standaard op with sharing. De oude standaard was het tegenovergestelde. Code die stilzwijgend op system-modetoegang leunde, geeft nu stilzwijgend minder data terug.

Triggers draaien in alle versies nog steeds in system mode. Handig om te weten en gevaarlijk om op te leunen.

Waarom is de sharingwijziging een deployprobleem en geen codeprobleem?

Dit is het deel dat de meeste release-overzichten missen. De nieuwe standaarden gelden voor klassen die zijn opgeslagen op API-versie 67.0 of hoger. Het gedrag van je org verandert dus niet op de dag dat de release landt, maar op de dag dat je pipeline een API-versie ophoogt.

Daarmee worden drie regels in je repository functionele wijzigingen:

• sourceApiVersion in sfdx-project.json
• het versie-element in je package.xml
• de API-versie per klasse in elke .cls-meta.xml

Daaruit volgen drie gevolgen, en geen ervan is theoretisch.

• Je tests vangen het niet af. Apex-tests draaien in een context die je meestal zelf bepaalt, dus een klasse kan elke assertie halen en toch minder rijen teruggeven aan een echte gebruiker.
• Een bulkverhoging van de API-versie is een release, geen klusje. Behandel "alles naar 67.0" als een wijziging die UAT met echte profielen nodig heeft, niet als opruimticket.
• Gedeeltelijke verhogingen geven gesplitst gedrag. Twee klassen in dezelfde aanroepketen op verschillende API-versies gedragen zich anders. Ga je ophogen, doe dan een heel domein tegelijk.

De veilige volgorde is: eerst op elke klasse expliciet sharing declareren, daarna de API-versie ophogen. Expliciet wint van standaard, in beide richtingen.

Welke retirements horen nu op de backlog?

• Platform-API-versies 31.0 tot en met 40.0. Deprecated, met volledige retirement in Summer '28, waarna die aanroepen falen. Alles moet op 41.0 of hoger.
• SOAP-API login() op versies 31.0 tot en met 64.0, vervalt in Summer '27.
• Sessie-ID's van managed packages voor authenticatie van anonieme Apex, afgedwongen vanaf Summer '27.

Geen van deze is urgent voor deze sprint. Ze zijn allemaal van het type dat je over achttien maanden om twee uur 's nachts ontdekt via een falende integratie. Doe de API-versie-inventarisatie nu het nog goedkoop is.

Wat is er echt nieuw voor CI/CD?

• Data 360-logica in de pipeline. DevOps data kits verplaatsen code extensions en data transforms van sandbox naar productie inclusief de bijbehorende code extensions, zodat een pipeline Data 360-logica kan promoveren zoals hij al Apex en LWC promoveert.
• Agentevaluatie als metadata. Custom Scorers deployen via de Metadata API met aiAgentScorerDefinitions, waarmee kwaliteitspoorten voor agents onder versiebeheer komen te staan.
• Een scratch org-vlag waar je over struikelt. Integratietests vereisen nu ApexIntegrationTests in de features-array van de scratch org-definitie. Voeg hem toe voordat je volgende pipelinerun zonder duidelijke reden faalt.
• DevOps Center wordt native. Salesforce Ben berichtte in juni 2026 dat de volgende generatie DevOps Center het managed package inruilt voor een native capability, met een DX MCP-server om de pipeline vanuit een agentische IDE aan te sturen. Volgen: ja. Nu al overstappen: nee.

Wat doe je deze week?

1. Zoek de repository af op WITH SECURITY_ENFORCED en vervang het. Dit is een build break, geen waarschuwing.
2. Maak een lijst van elke klasse zonder expliciet sharing-keyword en beslis per klasse bewust.
3. Bevries bulkverhogingen van de API-versie tot stap twee klaar is.
4. Inventariseer de integraties die nog API 31.0 tot 40.0 aanroepen.
5. Voeg ApexIntegrationTests toe aan je scratch org-definitie.

FAQ

Verandert Summer '26 het gedrag van bestaande Apex?

Niet uit zichzelf. De nieuwe user mode- en sharingstandaarden gelden voor klassen die op API-versie 67.0 of hoger zijn opgeslagen, dus bestaande klassen houden hun gedrag tot je hun API-versie ophoogt.

Wat vervangt WITH SECURITY_ENFORCED?

Gebruik WITH USER_MODE. De oude clausule is vervallen en compileert niet meer, dus elke deployment die hem nog bevat faalt.

Wanneer stoppen oude API-versies echt met werken?

Versies 31.0 tot 40.0 zijn deprecated met volledige retirement in Summer '28, en SOAP login() op versies 31.0 tot 64.0 vervalt in Summer '27. Zet integraties op 41.0 of hoger.

Raken deze wijzigingen Apex-triggers?

Nee. Triggers blijven in alle API-versies in system mode draaien.

Kan je pipeline je niet vertellen welke klassen geen expliciet sharing-keyword hebben, dan is dat het gat om te dichten vóór de volgende release. Serpent draait AI-code review op elke wijziging, op elk plan, en signaleert precies dit soort governance-drift voordat het productie bereikt.