Was sich in Summer '26 für Salesforce-DevOps-Teams geändert hat

Kurz gefasst: Summer '26 bringt API-Version 67.0, und für DevOps-Teams wiegen drei Punkte schwerer als alles andere zusammen. Apex-Datenbankoperationen laufen jetzt standardmäßig im User Mode, Klassen ohne Sharing-Schlüsselwort stehen standardmäßig auf with sharing, und WITH SECURITY_ENFORCED kompiliert nicht mehr. Alle drei hängen an der API-Version, unter der eine Klasse gespeichert wurde. Damit wird die API-Versionseinstellung Ihrer Pipeline zu einer Verhaltensentscheidung und nicht zu Hausputz.

Um welches Release geht es, und wann kam es?

Summer '26 ist API-Version 67.0. Die Sandbox-Vorschau öffnete am 8. Mai 2026, die Produktivausrollungen liefen am 15. Mai, 5. Juni und 12. bis 13. Juni 2026. Wenn Sie das lesen, sind Sie also längst darauf. Die vollständige Liste steht in den Release Notes. Hier folgt der Teil, der Deployment, Metadaten und API-Verhalten betrifft.

Was zerlegt in Summer '26 tatsächlich eine Pipeline?

Drei Dinge, sortiert danach, wie schnell sie zubeißen.

1. WITH SECURITY_ENFORCED ist abgeschafft und kompiliert nicht mehr. Das ist laut und sofort spürbar: Jedes Deployment, das die Klausel noch enthält, lässt den Build scheitern. Ersetzen Sie sie durch WITH USER_MODE, wie im Entwicklerleitfaden zum Release beschrieben.
2. Apex-Datenbankoperationen laufen standardmäßig im User Mode. Ab API 67.0 laufen DML und SOQL mit den Objektberechtigungen, der Feldebenensicherheit und den Freigaberegeln der aktuellen Nutzerin, sofern Sie nichts anderes angeben.
3. Klassen ohne Sharing-Schlüsselwort stehen standardmäßig auf with sharing. Der alte Standard war das Gegenteil. Code, der sich still auf Systemmodus-Zugriff verließ, liefert nun still weniger Daten.

Trigger laufen in allen Versionen weiterhin im Systemmodus. Ein nützlicher Notausgang, auf den man sich besser nicht stützt.

Warum ist die Sharing-Änderung ein Deployment-Problem und kein Code-Problem?

Das ist der Teil, den die meisten Release-Übersichten auslassen. Die neuen Standards gelten für Klassen, die unter API-Version 67.0 oder höher gespeichert sind. Das Verhalten Ihrer Org ändert sich also nicht am Tag des Releases, sondern an dem Tag, an dem Ihre Pipeline eine API-Version anhebt.

Damit werden drei Zeilen in Ihrem Repository zu funktionalen Änderungen:

• sourceApiVersion in sfdx-project.json
• das Versionselement in Ihrer package.xml
• die klassenweise API-Version in jeder .cls-meta.xml

Daraus folgen drei Konsequenzen, und keine davon ist theoretisch.

• Ihre Tests fangen es nicht ab. Apex-Tests laufen in einem Kontext, den Sie meist selbst bestimmen. Eine Klasse kann jede Zusicherung erfüllen und einer echten Nutzerin trotzdem weniger Zeilen zurückgeben.
• Eine pauschale Anhebung der API-Version ist ein Release, keine Fleißarbeit. Behandeln Sie "alles auf 67.0" als Änderung, die UAT mit echten Profilen braucht, nicht als Aufräumticket.
• Teilweise Anhebungen erzeugen geteiltes Verhalten. Zwei Klassen derselben Aufrufkette auf unterschiedlichen API-Versionen verhalten sich unterschiedlich. Wenn Sie anheben, dann eine ganze Domäne auf einmal.

Die sichere Reihenfolge lautet: erst auf jeder Klasse Sharing explizit deklarieren, dann die API-Version anheben. Explizit schlägt Standard, in beide Richtungen.

Welche Abkündigungen gehören jetzt ins Backlog?

• Plattform-API-Versionen 31.0 bis 40.0. Abgekündigt, mit vollständigem Rückzug in Summer '28, ab dem diese Aufrufe fehlschlagen. Alles muss auf 41.0 oder höher.
• SOAP-API login() auf den Versionen 31.0 bis 64.0, Rückzug in Summer '27.
• Session-IDs aus Managed Packages zur Authentifizierung von anonymem Apex, durchgesetzt ab Summer '27.

Nichts davon ist in diesem Sprint dringend. Alles davon ist die Sorte Thema, die man in achtzehn Monaten um zwei Uhr nachts an einer scheiternden Integration entdeckt. Machen Sie die API-Versionsinventur, solange sie billig ist.

Was ist wirklich neu für CI/CD?

• Data-360-Logik in der Pipeline. DevOps Data Kits verschieben Code-Erweiterungen und Datentransformationen von der Sandbox in die Produktion, samt zugehöriger Code-Erweiterungen, sodass eine Pipeline Data-360-Logik so befördert, wie sie schon Apex und LWC befördert.
• Agentenbewertung als Metadaten. Custom Scorers werden über die Metadata API mit aiAgentScorerDefinitions deployt, womit Qualitätstore für Agenten unter Versionskontrolle stehen.
• Ein Scratch-Org-Schalter, über den Sie stolpern werden. Integrationstests verlangen jetzt ApexIntegrationTests im Features-Array der Scratch-Org-Definition. Ergänzen Sie ihn, bevor Ihr nächster Pipelinelauf ohne erkennbaren Grund scheitert.
• DevOps Center wird nativ. Salesforce Ben berichtete im Juni 2026, dass die nächste Generation des DevOps Center das Managed Package zugunsten einer nativen Funktion aufgibt, mit einem DX-MCP-Server zum Steuern der Pipeline aus einer agentischen IDE. Beobachten: ja. Jetzt schon umziehen: nein.

Was sollten Sie diese Woche tun?

1. Durchsuchen Sie das Repository nach WITH SECURITY_ENFORCED und ersetzen Sie es. Das ist ein Build-Bruch, keine Warnung.
2. Listen Sie jede Klasse ohne explizites Sharing-Schlüsselwort auf und entscheiden Sie bewusst je Klasse.
3. Frieren Sie pauschale API-Versionsanhebungen ein, bis Schritt zwei erledigt ist.
4. Inventarisieren Sie die Integrationen, die noch API 31.0 bis 40.0 aufrufen.
5. Ergänzen Sie ApexIntegrationTests in Ihrer Scratch-Org-Definition.

FAQ

Ändert Summer '26 das Verhalten von bestehendem Apex?

Nicht von selbst. Die neuen Standards für User Mode und Sharing gelten für Klassen, die unter API-Version 67.0 oder höher gespeichert sind. Bestehende Klassen behalten ihr Verhalten, bis Sie ihre API-Version anheben.

Was ersetzt WITH SECURITY_ENFORCED?

Nutzen Sie WITH USER_MODE. Die alte Klausel ist abgeschafft und kompiliert nicht mehr, jedes Deployment mit ihr schlägt fehl.

Wann hören alte API-Versionen wirklich auf zu funktionieren?

Die Versionen 31.0 bis 40.0 sind abgekündigt, vollständiger Rückzug in Summer '28, und SOAP login() auf den Versionen 31.0 bis 64.0 verschwindet in Summer '27. Bringen Sie Integrationen auf 41.0 oder höher.

Betreffen diese Änderungen Apex-Trigger?

Nein. Trigger laufen in allen API-Versionen weiterhin im Systemmodus.

Wenn Ihre Pipeline Ihnen nicht sagen kann, welchen Klassen ein explizites Sharing-Schlüsselwort fehlt, ist das die Lücke, die Sie vor dem nächsten Release schließen sollten. Serpent führt KI-Code-Review bei jeder Änderung und in jedem Tarif aus und meldet genau diese Art von Governance-Drift, bevor sie die Produktion erreicht.