Home
» Technologie
»
Salesforce Workbench-fouten: Problemen met API-tools oplossen tijdens downtime
Salesforce Workbench-fouten: Problemen met API-tools oplossen tijdens downtime
Geverifieerd op 16 september 2026. Workbench-fouten zijn gemakkelijk verkeerd te interpreteren tijdens een Salesforce-incident. Een mislukte aanmelding kan het gevolg zijn van een verlopen sessie, een verkeerde omgeving, een defecte Workbench-route of een storing in de Salesforce API. Een verzoek dat een 503 Service Unavailablefoutmelding retourneert, wijst in een andere richting dan een foutmelding 401 Invalid Session, hoewel beide kunnen voorkomen wanneer een ontwikkelaar snel probeert te werken.
Het doel van probleemoplossing is niet om één verzoek erdoorheen te drukken. Het is om te achterhalen welke laag faalt, gegevens te beschermen terwijl het systeem instabiel is, en te weten wanneer er voldoende bewijs is om te wachten, andere tools te gebruiken of contact op te nemen met de juiste ondersteuningsinstantie.
Snelle diagnose: wat duidt de foutmelding waarschijnlijk aan?
Wat je ziet
Meest waarschijnlijke laag
Beste volgende stap
De werkbankpagina laadt niet.
Werkbanksite, browser, DNS of netwerkpad
Open Salesforce Trust Status en test de site vanuit een toegestaan alternatief netwerk.
Workbench laadt wel, maar inloggen mislukt met een 401-fout.
Sessie, OAuth, gebruikersnaam, wachtwoord of inlogproces
Start een nieuwe geautoriseerde login en bevestig de geselecteerde omgeving.
API-verzoek retourneert 403
Machtigingen, beleid voor verbonden apps of API-limiet
Controleer de limieten voor gebruikers, verbonden apps en aanvragen; beschouw dit niet als bewijs van uitval.
Verschillende API-aanroepen retourneren 500, 502 of 503.
Salesforce-platform, edge routing, onderhoud of overbelasting
Vergelijk de fouttijd met uw instantie- en productstatus in Trust.
Slechts één query of object mislukt.
Verzoeksyntaxis, objecttoegang, het delen van records of een gegevensprobleem
Vereenvoudig het verzoek tot een onschadelijke, aantoonbaar correcte tekst en inspecteer de inhoud van het antwoord.
Deze tabel is een uitgangspunt, geen diagnose. Dezelfde HTTP-code kan verschillende oorzaken hebben, afhankelijk van het eindpunt, de authenticatiemethode en het beleid van de organisatie.
Begrijp allereerst de ondersteuningsgrenzen van Workbench.
Workbench is een browsergebaseerde suite voor interactie met Salesforce-organisaties via verschillende API's, waaronder REST, SOAP, Bulk, Streaming, Metadata en Apex-gerelateerde tools. De Workbench-website vermeldt echter dat het geen officieel Salesforce-product is en dat Salesforce geen ondersteuning biedt voor Workbench zelf. Op de 'Over ons'-pagina wordt gebruikers ook gewaarschuwd de applicatie niet te gebruiken met productiedata.
Die waarschuwing heeft invloed op hoe u moet reageren tijdens downtime. Salesforce Support kan een probleem met een Salesforce-service, -instantie of -API onderzoeken, maar kan mogelijk niet elk gedrag van de Workbench-interface verhelpen. Omgekeerd kan een probleem dat alleen door Workbench wordt gemeld, betrekking hebben op Workbench of het browserpad in plaats van op het Salesforce-platform.
Houd de probleemoplossingspagina zoveel mogelijk alleen-lezen. Plak geen wachtwoorden, OAuth-geheimen, sessie-ID's, toegangstokens, klantgegevens of niet-geanonimiseerde aanvraagheaders in schermafbeeldingen, chatberichten of openbare probleemrapporten.
Begin met het identificeren van het inlogpad van Workbench en de geselecteerde omgeving. De getoonde interface is een illustratief voorbeeld, geen live inlogscherm of een verzoek om inloggegevens in te voeren.
Stap 1: Controleer de Salesforce-vertrouwensstatus voordat u de Workbench-instellingen wijzigt.
Open Salesforce Trust Status in een apart tabblad. De helpdocumentatie van Salesforce verwijst klanten naar deze pagina voor productstoringen en serviceproblemen, en de Trust-site kan informatie weergeven over producten en specifieke instanties.
Bekijk twee weergaven:
Het algemene productoverzicht: zoek naar een incident, servicevermindering, storing of onderhoudsgebeurtenis die van invloed is op de Salesforce-service die u gebruikt.
Uw instantieoverzicht: zoek naar uw instantie of Mijn domein en open het overeenkomende resultaat.
Een instantie die als ' Beschikbaar' is gemarkeerd , garandeert niet dat elke API-bewerking zal werken. Het betekent dat de instantie en de bijbehorende services beschikbaar zijn volgens de statusdefinitie van Salesforce. 'Prestatievermindering' geeft aan dat toegang mogelijk met vertraging of gedeeltelijke functionaliteit werkt; 'Serviceonderbreking' betekent dat de instantie niet beschikbaar is; 'Onderhoud' duidt op een onderhoudsgebeurtenis die de toegang al dan niet kan beïnvloeden.
Stap 1 — Vergelijk de algemene informatie over de vertrouwensstatus met de instantie van de betreffende organisatie. Het getoonde scherm is een illustratieve handleiding voor de gedocumenteerde opzoekworkflow en geen bewijs van een daadwerkelijk incident.
Stap 2: Controleer de omgeving en de organisatie voordat u het opnieuw probeert.
Workbench kan verbinding maken met verschillende Salesforce-omgevingen. Voordat u concludeert dat een API niet beschikbaar is, moet u controleren of het mislukte verzoek gericht is op de productieomgeving, een sandbox of een andere geautoriseerde omgeving. Een test die in de ene omgeving slaagt, sluit de omgeving waarin de fout optreedt niet uit.
Gebruik de 'Mijn domein'- of instantie-ID voor de betreffende organisatie. Salesforce documenteert dat het voorvoegsel 'Mijn domein' kan worden gebruikt in de vertrouwensstatus, terwijl een beheerder de instantie kan vinden in de instellingen onder Bedrijfsinformatie . Noteer de instantie, de omgeving, de API-versie, het geschatte tijdstip van de fout en het eindpunt. Deze korte notitie voorkomt een veelgemaakte fout: het vergelijken van een productiefout met een gezonde testomgeving.
Als de inlogpagina van Workbench zelf een niet-ondersteunde inlogmethode weergeeft of terugverwijst naar het inlogscherm, beschouw dit dan als een apart authenticatie- of Workbench-probleem totdat de vertrouwensstatus en een directe Salesforce-login anders aangeven. Dien tijdens een vermoedelijke storing niet herhaaldelijk inloggegevens in; te veel herhaalpogingen kunnen leiden tot blokkeringen of het onderzoek onnodig ingewikkeld maken.
Stap 3: Classificeer het API-antwoord in plaats van te gokken.
De REST API-documentatie van Salesforce legt uit dat de responseheader een HTTP-statuscode bevat en dat de body meestal een bericht bevat en, indien relevant, het veld of object dat aan de fout is gekoppeld. Bewaar beide bewijsstukken.
Code
Salesforce's gedocumenteerde aanwijzing
Hoe moet je het interpreteren tijdens een downtime?
400
Het verzoek kon niet worden begrepen, vaak omdat de JSON- of XML-body ongeldig is.
Verhelp het probleem doorgaans eerst voordat je het als een storing beschouwt.
401
De sessie-ID of het OAuth-token is verlopen of ongeldig.
Herauthenticeer via een goedgekeurde procedure; een 401-foutmelding alleen is geen bewijs van een platformstoring.
403
Het verzoek werd geweigerd, vaak vanwege ontbrekende machtigingen of een API-limiet.
Controleer de toegangsrechten en -limieten voordat u een beschikbaarheidsprobleem meldt.
500
Er is een fout opgetreden in het Lightning-platform.
Probeer het pas opnieuw nadat het antwoord is vastgelegd; vergelijk herhaalde mislukkingen met de vertrouwensstatus.
502
Salesforce Edge kon niet succesvol communiceren met de instantie.
Een routeringsprobleem of een probleem aan de platformzijde is mogelijk, vooral bij meerdere verzoeken.
503
De server is niet beschikbaar; mogelijk is er sprake van onderhoud of overbelasting.
Controleer op incidenten of onderhoudsgebeurtenissen en voorkom onnodige herhaalpogingen.
Stap 3 — Noteer de HTTP-code en de betekenis van het antwoord voordat u inloggegevens of verzoeken wijzigt. Het voorbeeld bevat geen token, klantgegevens of echte incident-ID.
Stap 4: Voer een veilige vergelijkingstest uit
Zodra je de status en de omgeving kent, gebruik je de kleinst mogelijke, alleen-lezen test. Een goede vergelijking heeft drie eigenschappen: hij is gericht op de betreffende organisatie, hij wijzigt geen gegevens en hij is eenvoudig genoeg om een fout in het aanvraagformaat te voorkomen.
Herhaal hetzelfde onschuldige verzoek nog een keer nadat je het eerste antwoord hebt opgenomen.
Als het verzoek een 401-fout retourneert, start dan een nieuwe geautoriseerde authenticatieprocedure in plaats van een oude sessie opnieuw te gebruiken.
Als de aanvraag een 400-, 403- of 404-fout retourneert, controleer dan het eindpunt, de API-versie, de objectnaam, de machtigingen en de aanvraagbody.
Als er herhaaldelijk een 500-, 502- of 503-foutmelding wordt geretourneerd, vergelijk dan de tijd en het instantie-item met de vertrouwensstatus.
Als de gebruikersinterface in de browser wel werkt, maar Workbench niet, test dan hetzelfde geautoriseerde API-pad met een goedgekeurde interne client of een integratiediagnose.
Gebruik een schrijf-, verwijder-, bulkupdate-, metadata-implementatie- of migratieverzoek niet als statuscontrole. Tijdens een incident kan een schrijfbewerking leiden tot gedeeltelijke resultaten, dubbel werk of de valse indruk dat het systeem is hersteld.
Wanneer moet je je aanpak voor probleemoplossing aanpassen?
Wijzig de aanpak wanneer de vertrouwensstatus een incident aangeeft.
Stop met het herontwerpen van de query, tenzij u onafhankelijk bewijs hebt dat het verzoek onjuist is geformuleerd. Bewaar het incidentnummer, de betreffende service, het instantienummer, de starttijd en de laatste update. Volg de herstelberichten van Salesforce en bescherm taken in de wachtrij tegen dubbele herhaalpogingen.
Wijzig de aanpak wanneer de vertrouwensstatus beschikbaar is, maar de werkbank op zichzelf niet werkt.
Focus op Workbench, browser, netwerk, authenticatie of lokaal beleid. Probeer een privévenster in de browser, een ondersteunde alternatieve browser en een toegestane netwerkvergelijking. De Workbench-website verwijst Workbench-specifieke ondersteuning naar de open-source communitybronnen, terwijl Salesforce Help de aangewezen weg blijft voor ondersteuning van Salesforce-producten en -accounts.
Wijzig de aanpak wanneer de fout consistent 401 of 403 is.
Ga verder met de identiteits- en autorisatieanalyse. Controleer de gebruiker, het beleid voor de verbonden app, het OAuth-bereik, de sessieleeftijd, de API-toegang, het profiel of de machtigingenset en de organisatielimieten. Het herhaaldelijk vernieuwen van de browser zal een ontbrekende machtiging of een ongeldig token niet herstellen.
Wijzig de aanpak wanneer één eindpunt faalt, maar eenvoudige leesbewerkingen wel werken.
Onderzoek het eindpunt, object, veld, recorddeling, API-versie, aanvraagbody en antwoordbody. Een specifieke fout is niet voldoende om Salesforce wereldwijd als defect te bestempelen. Verklein de aanvraag totdat u kunt vaststellen of het probleem te maken heeft met de syntaxis, toegang, gegevens of een afhankelijke service.
Stap 4 — Respecteer de ondersteunings- en veiligheidslimieten van Workbench. Gebruik de goedgekeurde Salesforce-ondersteuning voor platformincidenten en open-source communitybronnen voor Workbench-specifiek gedrag.
Welk bewijsmateriaal moet je naar de ondersteuning sturen?
Of het nu gaat om de Salesforce-gebruikersinterface, een andere gebruiker of een andere goedgekeurde klant, het probleem is ook opgetreden.
Het incidentnummer van de vertrouwensstatus of een melding dat er geen overeenkomende gebeurtenis zichtbaar was.
Verwijder inloggegevens, sessie-ID's, toegangstokens, klantnamen, record-ID's en gevoelige gegevens voordat u logboeken verzendt. Als het probleem zich alleen voordoet in Workbench, volg dan de ondersteuningsprocedure die wordt beschreven op de Workbench-help pagina ; Salesforce biedt geen productondersteuning voor Workbench zelf.
Hoe kunt u het herstel controleren?
Een groene statusindicator is bemoedigend, maar het is nog niet het eindpunt. Controleer het herstel in stappen:
Controleer of op de incidentpagina een oplossing wordt weergegeven of dat het incident weer de status 'Beschikbaar' krijgt.
Meld u aan via de goedgekeurde Salesforce- of Workbench-workflow zonder een verlopen sessie opnieuw te gebruiken.
Voer dezelfde onschadelijke, alleen-lezen aanvraag uit die eerder mislukte.
Vergelijk de HTTP-code, de reactietijd en de reactiebody met de geregistreerde fout.
Controleer integraties, taken in de wachtrij en downstream-meldingen op vertraagde of dubbele werkzaamheden.
Het gewenste resultaat is niet simpelweg "de pagina is geopend". U wilt dat de oorspronkelijke, geautoriseerde bewerking slaagt, met de verwachte reactie en zonder ongewenste neveneffecten.
Controlelijst voor zelfcontrole
Omvang: Heeft u zowel de pagina 'Vertrouwen' op productniveau als de betreffende instantie gecontroleerd?
Omgeving: Heeft u de productieomgeving versus de sandboxomgeving en het juiste Mijn Domein of de juiste instantie bevestigd?
Bewijs: Heeft u de exacte HTTP-code, foutcode, tijd en het geanonimiseerde antwoord opgeslagen?
Veiligheid: Heeft u tijdens het incident schrijf-, verwijder-, bulk-, implementatie- en migratieverzoeken vermeden?
Beslissing: Heeft u onderscheid gemaakt tussen gedrag dat alleen in Workbench voorkwam en een storing in de Salesforce API?
Herstel: Heeft u de oorspronkelijke bewerking opnieuw getest en de vertraagde vervolgwerkzaamheden gecontroleerd?
Kortom
Bij Salesforce Workbench-fouten tijdens downtime, begin dan met de vertrouwensstatus en de betreffende instantie. Classificeer vervolgens het HTTP-antwoord voordat u referenties wijzigt of verzoeken herschrijft. Een herhaalde 500-, 502- of 503-fout bij eenvoudige alleen-lezen-tests en een overeenkomend vertrouwensincident ondersteunen een verklaring vanuit Salesforce. Een 401-, 403-, 400-fout of een fout die alleen in Workbench optreedt, vereist doorgaans problemen met authenticatie, machtigingen, het verzoek, de browser of Workbench zelf. Omdat Workbench geen door Salesforce ondersteund product is, moet u productiedata er buiten houden, de grens duidelijk documenteren en de meest recente officiële status- en ondersteuningsrichtlijnen gebruiken wanneer de situatie verandert.