← Alle Beiträge

Summer ’26 Plattform

Summer ’26 für Entwickler: MCP-Server, State Managers, Web Console

Das Release stellt die Plattform so um, dass KI-Agenten sie bedienen können. Daneben stehen zwei Änderungen, die den Alltag unabhängig davon verbessern, und eine, die überfällig war.

Die Plattform bekommt eine Werkzeugschicht

Der größte Block in Summer ’26 dreht sich um das Model Context Protocol. Salesforce liefert Hosted MCP Servers allgemein verfügbar aus: fertige Server für CRUD und SOQL auf sObjects, für Abfragen gegen Data 360 und für Tableau-Analytik. Interessanter ist der zweite Teil. Eigene MCP-Server lassen sich aus Bausteinen erzeugen, die ohnehin in der Org liegen: Apex Actions, Flows, Apex REST, @AuraEnabled-Methoden, Named Query API, Prompt Builder, Agentforce-Agenten und dem API Catalog.

Praktisch heißt das: Was du bereits als Automatisierung gebaut hast, wird ohne Umweg zum Werkzeug für einen Agenten. Der Aufwand verschiebt sich vom Anbinden zum Zuschneiden: welche Aktion darf ein Agent aufrufen, mit welchen Rechten, mit welcher Fehlerbehandlung. Das ist eine Architekturfrage, keine Integrationsfrage.

Für die Entwicklungsumgebung kommt der Salesforce DX MCP Server als Beta dazu, mit Werkzeugen für SLDS-Styling-Hinweise und ApexGuru, das Apex-Code anhand von Laufzeitmetriken beurteilt. Weitere Server für Metadata API, Data 360, Omnistudio und Marketing Cloud Engagement stehen in verschiedenen Reifegraden bereit.

LWC: Zustand verlässt den Component-Baum

State Managers sind allgemein verfügbar. Die Idee in einem Satz: Daten und die Logik, die sie verändert, wandern aus den Komponenten heraus. Über das Primitiv defineState baust du einen Zustandscontainer aus drei Bausteinen: atom(value) für einen Wert, computed([deps], fn) für einen abgeleiteten Wert und setAtom(atom, value) zum Setzen.

Wer schon einmal einen Wert durch fünf Komponentenebenen gereicht oder ihn über einen Pub/Sub-Kanal geschmuggelt hat, weiß, warum das gebraucht wurde. Für den Zugriff auf Lightning Data Service bringt Salesforce fertige State Manager mit.

Daneben, kleiner, aber im Alltag spürbar:

Die Developer Console hat einen Nachfolger

Die Web Console (Beta) ist eine browserbasierte Entwicklungsumgebung für Apex, LWC und Metadaten, direkt in jeder Org. Sie lädt schneller als die Agentforce-Vibes-IDE und ist als Ablösung der alten Developer Console gedacht.

Das ersetzt keine lokale Umgebung mit Versionskontrolle, und sollte es auch nicht. Aber für den Fall „kurz in die Produktion schauen, warum ein Job hängt“ ist es der Unterschied zwischen einem Werkzeug aus 2013 und einem aktuellen.

Apex-Komfort, endlich

Neben der Umstellung auf User Mode, die einen eigenen Beitrag wert ist, bringt API 67.0 Kleinigkeiten, die erstaunlich viel Ärger sparen:

Zwei Punkte für den Kalender

SOAP login() wird in Summer ’27 zurückgezogen. Authentifizierung über Benutzername und Passwort per SOAP endet damit; der Weg führt über OAuth mit JWT-Token. Die SOAP API akzeptiert dafür ab sofort JWT-basierte Token im sessionId-Header. Wer noch Skripte mit SOAP-Login betreibt, hat ein Jahr Zeit, sollte es aber nicht ausreizen, denn der Username-Password-Flow bei OAuth fällt schon in Winter ’27.

Der zweite Termin liegt näher: Ab dem 13. Juli 2026 wird der neue Agentforce Builder zum Standard. Bestehende Agenten lassen sich per Klick auf Agent Script umstellen, dessen Parser, Linter, Compiler und LSP-Integration Salesforce unter Apache 2.0 offenlegt.

Einordnung

Der Schwerpunkt des Releases liegt eindeutig bei Agenten, und wer damit nichts vorhat, könnte den Eindruck bekommen, es sei wenig für ihn dabei. Das täuscht. Die drei Änderungen mit dem größten Effekt auf bestehenden Code (User Mode als Standard, blockierte data:-URIs und der angekündigte Wegfall der Passwort-Flows) haben mit KI nichts zu tun. Sie stehen nur weniger prominent in der Ankündigung.

Quellen