Salesforce Workbench-feil: Feilsøking av API-verktøy under nedetid

Salesforce Workbench-feil under nedetid: start med å skille verktøyfeil fra plattformfeil

Når Salesforce Workbench plutselig slutter å logge inn, REST Explorer returnerer en feil, eller en spørring som fungerte for minutter siden begynner å tidsavbrytes, er den raskeste veien ikke å stadig klikke på Prøv på nytt. Finn først ut hvilket lag som feiler: Workbench-nettappen, nettleseren eller nettverket ditt, Salesforce-autentisering, din spesifikke Salesforce-instans eller selve API-forespørselen.

Denne forskjellen er viktig fordi Workbench er et fellesskapsvedlikeholdt, nettbasert API-verktøy snarere enn et fullt støttet Salesforce-produkt. Salesforce sier eksplisitt at de ikke vedlikeholder Workbench og anbefaler støttede alternativer som Salesforce CLI, Code Builder og Salesforce Extensions for Visual Studio Code. Selve Workbench-prosjektet beskriver også verktøyet som kun vedlikeholdsbasert. Se Salesforces veiledning for erstatning av Workbench og det originale Workbench-kildelageret .

Bruk denne siden som en praktisk referanse når det er mistanke om driftsstans eller forringet tjeneste. Målet er å bevare bevis, unngå unødvendige nye forsøk og avgjøre om man skal vente, bytte verktøy eller fikse noe lokalt.

Rask triage-sjekkliste

1. Sjekk Salesforce Trust før du endrer konfigurasjonen

Gå til det offisielle nettstedet for Salesforce Trust-status og søk etter forekomsten, domenet, pod-en eller leietakeren som er relevant for organisasjonen din. Salesforce-hendelser kan være regionale eller forekomstspesifikke, så en grønn status for en urelatert forekomst beviser ikke at organisasjonen din er i god form.

Hvis Trust rapporterer et tjenesteavbrudd, ytelsesforringelse, påloggingsproblem eller vedlikehold som påvirker miljøet ditt, må du registrere hendelses-ID-en og tidspunktet. Unngå deretter å gjøre spekulative endringer i tilkoblede apper, legitimasjon, profiler, tillatelsessett, nettverkspolicyer eller API-versjoner med mindre feilen spesifikt peker på disse innstillingene. Konfigurasjonsendringer som gjøres under et driftsavbrudd kan skape et nytt problem etter at plattformen gjenopprettes.

2. Bevar den nøyaktige Workbench-feilen og klassifiser den

Workbench sender ofte feilsvar fra Salesforce API med lite tolkning. Det er nyttig for feilsøking: den nøyaktige HTTP-statusen, Salesforce-feilkoden, endepunktet og meldingen forteller deg vanligvis mer enn et generisk nettleserbanner.

Tilkoblingsfeil, tidsavbrudd eller HTTP 5xx

En timeout, 502, 503 eller annen 5xx-respons kan være forenlig med tjenesteforringelse, overbelastet infrastruktur eller en mellomliggende nettverksfeil. Ikke anta at en 5xx beviser et Salesforce-omfattende driftsstans. Sammenlign den samme lette forespørselen fra en annen godkjent klient og sjekk tillit. Hvis flere klienter mislykkes mot samme Salesforce-instans samtidig, peker bevisene bort fra Workbench alene.

401- eller ugyldige øktfeil

Disse peker vanligvis på autentiserings- eller øktproblemer. Autentiser på nytt med OAuth i stedet for å kopiere gamle økt-ID-er mellom nettlesere. Hvis vanlig Salesforce-pålogging også mislykkes og Trust rapporterer påloggingspåvirkning, vent til tjenesten er gjenopprettet før du roterer legitimasjon. Hvis Salesforce-pålogging fungerer, men Workbench OAuth ikke gjør det, undersøk banen til den tilkoblede appen i Workbench eller bruk en støttet alternativ klient.

403- og autorisasjonsfeil

En 403-feil betyr vanligvis at forespørselen har nådd en tjeneste som har avvist den. Sjekk brukertillatelser, policy for tilkoblet app, IP-begrensninger og den nøyaktige Salesforce-feilkoden. Et kjent Workbench-spesifikt eksempel er OAUTH_APP_BLOCKED, som kan oppstå når en administrator blokkerer den tilkoblede Workbench-appen. Workbench-prosjektets veiledning for tilkoblede apper beskriver dette scenariet.

3. Reduser testen til den minste sikre API-forespørselen

Under et mistenkt driftsavbrudd, ikke diagnostiser med masseinnlasting, metadatadistribusjon, lang SOQL-spørring eller flertrinnsskript. Start med et skrivebeskyttet endepunkt som er billig å kjøre. I REST Explorer GET /services/data/sjekker en forespørsel som grunnleggende API-tilgjengelighet. En forespørsel som GET /services/data/v66.0/limitskan hjelpe deg med å inspisere organisasjonsgrenser når API-et fungerer.

Salesforce dokumenterer Workbench REST Explorer som en måte å kalle REST-endepunkter på, men Workbench er ikke ideell for store eller ytelsesintensive operasjoner. Den originale Workbench-dokumentasjonen bemerker at tidsavbrudd for nettlesere og tilkoblinger gjør den bedre egnet til raske API-interaksjoner underveis enn store datalastinger eller eksporter.

4. Behandle API-grensefeil annerledes enn nedetid

REQUEST_LIMIT_EXCEEDEDer ikke det samme som et plattformbrudd. Salesforce bruker API-forespørselstildelinger, og når en organisasjon overskrider sin rullerende bruksgrense, kan ytterligere API-kall blokkeres inntil bruken faller under terskelen. Salesforces støtteartikkel fra juli 2026 bekrefter at REST API-, SOAP API-, Bulk API- og Bulk API 2.0-kall alle bidrar til API-forbruk. Se Salesforce-veiledningen for REQUEST_LIMIT_EXCEEDED og forklaringen av rullerende API-grenser .

Hvis feilen er en grensebetingelse, forverrer gjentatte forsøk situasjonen ved å bruke flere anrop når forespørsler fortsatt aksepteres. Identifiser integrasjoner med høyt volum, sett ikke-essensielle jobber på pause der det er driftsmessig trygt, og overvåk bruken i Salesforce-oppsettet. Ikke vent på en tillitshendelse for å løse et leietakerspesifikt grenseproblem.

5. Sjekk om det er en avvik i API-versjonen

UNSUPPORTED_API_VERSIONfortjener sin egen gren. Salesforce publiserte en støtteartikkel i mai 2026 som forklarte at Workbench kan bruke en nyere API-versjon som standard før en produksjons- eller Developer Edition-organisasjon støtter den. Den anbefalte Workbench-løsningen er å senke standard API-versjonen til en som støttes av målorganisasjonen. Se Salesforces feilsøkingsartikkel UNSUPPORTED_API_VERSION .

Dette er viktig i utgivelsesvinduer fordi en API-versjonsavvik kan se ut som et driftsavbrudd hvis du bare fokuserer på timingen. Bekreft selve versjonsfeilen før du venter på plattformgjenoppretting.

6. Sammenlign Workbench med en støttet klient

Hvis oppgaven haster og Workbench er den eneste komponenten som feiler, reproduser den minste forespørselen ved hjelp av Salesforce CLI eller en annen støttet, godkjent klient. Formålet er diagnose, ikke å omgå et ekte Salesforce-avbrudd. Hvis begge klientene feiler mot samme organisasjon med sammenlignbare feil på serversiden, er det usannsynlig at det å bytte verktøy vil gjenopprette tjenesten. Hvis CLI lykkes mens Workbench feiler, har du sterkere bevis for at Workbench-hostingen, nettleserøkten eller banen til den tilkoblede appen er problemet.

7. Bruk disiplin for nye forsøk i stedet for stormer av nye forsøk

Under et bekreftet tjenesteavbrudd hjelper aggressive manuelle forsøk sjelden. For automatiserte klienter, bruk begrensede forsøk med eksponentiell tilbakekobling og jitter der integrasjonsdesignet tillater det. For manuell bruk på arbeidsbenken, vent på en meningsfull statusoppdatering eller et rimelig intervall før du gjentar den samme forespørselen.

Vær spesielt forsiktig for skriveoperasjoner. En tidsavbrudd beviser ikke alltid at Salesforce ikke gjorde noe; klienten kan ha mistet svaret etter at serveren behandlet forespørselen. Før du sender inn en oppretting, oppdatering, sletting eller distribusjon på nytt, må du kontrollere om den opprinnelige handlingen ble utført. Dupliserte skrivinger er ofte mer skadelige enn et forsinket nytt forsøk.

Vanlige symptomer og neste tiltak

Hvilke bevis bør du samle inn for en hendelsesbot?

• UTC-tidsstempel og din lokale tidssone.
• Salesforce-organisasjons- og forekomstidentifikatorer som er trygge å dele internt.
• Det nøyaktige endepunktet og HTTP-metoden, med sensitive parametere fjernet.
• HTTP-status, Salesforce errorCodeog et kort utdrag av svaret.
• Om vanlig Salesforce-pålogging fungerte.
• Om den samme minimale forespørselen mislyktes fra en annen godkjent klient.
• Relevant Salesforce Trust-hendelses-ID eller en merknad om at ingen samsvarende hendelse var synlig.
• Om operasjonen var skrivebeskyttet eller kunne ha utført en skriving.

Lim aldri inn tilgangstokener, passord, økt-ID-er, OAuth-autorisasjonskoder eller fullstendige sensitive nyttelaster i delte billetter eller chatkanaler.

Når du skal stoppe feilsøking av arbeidsbenk og bytte av verktøy

Bytt fra Workbench når feilen er tydelig isolert til Workbench, når operasjonen er for stor for et nettleserbasert verktøy, når du trenger repeterbar skriptet oppførsel, eller når du trenger en støttet utviklingsarbeidsflyt. Salesforces egen erstatningsveiledning peker spesifikt utviklere mot Code Builder, Salesforce CLI og Salesforce Extensions for VS Code.

Ikke bytt verktøy bare for å fortsette å hamre på en utilgjengelig Salesforce-tjeneste. En annen klient kan ikke fikse et serversidebrudd, og gjentatte anrop kan gjøre diagnosen mer støyende. Under nedetid er det beste resultatet en klar klassifisering: bekreftet plattformhendelse, feil kun på arbeidsbenken, problem med lokalt nettverk/nettleser, avvik i API-versjon, problem med tillatelser/autentisering, uttømming av API-grenser eller forespørselsspesifikk feil.

Konklusjon

Salesforce Workbench-feil er enklere å håndtere når du behandler dem som signaler, ikke diagnoser. Sjekk Salesforce Trust, behold den nøyaktige feilen, reduser forespørselen, sammenlign med én støttet klient og følg feilkoden. Denne sekvensen hjelper deg med å unngå unødvendige konfigurasjonsendringer under driftsavbrudd, samtidig som den fanger opp problemer som ser ut som nedetid, men som faktisk er leierspesifikke eller Workbench-spesifikke.