Når Salesforce Workbench pludselig holder op med at logge ind, REST Explorer returnerer en fejl, eller en forespørgsel, der fungerede for få minutter siden, begynder at få timeout, er den hurtigste vej ikke at blive ved med at klikke på "Prøv igen". Bestem først, hvilket lag der fejler: Workbench-webappen, din browser eller dit netværk, Salesforce-godkendelse, din specifikke Salesforce-instans eller selve API-anmodningen.
Denne sondring er vigtig, fordi Workbench er et community-vedligeholdt, webbaseret API-værktøj snarere end et fuldt understøttet Salesforce-produkt. Salesforce siger eksplicit, at de ikke vedligeholder Workbench og anbefaler understøttede alternativer såsom Salesforce CLI, Code Builder og Salesforce Extensions til Visual Studio Code. Selve Workbench-projektet beskriver også værktøjet som kun vedligeholdelsesbaseret. Se Salesforces vejledning til erstatning af Workbench og det originale Workbench-kildelager .
Brug denne side som en praktisk reference, når der er mistanke om et driftsafbrydelse eller en forringet service. Målet er at bevare bevismateriale, undgå unødvendige gentagne forsøg og beslutte, om man skal vente, skifte værktøjer eller reparere noget lokalt.
| Check | Hvad skal man kigge efter | Hvad det fortæller dig |
|---|---|---|
| Salesforce Trust | Hændelse, forringelse, vedligeholdelse eller instansspecifik påvirkning | Om Salesforce rapporterer et problem på platformsiden |
| Selve arbejdsbænken | Kan loginsiden indlæses? Omdirigerer OAuth korrekt? | Om det community-hostede værktøj er tilgængeligt |
| Salesforce-login | Kan du logge ind på organisationen normalt? | Om godkendelse er bredt påvirket |
| Minimalt API-kald | Prøv et letvægtsslutpunkt, f.eks /services/data/. eller/services/data/v66.0/limits | Om API-stien fungerer uafhængigt af en kompleks forespørgsel |
| Fejlkode | 401, 403, 404, 5xx, timeout, REQUEST_LIMIT_EXCEEDED,UNSUPPORTED_API_VERSION | Hvilken fejlfindingsgren skal følges |
| Anden klient | Salesforce CLI, en eksisterende integration eller en anden godkendt API-klient | Om fejlen er specifik for arbejdsbænken |
Gå til det officielle Salesforce Trust-statuswebsted , og søg efter den instans, det domæne, den pod eller den lejer, der er relevant for din organisation. Salesforce-hændelser kan være regionale eller instansspecifikke, så en grøn status for en urelateret instans beviser ikke, at din organisation er sund.
Hvis Trust rapporterer en serviceafbrydelse, forringelse af ydeevnen, loginproblem eller vedligeholdelse, der påvirker dit miljø, skal du registrere hændelses-ID'et og tidspunktet. Undgå derefter at foretage spekulative ændringer af tilsluttede apps, legitimationsoplysninger, profiler, tilladelsessæt, netværkspolitikker eller API-versioner, medmindre fejlen specifikt peger på disse indstillinger. Konfigurationsændringer foretaget under et afbrydelse kan skabe et andet problem, efter platformen er genoprettet.
Workbench sender ofte Salesforce API-fejlsvar igennem med begrænset fortolkning. Det er nyttigt til fejlfinding: den nøjagtige HTTP-status, Salesforce-fejlkode, slutpunkt og meddelelse fortæller dig normalt mere end et generisk browserbanner.
En timeout, 502, 503 eller anden 5xx-respons kan være i overensstemmelse med serviceforringelse, overbelastet infrastruktur eller en mellemliggende netværksfejl. Antag ikke, at en 5xx beviser et Salesforce-omfattende nedbrud. Sammenlign den samme lightweight-anmodning fra en anden godkendt klient, og tjek Trust. Hvis flere klienter fejler mod den samme Salesforce-instans på samme tid, peger beviserne væk fra Workbench alene.
Disse peger generelt på godkendelses- eller sessionsproblemer. Godkend igen med OAuth i stedet for at kopiere gamle sessions-id'er mellem browsere. Hvis normalt Salesforce-login også mislykkes, og Trust rapporterer loginpåvirkning, skal du vente på tjenestegendannelse, før du roterer legitimationsoplysninger. Hvis Salesforce-login fungerer, men Workbench OAuth ikke gør, skal du undersøge stien til den tilsluttede Workbench-app eller bruge en understøttet alternativ klient.
En 403-fejl betyder normalt, at anmodningen er nået frem til en tjeneste, der har afvist den. Kontroller brugertilladelser, politik for tilsluttede apps, IP-begrænsninger og den nøjagtige Salesforce-fejlkode. Et kendt Workbench-specifikt eksempel er OAUTH_APP_BLOCKED, som kan opstå, når en administrator blokerer den tilsluttede Workbench-app. Workbench-projektets vejledning til tilsluttede apps beskriver dette scenarie.
Under en formodet strømafbrydelse må du ikke diagnosticere med en masseindlæsning, metadataudrulning, lang SOQL-forespørgsel eller et flertrinsscript. Start med et skrivebeskyttet slutpunkt, der er billigt at udføre. I REST Explorer GET /services/data/kontrollerer en anmodning som f.eks. grundlæggende API-tilgængelighed. En anmodning som f.eks. GET /services/data/v66.0/limitskan hjælpe dig med at inspicere organisationens grænser, når API'en fungerer.
Salesforce dokumenterer Workbench REST Explorer som en måde at kalde REST-slutpunkter på, men Workbench er ikke ideel til store eller ydeevnekrævende operationer. Den originale Workbench-dokumentation bemærker, at browser- og forbindelsestimeouts gør den bedre egnet til hurtige, on-the-fly API-interaktioner end store dataindlæsninger eller eksporter.
REQUEST_LIMIT_EXCEEDEDer ikke det samme som et platformsnedbrud. Salesforce anvender API-anmodningsallokeringer, og når en organisation overskrider sin rullende forbrugsgrænse, kan yderligere API-kald blokeres, indtil forbruget falder til under tærsklen. Salesforces supportartikel fra juli 2026 bekræfter, at REST API-, SOAP API-, Bulk API- og Bulk API 2.0-kald alle bidrager til API-forbruget. Se Salesforce-vejledningen til REQUEST_LIMIT_EXCEEDED og dens forklaring af rullende API-grænser .
Hvis fejlen er en grænsebetingelse, forværrer gentagne forsøg situationen ved at forbruge flere kald, når anmodninger stadig accepteres. Identificer integrationer med stor volumen, sæt ikke-essentielle job på pause, hvor det er driftsmæssigt sikkert, og overvåg brugen i Salesforce-opsætningen. Vent ikke på en tillidshændelse for at løse et lejerspecifikt grænseproblem.
UNSUPPORTED_API_VERSIONfortjener sin egen gren. Salesforce udgav en supportartikel i maj 2026, der forklarede, at Workbench kan bruge en nyere API-version som standard, før en produktions- eller Developer Edition-organisation understøtter den. Den anbefalede Workbench-løsning er at sænke standard-API-versionen til en, der understøttes af målorganisationen. Se Salesforces fejlfindingsartikel om UNSUPPORTED_API_VERSION .
Dette er vigtigt i udgivelsesvinduer, fordi en uoverensstemmelse mellem API og version kan ligne et nedbrud, hvis du kun fokuserer på timingen. Bekræft selve versionsfejlen, før du venter på platformgendannelse.
Hvis opgaven er presserende, og Workbench er den eneste komponent, der fejler, skal du reproducere den mindste anmodning ved hjælp af Salesforce CLI eller en anden understøttet, godkendt klient. Formålet er diagnose, ikke at omgå et ægte Salesforce-nedbrud. Hvis begge klienter fejler mod den samme organisation med sammenlignelige serversidefejl, er det usandsynligt, at det at skifte værktøj vil genoprette tjenesten. Hvis CLI lykkes, mens Workbench fejler, har du stærkere beviser for, at Workbench-hosting, browsersession eller stien til den tilsluttede app er problemet.
Under en bekræftet serviceafbrydelse hjælper aggressive manuelle genforsøg sjældent. For automatiserede klienter skal du bruge begrænsede genforsøg med eksponentiel backoff og jitter, hvor dit integrationsdesign tillader det. Ved manuel brug på Workbench skal du vente på en meningsfuld statusopdatering eller et rimeligt interval, før du gentager den samme anmodning.
Vær særligt forsigtig ved skrivehandlinger. En timeout beviser ikke altid, at Salesforce ikke gjorde noget; klienten kan have mistet svaret, efter at serveren behandlede anmodningen. Før du genindsender en oprettelse, opdatering, sletning eller implementering, skal du kontrollere, om den oprindelige handling blev udført. Duplikerede skrivninger er ofte mere skadelige end et forsinket nyt forsøg.
| Symptom | Mest nyttige næste tjek | Undgå |
|---|---|---|
| Workbench-siden indlæses ikke | Kontrollér tilgængeligheden af Workbench, og brug en anden godkendt klient | Ændring af Salesforce-tilladelser med det samme |
| OAuth-omdirigeringer mislykkes | Tjek Salesforce-login, tillid og politik for tilsluttede apps | Deling af sessions-ID'er eller legitimationsoplysninger |
| REST Explorer returnerer 5xx | Markér Tillid og gentag et minimalt skrivebeskyttet kald fra en anden klient | Kørsel af større testjobs |
REQUEST_LIMIT_EXCEEDED | Gennemgå organisationens API-forbrug og rullende grænser | Hurtige genforsøg |
UNSUPPORTED_API_VERSION | Vælg en API-version, der understøttes af målorganisationen | Venter på et strømafbrydelse, der måske ikke eksisterer |
| Kun én kompleks forespørgsel får timeout | Forenkl forespørgslen og undersøg selektivitet/volumen | Forudsat platformomfattende nedetid |
errorCodeog et kort uddrag af svaret.Indsæt aldrig adgangstokens, adgangskoder, sessions-id'er, OAuth-godkendelseskoder eller fulde følsomme data i delte billetter eller chatkanaler.
Skift væk fra Workbench, når fejlen tydeligt er isoleret til Workbench, når handlingen er for stor til et browserbaseret værktøj, når du har brug for gentagne scriptede funktioner, eller når du har brug for en understøttet udviklingsworkflow. Salesforces egen vejledning til erstatning henviser specifikt udviklere til Code Builder, Salesforce CLI og Salesforce Extensions til VS Code.
Skift ikke værktøj blot for at blive ved med at hamre en utilgængelig Salesforce-tjeneste. En anden klient kan ikke løse et serverside-nedbrud, og gentagne opkald kan gøre diagnosen mere støjende. Under nedetid er det bedste resultat en klar klassificering: bekræftet platformhændelse, Workbench-only-fejl, lokalt netværk/browser-problem, API-versionsmatch, tilladelses-/godkendelsesproblem, API-grænseudmattelse eller anmodningsspecifik fejl.
Salesforce Workbench-fejl er nemmere at håndtere, når du behandler dem som signaler, ikke diagnoser. Tjek Salesforce Trust, bevar den nøjagtige fejl, reducer anmodningen, sammenlign med én understøttet klient, og følg fejlkoden. Denne sekvens hjælper dig med at undgå unødvendige konfigurationsændringer under afbrydelser, samtidig med at du opdager problemer, der ligner nedetid, men som faktisk er lejerspecifikke eller Workbench-specifikke.
Gennemgå bemærkelsesværdige Salesforce-nedbrud i 2025, hvad der fejlede, hvor længe udvalgte hændelser varede, og de praktiske erfaringer om modstandsdygtighed, som teams kan anvende.
Byg en praktisk Salesforce-plan for kontinuitet i nedetid med konsekvensanalyse, RTO/RPO-mål, manuelle løsninger, integrationskontroller og genoprettelsestjek.
Lær, hvordan du kontakter Salesforce Support under et større nedbrud: Tjek tillidsstatus, vælg den rigtige kanal, åbn en stærk sag, og spor gendannelse.
Fejlfind Salesforce Workbench login, REST Explorer, timeout, 503, API-version og begræns fejl under nedetid med en praktisk diagnostisk tjekliste.
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å de vigtigste årsager til udbredt nedetid i skyen, hvordan fejl opstår i flere omgange, hvad man skal kontrollere først, og hvordan man designer en mere robust genopretningsplan.
Hvis Datorama eller Marketing Cloud Intelligence ser ud til at være nede, kan du bruge denne evidensbaserede tjekliste til at verificere nedbruddet, beskytte rapporteringskvaliteten og vide, hvornår data er troværdige igen.
A practical look at how Heroku outages can affect deployed apps, dynos, routing, databases, deploys, Heroku Connect, logs, and recovery.
Understand how Salesforce and AWS connect through Hyperforce, integrations, networking, data residency, outages, and shared operational responsibilities.
Et AWS-nedbrud betyder ikke automatisk, at Salesforce er nede. Lær, hvordan Hyperforce, regioner, instanser og Salesforce Trust afgør, om din organisation er berørt.
