Nicht jede kritische Integration ist sichtbar. Manche laufen seit Jahren nachts im Hintergrund, verwenden einen eigenen Salesforce-Benutzer und melden sich mit Benutzername, Passwort und Security Token an. Solange die Daten übertragen werden, fragt selten jemand nach, welche Authentifizierung dahintersteht.
Genau diese Verbindungen müssen jetzt überprüft werden. Salesforce stellt den SOAP-API-Aufruf login() in den API-Versionen 31.0 bis 64.0 mit Summer ’27 ein. Der Aufruf ist in API-Version 65.0 und höher bereits nicht mehr verfügbar. Salesforce empfiehlt, externe Anwendungen auf External Client Apps und OAuth umzustellen.
Wichtig ist die Abgrenzung: Es geht nicht darum, dass SOAP als Schnittstelle grundsätzlich verschwindet. Es geht um eine konkrete Authentifizierungsmethode. Anwendungen, die sich über SOAP API login() anmelden, können nach der Umstellung nicht mehr authentifizieren. Alle nachgelagerten API-Aufrufe hängen damit ebenfalls an dieser Änderung.
Nicht jede alte Integration ist ein Problem. Problematisch wird sie dann, wenn niemand mehr weiß, wie sie sich anmeldet, wem sie gehört und welcher Prozess daran hängt.
Was Salesforce konkret ändert
Salesforce beschreibt die Änderung als Retirement von SOAP API login() für die API-Versionen 31.0 bis 64.0 mit Summer ’27. Bis dahin wird der Aufruf in diesen Versionen weiterhin unterstützt. Ab Summer ’27 ist er nicht mehr verfügbar.
Im Developer Guide zur Summer-’26-Version nennt Salesforce diese Änderung einen besonders relevanten Punkt für Integration Owner. Dort wird darauf hingewiesen, dass Integrationen mit Username-Password-Authentifizierung über SOAP ausfallen, wenn sie nicht rechtzeitig migriert werden. Als Ziel nennt Salesforce OAuth über External Client Apps, unter anderem mit JWT-basierten Tokens.
Parallel verschiebt Salesforce die Plattform weiter in Richtung moderner Authentifizierung. In Summer ’26 wird auch eine neue Berechtigung beschrieben, mit der gesteuert werden kann, wer sich über SOAP login() authentifizieren darf. In neu erstellten Orgs wird diese Kontrolle standardmäßig strenger durchgesetzt.
Für bestehende Organisationen bedeutet das: Die Frage ist nicht erst 2027 relevant. Sie betrifft bereits jetzt die Bestandsaufnahme, die Priorisierung und die technische Planung.
Warum das mehr ist als ein Versionsupdate
Auf den ersten Blick könnte die Änderung wie ein normales API-Versionsthema wirken. Eine alte Version läuft aus, also wird die Integration auf eine neue Version gehoben. Bei SOAP login() greift diese Logik aber zu kurz.
Der betroffene Aufruf ist nicht irgendeine fachliche Operation. Er steht am Anfang der Verbindung. Wenn die Authentifizierung scheitert, kommt die Integration gar nicht erst zu den eigentlichen Daten- oder Prozessaufrufen.
Eine nächtliche Synchronisation kann technisch sauber gebaut sein, gut dokumentierte Feldzuordnungen haben und trotzdem ausfallen, wenn sie noch über login() authentifiziert. Dasselbe gilt für ein externes Reporting-Tool, einen alten Middleware-Job oder eine kleine Eigenentwicklung, die seit Jahren zuverlässig Daten abholt.
Deshalb sollte die Migration nicht als reine Codeänderung betrachtet werden. Sie ist eine Inventurfrage: Welche Verbindungen existieren überhaupt, wem gehören sie, wie kritisch sind sie und wie melden sie sich heute an?
Bei
SOAP login()fällt nicht ein einzelner Datenaufruf weg. Es betrifft den Einstiegspunkt der Verbindung. Wenn die Authentifizierung scheitert, erreicht die Integration den eigentlichen Prozess gar nicht mehr.
Was betroffen sein kann
Nicht jede Salesforce-Integration ist automatisch betroffen. Entscheidend ist, ob eine Anwendung SOAP API login() in den betroffenen API-Versionen für die Authentifizierung verwendet.
| Bereich | Mögliche Beispiele | Typisches Risiko |
|---|---|---|
| Eigenentwicklungen | Skripte, Batch-Jobs, interne Tools, alte Java- oder .NET-Anwendungen | Der ursprüngliche Entwickler ist nicht mehr verfügbar, Zugangsdaten sind historisch gewachsen |
| Externe Tools | Reporting, ETL, Datenexporte, Connectoren | Die Authentifizierung wird in der Oberfläche verborgen oder nur als „Salesforce Login" angezeigt |
| Middleware und Integrationsplattformen | ältere Flows, Legacy-Connectoren, individuell konfigurierte Adapter | Die Verbindung läuft stabil, wurde aber seit Jahren nicht neu bewertet |
| Packages und Partnerlösungen | installierte Anwendungen mit eigener Salesforce-Anbindung | Abhängigkeit vom Anbieter und dessen Migrationspfad |
| Ad-hoc-Automatisierungen | kleine Hilfsjobs für Datenabgleich, Monitoring oder Support | Kein klarer Owner, keine Betriebsdokumentation |
Besonders kritisch sind Integrationen, die selten verändert werden. Gerade weil sie zuverlässig laufen, tauchen sie in Modernisierungsprojekten oft nicht auf.
Die Bestandsaufnahme ist der erste Projektschritt
Salesforce verweist darauf, dass betroffene Anwendungen über API-Nutzungsdaten identifiziert werden können. Im Help-Artikel wird der API Total Usage EventLogFile genannt, um Anwendungen zu finden, die sich über SOAP API login() authentifizieren.
Eine sinnvolle Bestandsaufnahme sollte technische und fachliche Informationen verbinden:
- Welche Benutzer und Anwendungen authentifizieren sich noch über
SOAP login()? - Welche API-Versionen und Endpunkte werden verwendet?
- Welche Geschäftsprozesse hängen an der Verbindung?
- Wer ist fachlicher und technischer Owner?
- Gibt es Anbieter, Packages oder Quellcode, die angepasst werden müssen?
Diese Liste ist wichtiger als die reine Anzahl der Verbindungen. Eine einzelne Integration kann einen kritischen Prozess tragen, während zehn andere nur historische Exporte bedienen.
Der zweite Blick gilt den Zugangsdaten. Username-Password-Logins sind oft mit technischen Benutzern, geteilten Zugangsdaten oder lange nicht rotierten Secrets verbunden. Die Migration ist damit auch eine Gelegenheit, Verantwortlichkeiten, Berechtigungen und Secret Handling sauberer aufzusetzen.
OAuth ist nicht nur ein anderer Login
Die empfohlene Richtung ist klar: External Client Apps und OAuth. Damit wird die Integration nicht mehr über einen direkten SOAP-Login mit Benutzername und Passwort aufgebaut, sondern über einen kontrollierten OAuth-Flow.
Für Server-to-Server-Integrationen wird häufig ein Flow benötigt, der ohne interaktive Benutzeranmeldung funktioniert. Salesforce nennt im Developer Guide unter anderem OAuth mit External Client Apps und JWT Tokens als Migrationspfad. Zusätzlich akzeptiert die SOAP API in Summer ’26 JWT-basierte Access Tokens aus Salesforce OAuth-Flows im sessionId-Header. Dadurch können SOAP-basierte Aufrufe weiter verwendet werden, ohne SOAP login() als Authentifizierungsschritt einzusetzen.
Wichtig ist dabei die Auswahl des richtigen OAuth-Flows. Wer nur von SOAP login() auf einen anderen Username-Password-Mechanismus ausweicht, löst das Problem nicht sauber. Salesforce hat auch für den OAuth 2.0 Username-Password Flow bei Connected Apps ein Retirement für Winter ’27 angekündigt.
Die technische Zielarchitektur sollte deshalb nicht lauten: alter Passwort-Login an anderer Stelle. Sie sollte lauten: klar definierte Client-App, begrenzte Berechtigungen, nachvollziehbare Tokens und ein sauberer Lebenszyklus für Credentials.
Die Migration sollte nicht alte Passwortmuster an eine neue Stelle verschieben. Entscheidend ist ein Authentifizierungsstandard mit klaren Berechtigungen, Token-Lebenszyklus und Verantwortlichkeit.
Nicht jede Integration muss neu gebaut werden
Eine Migration bedeutet nicht automatisch, dass fachliche Integrationslogik ersetzt werden muss. In vielen Fällen bleibt der eigentliche Datenfluss gleich: dieselben Objekte, dieselben Felder, dieselbe Zielanwendung. Geändert wird zunächst die Art, wie sich die Anwendung gegenüber Salesforce authentifiziert.
Trotzdem sollte die Gelegenheit nicht zu klein gedacht werden. Bei alten Verbindungen lohnt sich mindestens ein kurzer Architekturcheck. Nutzt die Integration zu breite Berechtigungen? Verwendet sie einen allgemeinen Admin-Benutzer? Ist klar dokumentiert, welche Daten gelesen oder geschrieben werden? Gibt es Fehlerbehandlung, Monitoring und einen Owner?
Aus einem reinen Authentifizierungswechsel kann sonst schnell eine oberflächliche Reparatur werden. Die Verbindung funktioniert danach wieder, aber die strukturellen Schwächen bleiben bestehen.
Gerade im Salesforce-Umfeld sind solche Integrationen oft über Jahre gewachsen. Ein Export wurde ergänzt, ein Feld kam dazu, ein Tool wurde gewechselt, ein Benutzer blieb bestehen. Die SOAP-login-Umstellung ist ein guter Anlass, diese gewachsene Integrationsrealität sichtbar zu machen.
Testläufe vor dem Stichtag
Salesforce beschreibt für das Release Update auch einen Test Run, bei dem SOAP API login() in der Org deaktiviert wird. Damit lässt sich prüfen, welche Verbindungen ausfallen würden, bevor die Änderung endgültig greift.
Ein solcher Test ist nur dann hilfreich, wenn vorher klar ist, welche Systeme beobachtet werden müssen. Sonst fällt zwar etwas aus, aber die Zuordnung bleibt unklar.
Sinnvoll ist ein schrittweises Vorgehen:
-
Inventarisieren Alle bekannten Salesforce-Verbindungen erfassen, API-Nutzung prüfen und technische Benutzer zuordnen.
-
Priorisieren Kritische Geschäftsprozesse, externe Anbieter und schwer wartbare Eigenentwicklungen zuerst behandeln.
-
Migrieren und testen Authentifizierung auf OAuth und External Client Apps umstellen, Berechtigungen begrenzen und Fehlerfälle in Sandbox oder kontrollierten Testfenstern prüfen.
-
Überwachen Nach der Umstellung API-Nutzung, Login Events, Fehlermeldungen und Job-Ergebnisse gezielt beobachten.
Der Testlauf sollte nicht als einmaliger Haken im Release-Update-Menü verstanden werden. Er ist Teil eines Migrationsprojekts, das technische Abhängigkeiten und fachliche Kritikalität zusammenbringen muss.
Was Unternehmen jetzt klären sollten
Bis Summer ’27 bleibt noch Zeit. Für produktive Salesforce-Landschaften ist das trotzdem kein Grund, die Prüfung aufzuschieben. Der Aufwand liegt häufig nicht im Code, sondern im Auffinden und Bewerten alter Verbindungen.
Vor der Migration sollten drei Entscheidungen geklärt sein:
-
Welche Integrationen sind tatsächlich betroffen? Nicht jede SOAP-Nutzung ist automatisch ein Problem. Relevant ist die Authentifizierung über
SOAP API login()in den betroffenen API-Versionen. -
Welche Anwendung ist für welchen Prozess kritisch? Eine technische Verbindung muss mit ihrem Geschäftsprozess verbunden werden. Nur so lässt sich entscheiden, welche Migration zuerst kommt.
-
Wie soll Authentifizierung künftig standardisiert werden? External Client Apps, OAuth-Flows, technische Benutzer, Berechtigungen und Secret Handling sollten nicht pro Integration improvisiert werden.
Diese Entscheidungen verhindern, dass jedes Team einzeln migriert und am Ende unterschiedliche Sicherheits- und Betriebsmodelle entstehen.
Alte Logins sind oft ein Symptom
Die Einstellung von SOAP API login() ist nicht nur ein Salesforce-Release-Thema. Sie macht sichtbar, wie stark Unternehmen noch von historisch gewachsenen Authentifizierungsmustern abhängen.
Eine Integration kann fachlich wichtig und technisch alt sein. Sie kann stabil laufen und trotzdem ein Risiko darstellen. Sie kann seit Jahren Daten bewegen, ohne dass klar ist, wem sie gehört oder wie sie im Fehlerfall wiederhergestellt wird.
Genau deshalb sollte die Migration nicht erst kurz vor Summer ’27 beginnen. Wer früh prüft, findet nicht nur betroffene SOAP-Logins. Er bekommt auch einen besseren Blick auf die eigene Integrationslandschaft.
Das Ziel ist nicht, SOAP pauschal zu ersetzen. Das Ziel ist, alte Authentifizierungsmuster kontrolliert aus dem Betrieb zu nehmen und Salesforce-Integrationen so aufzusetzen, dass sie auch in den nächsten Release-Zyklen nachvollziehbar, wartbar und sicher bleiben.