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.
| Sjekke | Hva du skal se etter | Hva det forteller deg |
|---|---|---|
| Salesforce Trust | Hendelse, degradering, vedlikehold eller instansspesifikk påvirkning | Om Salesforce rapporterer et problem på plattformsiden |
| Arbeidsbenken i seg selv | Kan innloggingssiden lastes inn? Omdirigerer OAuth riktig? | Om det fellesskapsbaserte verktøyet er tilgjengelig |
| Salesforce-pålogging | Kan du logge inn på organisasjonen på vanlig måte? | Om autentisering er i stor grad påvirket |
| Minimalt API-kall | Prøv et lett endepunkt, for eksempel /services/data/eller/services/data/v66.0/limits | Om API-banen fungerer uavhengig av en kompleks spørring |
| Feilkode | 401, 403, 404, 5xx, tidsavbrudd, REQUEST_LIMIT_EXCEEDED,UNSUPPORTED_API_VERSION | Hvilken feilsøkingsgren skal følges |
| Andre klient | Salesforce CLI, en eksisterende integrasjon eller en annen godkjent API-klient | Om feilen er spesifikk for arbeidsbenken |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
| Symptom | Mest nyttig neste sjekk | Unngå |
|---|---|---|
| Arbeidsbenksiden lastes ikke inn | Sjekk tilgjengeligheten til Workbench og bruk en annen godkjent klient | Endre Salesforce-tillatelser umiddelbart |
| OAuth-viderekoblinger mislykkes | Sjekk Salesforce-pålogging, tillit og policy for tilkoblede apper | Deling av økt-ID-er eller legitimasjon |
| REST Explorer returnerer 5xx | Sjekk tillit og gjenta et minimalt skrivebeskyttet kall fra en annen klient | Kjører større testjobber |
REQUEST_LIMIT_EXCEEDED | Gjennomgå organisasjonens API-forbruk og rullerende grenser | Raske nye forsøk |
UNSUPPORTED_API_VERSION | Velg en API-versjon som støttes av målorganisasjonen | Venter på et strømbrudd som kanskje ikke eksisterer |
| Bare én kompleks spørring får tidsavbrudd | Forenkle spørringen og inspiser selektivitet/volum | Forutsatt nedetid på plattformen |
errorCodeog et kort utdrag av svaret.Lim aldri inn tilgangstokener, passord, økt-ID-er, OAuth-autorisasjonskoder eller fullstendige sensitive nyttelaster i delte billetter eller chatkanaler.
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.
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.
Gjennomgå bemerkelsesverdige Salesforce-avbrudd i 2025, hva som feilet, hvor lenge utvalgte hendelser varte, og de praktiske lærdommene om robusthet teamene kan bruke.
Bygg en praktisk kontinuitetsplan for nedetid i Salesforce med konsekvensanalyse, RTO/RPO-mål, manuelle løsninger, integrasjonskontroller og gjenopprettingskontroller.
Learn how to contact Salesforce Support during a major outage: check Trust Status, choose the right channel, open a strong case, and track recovery.
Feilsøk Salesforce Workbench-innlogging, REST Explorer, timeout, 503, API-versjon og begrens feil under nedetid med en praktisk diagnostisk sjekkliste.
StoreForce issues can disrupt scheduling, timekeeping, and employee workflows. Learn how to assess impact, keep stores operating, verify recovery, and know when to escalate.
Forstå hovedårsakene til utbredt nedetid i skyen, hvordan feil oppstår, hva du bør sjekke først og hvordan du kan utforme en mer robust gjenopprettingsplan.
Hvis Datorama eller Marketing Cloud Intelligence ser ut til å være nede, bruk denne evidensbaserte sjekklisten for å bekrefte driftsstansen, beskytte rapporteringskvaliteten og vite når dataene er pålitelige igjen.
Et praktisk blikk på hvordan Heroku-avbrudd kan påvirke distribuerte apper, dynamoer, ruting, databaser, distribusjoner, Heroku Connect, logger og gjenoppretting.
En praktisk tilbakeblikk på store Salesforce-avbrudd i 2025, inkludert årsaker, tidslinjer, berørte tjenester, lærdommer og kontinuitetstrinn for administratorer.
Et AWS-avbrudd betyr ikke automatisk at Salesforce er nede. Lær hvordan Hyperforce, regioner, instanser og Salesforce Trust avgjør om organisasjonen din er berørt.
