Startseite
» Technologie
»
Salesforce Workbench-Fehler: Fehlerbehebung bei API-Tools während Ausfallzeiten
Salesforce Workbench-Fehler: Fehlerbehebung bei API-Tools während Ausfallzeiten
Verifiziert am 16. September 2026. Workbench-Fehler werden bei Salesforce-Störungen leicht falsch interpretiert. Ein fehlgeschlagener Login kann durch eine abgelaufene Sitzung, eine falsche Umgebung, eine fehlerhafte Workbench-Route oder einen Ausfall der Salesforce-API verursacht werden. Eine Anfrage, die einen 503 Service UnavailableFehler zurückgibt, deutet in eine andere Richtung als eine andere 401 Invalid Session, obwohl beide auftreten können, wenn ein Entwickler unter Zeitdruck arbeitet.
Ziel der Fehlerbehebung ist nicht, eine Anfrage zu erzwingen. Vielmehr geht es darum, die fehlerhafte Ebene zu identifizieren, Daten während der Systeminstabilität zu schützen und zu erkennen, wann die Beweislage ausreicht, um abzuwarten, das Tool zu wechseln oder den richtigen Supportkanal zu kontaktieren.
Kurzdiagnose: Was bedeutet der Fehler höchstwahrscheinlich?
Was Sie sehen
Wahrscheinlichste Schicht
Der beste nächste Schritt
Die Workbench-Seite wird nicht geladen.
Workbench-Site, Browser, DNS oder Netzwerkpfad
Öffnen Sie den Salesforce-Vertrauensstatus und testen Sie die Website von einem zulässigen alternativen Netzwerk aus.
Workbench wird geladen, aber die Anmeldung schlägt mit dem Fehlercode 401 fehl.
Sitzung, OAuth, Benutzername, Passwort oder Anmeldevorgang
Starten Sie eine neue, autorisierte Anmeldung und bestätigen Sie die ausgewählte Umgebung.
Die API-Anfrage liefert den Statuscode 403 zurück.
Berechtigungen, Richtlinien für verbundene Apps oder API-Beschränkungen
Überprüfen Sie die Benutzer-, die verbundene App- und die Anforderungslimits; betrachten Sie dies nicht als Beweis für Ausfallzeiten.
Mehrere API-Aufrufe liefern die Fehlercodes 500, 502 oder 503 zurück.
Salesforce-Plattform, Edge-Routing, Wartung oder Überlastung
Vergleichen Sie die Fehlerzeit mit Ihrem Instanz- und Produktstatus auf Trust.
Nur eine Abfrage oder ein Objekt schlägt fehl.
Anfragesyntax, Objektzugriff, Datensatzfreigabe oder Datenproblem
Reduzieren Sie die Anfrage auf eine harmlose, als korrekt bekannte Leseoperation und überprüfen Sie den Antworttext.
Diese Tabelle dient als Ausgangspunkt, nicht zur Diagnose. Derselbe HTTP-Code kann je nach Endpunkt, Authentifizierungsmethode und Organisationsrichtlinie unterschiedliche Ursachen haben.
Zunächst sollten Sie die Supportgrenzen von Workbench verstehen.
Workbench ist eine browserbasierte Suite zur Interaktion mit Salesforce-Organisationen über verschiedene APIs, darunter REST, SOAP, Bulk, Streaming, Metadaten und Apex-bezogene Tools. Auf der Workbench-Website wird jedoch darauf hingewiesen, dass es sich nicht um ein offizielles Salesforce-Produkt handelt und dass kein Salesforce-Support für Workbench selbst verfügbar ist. Die Seite „Über uns“ warnt zudem davor, die Anwendung mit Produktionsdaten zu verwenden.
Diese Warnung ändert Ihr Vorgehen bei Ausfallzeiten. Der Salesforce-Support kann Probleme mit Salesforce-Diensten, -Instanzen oder -APIs untersuchen, aber möglicherweise nicht jedes Verhalten der Workbench-Oberfläche beheben. Umgekehrt kann ein Problem, das nur von Workbench gemeldet wird, eher auf Workbench selbst oder den Browserpfad als auf die Salesforce-Plattform zurückzuführen sein.
Die Fehlerbehebung sollte nach Möglichkeit schreibgeschützt sein. Passwörter, OAuth-Geheimnisse, Sitzungs-IDs, Zugriffstoken, Kundendatensätze oder ungeschwärzte Anfrageheader dürfen nicht in Screenshots, Chatnachrichten oder öffentliche Problemberichte eingefügt werden.
Ermitteln Sie zunächst den Anmeldepfad für Workbench und die ausgewählte Umgebung. Die dargestellte Benutzeroberfläche ist lediglich ein Beispiel und kein Live-Anmeldebildschirm oder eine Aufforderung zur Eingabe von Anmeldeinformationen in ein Artikelbild.
Schritt 1: Überprüfen Sie den Salesforce-Vertrauensstatus, bevor Sie die Workbench-Einstellungen ändern.
Öffnen Sie den Salesforce-Vertrauensstatus in einem separaten Tab. Die Hilfedokumentation von Salesforce verweist Kunden bei Produktausfällen und Servicebeeinträchtigungen auf diese Seite. Die Vertrauensseite kann Informationen zu Produkten sowie zu spezifischen Instanzen anzeigen.
Prüfen Sie zwei Ansichten:
Die allgemeine Produktübersicht: Achten Sie auf Vorfälle, Beeinträchtigungen, Störungen oder Wartungsereignisse, die den von Ihnen genutzten Salesforce-Dienst betreffen.
Ihre Instanzansicht: Suchen Sie nach Ihrer Instanz oder nach „Meine Domäne“ und öffnen Sie das entsprechende Ergebnis.
Eine als „Verfügbar“ gekennzeichnete Instanz garantiert nicht, dass alle API-Operationen funktionieren. Sie bedeutet, dass die Instanz und ihre Dienste gemäß der Statusdefinition von Salesforce verfügbar sind. „Leistungsbeeinträchtigung“ deutet darauf hin, dass der Zugriff möglicherweise mit Verzögerungen oder eingeschränkter Funktionalität erfolgt; „Dienstunterbrechung“ bedeutet, dass die Instanz nicht verfügbar ist; „Wartung“ kennzeichnet ein Wartungsereignis, das den Zugriff beeinträchtigen kann.
Schritt 1 – Vergleichen Sie die allgemeinen Informationen zum Vertrauensstatus mit der Instanz der betroffenen Organisation. Die angezeigte Ansicht dient lediglich der Veranschaulichung des dokumentierten Suchvorgangs und stellt keinen Nachweis eines aktuellen Vorfalls dar.
Schritt 2: Umgebung und Organisation vor erneutem Versuch überprüfen
Workbench kann Verbindungen zu verschiedenen Salesforce-Umgebungen herstellen. Bevor Sie davon ausgehen, dass eine API ausgefallen ist, prüfen Sie, ob die fehlgeschlagene Anfrage die Produktionsumgebung, eine Sandbox oder eine andere autorisierte Umgebung betrifft. Ein Test, der in einer Umgebung erfolgreich ist, behebt das Problem nicht in der tatsächlich fehlerhaften Umgebung.
Verwenden Sie die Domäne oder die Instanzkennung der betroffenen Organisation. Salesforce dokumentiert, dass das Präfix „Domäne“ im Vertrauensstatus verwendet werden kann, während Administratoren die Instanz unter „ Firmeninformationen“ in den Einstellungen finden . Notieren Sie sich die Instanz, die Umgebung, die API-Version, den ungefähren Zeitpunkt des Fehlers und den Endpunkt. Diese kurze Dokumentation verhindert einen häufigen Fehler: den Vergleich eines Produktionsfehlers mit einem fehlerfreien Sandbox-Status.
Wenn die Workbench-Anmeldeseite selbst eine nicht unterstützte Anmeldemethode anzeigt oder zur Anmeldeseite zurückleitet, behandeln Sie dies als separates Authentifizierungs- oder Workbench-Problem, bis der Vertrauensstatus und eine direkte Salesforce-Anmeldung etwas anderes anzeigen. Geben Sie während eines vermuteten Ausfalls nicht wiederholt Anmeldeinformationen ein; übermäßige Wiederholungsversuche können zu Kontosperrungen führen oder die Untersuchung erschweren.
Schritt 3: Klassifizieren Sie die API-Antwort, anstatt zu raten.
Die Dokumentation der Salesforce REST-API erklärt, dass der Antwortheader einen HTTP-Statuscode enthält und der Antworttext üblicherweise eine Fehlermeldung sowie gegebenenfalls das Feld oder Objekt, das mit dem Fehler verknüpft ist. Bewahren Sie beide Informationen auf.
Code
Salesforces dokumentierter Hinweis
Wie man es während Ausfallzeiten interpretiert
400
Die Anfrage konnte nicht verstanden werden, häufig weil der JSON- oder XML-Body ungültig war.
Normalerweise wird die Anfrage behoben, bevor sie als Ausfall behandelt wird.
401
Die Sitzungs-ID oder das OAuth-Token ist abgelaufen oder ungültig.
Bitte authentifizieren Sie sich erneut über einen genehmigten Ablauf; ein 401-Fehler allein ist kein Beweis für einen Plattformausfall.
403
Die Anfrage wurde abgelehnt, häufig aufgrund fehlender Berechtigungen oder einer API-Beschränkung.
Prüfen Sie Zugriffsrechte und Beschränkungen, bevor Sie einen Verfügbarkeitsvorfall melden.
500
Auf der Lightning-Plattform ist ein Fehler aufgetreten.
Wiederholen Sie den Vorgang erst nach der Aufzeichnung der Antwort; vergleichen Sie wiederholte Fehlschläge mit dem Vertrauensstatus.
502
Salesforce Edge konnte nicht erfolgreich mit der Instanz kommunizieren.
Ein Routing- oder plattformseitiges Problem ist möglich, insbesondere bei mehreren Anfragen.
503
Der Server ist nicht verfügbar; möglicherweise finden Wartungsarbeiten statt oder es liegt eine Überlastung vor.
Prüfen Sie, ob ein Vorfall oder eine Wartungsmaßnahme vorliegt, und vermeiden Sie destruktive Wiederholungsversuche.
Schritt 3 – Notieren Sie den HTTP-Code und die Bedeutung der Antwort, bevor Sie Anmeldeinformationen oder Anfragen ändern. Das Beispiel enthält weder Token noch Kundendaten oder eine echte Vorfalls-ID.
Schritt 4: Führen Sie einen sicheren Vergleichstest durch
Sobald Sie den Status und die Umgebung kennen, verwenden Sie den kleinstmöglichen zulässigen Lesetest. Ein guter Vergleich muss drei Eigenschaften aufweisen: Er zielt auf die betroffene Organisation ab, verändert keine Daten und ist so einfach, dass ein Fehler im Anfrageformat unwahrscheinlich ist.
Wiederholen Sie die gleiche harmlose Bitte einmal, nachdem Sie die erste Antwort aufgezeichnet haben.
Wenn die Anfrage den Statuscode 401 zurückgibt, sollte ein neuer autorisierter Authentifizierungsablauf gestartet werden, anstatt eine alte Sitzung wiederzuverwenden.
Falls die Antwort 400, 403 oder 404 lautet, überprüfen Sie den Endpunkt, die API-Version, den Objektnamen, die Berechtigungen und den Anfragetext.
Wenn wiederholt die Fehlercodes 500, 502 oder 503 zurückgegeben werden, vergleichen Sie die Uhrzeit und die Instanz mit dem Vertrauensstatus.
Wenn die Browser-Benutzeroberfläche funktioniert, Workbench aber fehlschlägt, testen Sie denselben autorisierten API-Pfad mit einem genehmigten internen Client oder einer Integrationsdiagnose.
Verwenden Sie keine Schreib-, Lösch-, Massenaktualisierungs-, Metadatenbereitstellungs- oder Migrationsanforderungen als Integritätsprüfung. Während eines Vorfalls kann ein Schreibvorgang zu Teilergebnissen, doppelter Arbeit oder dem falschen Eindruck einer erfolgreichen Wiederherstellung führen.
Wann sollten Sie Ihre Vorgehensweise bei der Fehlersuche ändern?
Vorgehensweise ändern, wenn der Vertrauensstatus einen Vorfall anzeigt
Ändern Sie die Abfrage erst dann, wenn Sie unabhängige Beweise dafür haben, dass die Anfrage fehlerhaft ist. Speichern Sie die Vorfallnummer, den betroffenen Dienst, die Instanz, die Startzeit und das letzte Update. Befolgen Sie die Wiederherstellungshinweise von Salesforce und schützen Sie die in der Warteschlange befindlichen Aufgaben vor doppelten Wiederholungsversuchen.
Vorgehensweise ändern, wenn der Vertrauensstatus verfügbar ist, Workbench allein jedoch fehlschlägt.
Konzentrieren Sie sich auf Workbench, Browser, Netzwerk, Authentifizierung oder lokale Richtlinien. Versuchen Sie es mit einem privaten Browserfenster, einem unterstützten alternativen Browser und einem Vergleich der zulässigen Netzwerkeinstellungen. Die Workbench-Website verweist bei Workbench-spezifischem Support auf die Ressourcen der Open-Source-Community, während die Salesforce-Hilfe weiterhin die Anlaufstelle für Support zu Salesforce-Produkten und -Konten ist.
Ändern Sie Ihre Vorgehensweise, wenn der Fehler wiederholt 401 oder 403 lautet.
Fahren Sie mit der Identitäts- und Autorisierungsanalyse fort. Überprüfen Sie den Benutzer, die Richtlinie der verbundenen App, den OAuth-Bereich, die Sitzungsdauer, den API-Zugriff, das Profil bzw. die Berechtigungsgruppe sowie die Organisationsbeschränkungen. Wiederholtes Aktualisieren des Browsers behebt weder fehlende Berechtigungen noch ungültige Token.
Vorgehensweise ändern, wenn ein Endpunkt ausfällt, einfache Lesevorgänge aber funktionieren.
Untersuchen Sie Endpunkt, Objekt, Feld, Datensatzfreigabe, API-Version, Anfragetext und Antworttext. Ein einzelner Fehler reicht nicht aus, um Salesforce generell als fehlerhaft einzustufen. Reduzieren Sie die Anfrage, bis Sie feststellen können, ob das Problem Syntaxfehler, Zugriffsprobleme, Datenfehler oder ein abhängiger Dienst ist.
Schritt 4 – Beachten Sie die Support- und Sicherheitsgrenzen von Workbench. Nutzen Sie den autorisierten Salesforce-Support bei Plattformvorfällen und Open-Source-Community-Ressourcen für Workbench-spezifisches Verhalten.
Welche Nachweise sollten Sie an den Support senden?
Sollte das Salesforce-Problem weiterhin bestehen, verwenden Sie die offizielle Salesforce-Supportanleitung für den in Ihrem Success Plan enthaltenen Kanal. Folgende Punkte sind dabei zu beachten:
Organisationskennung, Instanz und Umgebung
UTC-Zeitstempel und Ihre lokale Zeitzone
Workbench-Seite oder API-Operation beteiligt
HTTP-Code, Fehlercode und geschwärzter Antworttext
Ob die Salesforce-Benutzeroberfläche, ein anderer Benutzer oder ein anderer genehmigter Client ebenfalls fehlschlägt
Trust Status-Vorgangsnummer oder ein Hinweis darauf, dass kein passendes Ereignis gefunden wurde
Entfernen Sie Anmeldeinformationen, Sitzungs-IDs, Zugriffstoken, Kundennamen, Datensatz-IDs und sensible Nutzdaten, bevor Sie Protokolle senden. Wenn das Problem nur Workbench betrifft, nutzen Sie den Support-Weg, der auf der Workbench-Hilfeseite beschrieben ist . Salesforce bietet keinen Produktsupport für Workbench selbst an.
Wie man die Wiederherstellung überprüft
Eine grüne Statusanzeige ist ermutigend, aber noch nicht das Ziel. Überprüfen Sie die Wiederherstellung schrittweise:
Prüfen Sie, ob auf der Vorfallseite eine Lösung angezeigt wird oder ob der Status der Instanz wieder auf „Verfügbar“ wechselt.
Melden Sie sich über den genehmigten Salesforce- oder Workbench-Workflow an, ohne eine veraltete Sitzung wiederzuverwenden.
Führen Sie dieselbe harmlose Leseanfrage aus, die zuvor fehlgeschlagen ist.
Vergleichen Sie den HTTP-Code, die Antwortzeit und den Antworttext mit dem aufgezeichneten Fehler.
Prüfen Sie Integrationen, in der Warteschlange befindliche Jobs und nachgelagerte Benachrichtigungen auf verzögerte oder doppelte Arbeit.
Das gewünschte Ergebnis ist nicht einfach nur „die Seite wurde geöffnet“. Sie möchten, dass die ursprünglich autorisierte Operation erfolgreich ist, mit der erwarteten Antwort und ohne unvorhergesehene Nebenwirkungen.
Checkliste zur Selbstkontrolle
Umfang: Haben Sie sowohl die Vertrauensseite auf Produktebene als auch die betroffene Instanz überprüft?
Umgebung: Haben Sie überprüft, ob es sich um die Produktionsumgebung oder die Sandbox-Umgebung handelt und ob die richtige My Domain oder Instanz verwendet wird?
Nachweis: Haben Sie den genauen HTTP-Code, den Fehlercode, die Uhrzeit und die geschwärzte Antwort gespeichert?
Sicherheit: Haben Sie während des Vorfalls Schreib-, Lösch-, Massen-, Bereitstellungs- und Migrationsanforderungen vermieden?
Entscheidung: Haben Sie zwischen einem reinen Workbench-Verhalten und einem Fehler der Salesforce-API unterschieden?
Wiederherstellung: Haben Sie den ursprünglichen Vorgang erneut getestet und verzögerte Folgearbeiten überprüft?
Fazit
Bei Salesforce Workbench-Fehlern während Ausfallzeiten sollten Sie zunächst den Vertrauensstatus und die betroffene Instanz überprüfen und anschließend die HTTP-Antwort klassifizieren, bevor Sie Anmeldeinformationen ändern oder Anfragen neu schreiben. Wiederholte Fehler 500, 502 oder 503 bei einfachen Lesetests und ein zugehöriger Vertrauensvorfall deuten auf ein Problem mit Salesforce hin. Fehler 401, 403, 400 oder ein reiner Workbench-Fehler erfordern in der Regel eine Fehlerbehebung bei Authentifizierung, Berechtigungen, Anfragen, Browser oder Workbench selbst. Da Workbench kein von Salesforce unterstütztes Produkt ist, dürfen keine Produktionsdaten darin verarbeitet werden. Dokumentieren Sie die Abgrenzung klar und verwenden Sie bei Änderungen der Beweislage die aktuellsten offiziellen Status- und Supportrichtlinien.