När Salesforce Workbench plötsligt slutar logga in, REST Explorer returnerar ett fel, eller en fråga som fungerade för några minuter sedan börjar få tidsgränsen, är det snabbaste sättet att inte klicka på "Försök igen" hela tiden. Bestäm först vilket lager som misslyckas: Workbench-webbappen, din webbläsare eller ditt nätverk, Salesforce-autentisering, din specifika Salesforce-instans eller själva API-begäran.
Den skillnaden är viktig eftersom Workbench är ett community-underhållet, webbaserat API-verktyg snarare än en fullt stödd Salesforce-produkt. Salesforce säger uttryckligen att de inte underhåller Workbench och rekommenderar stödda alternativ som Salesforce CLI, Code Builder och Salesforce Extensions för Visual Studio Code. Själva Workbench-projektet beskriver också verktyget som endast underhållsbaserat. Se Salesforces riktlinjer för ersättning av Workbench och den ursprungliga Workbench-källkodsförteckningen .
Använd den här sidan som en praktisk referens när man misstänker ett avbrott eller en försämrad tjänst. Målet är att bevara bevis, undvika onödiga omförsök och avgöra om man ska vänta, byta verktyg eller åtgärda något lokalt.
| Kontrollera | Vad man ska leta efter | Vad det säger dig |
|---|---|---|
| Salesforce Trust | Incident-, försämrings-, underhålls- eller instansspecifik påverkan | Huruvida Salesforce rapporterar ett problem på plattformssidan |
| Själva arbetsbänken | Kan inloggningssidan laddas? Omdirigerar OAuth korrekt? | Om det community-hostade verktyget är tillgängligt |
| Salesforce-inloggning | Kan du logga in på organisationen normalt? | Huruvida autentisering påverkas i stor utsträckning |
| Minimalt API-anrop | Prova en lättviktig slutpunkt som /services/data/eller/services/data/v66.0/limits | Om API-sökvägen fungerar oberoende av en komplex fråga |
| Felkod | 401, 403, 404, 5xx, timeout, REQUEST_LIMIT_EXCEEDED,UNSUPPORTED_API_VERSION | Vilken felsökningsgren ska följas |
| Andra klienten | Salesforce CLI, en befintlig integration eller en annan godkänd API-klient | Om felet är specifikt för Workbench |
Gå till den officiella webbplatsen för Salesforce Trust-status och sök efter den instans, domän, pod eller hyresgäst som är relevant för din organisation. Salesforce-incidenter kan vara regionala eller instansspecifika, så en grön status för en orelaterad instans bevisar inte att din organisation är felfri.
Om Trust rapporterar ett avbrott i tjänsten, prestandaförsämring, inloggningsproblem eller underhåll som påverkar din miljö, registrera incident-ID och tidpunkt. Undvik sedan att göra spekulativa ändringar i anslutna appar, autentiseringsuppgifter, profiler, behörighetsuppsättningar, nätverkspolicyer eller API-versioner om inte felet specifikt pekar på dessa inställningar. Konfigurationsändringar som görs under ett avbrott kan skapa ett andra problem efter att plattformen återställts.
Workbench skickar ofta igenom Salesforce API-felsvar med liten tolkning. Det är användbart för felsökning: den exakta HTTP-statusen, Salesforce-felkoden, slutpunkten och meddelandet säger vanligtvis mer än en generisk webbläsarbanner.
En timeout, 502, 503 eller annan 5xx-respons kan vara förenlig med tjänsteförsämring, överbelastad infrastruktur eller ett mellanliggande nätverksfel. Anta inte att en 5xx bevisar ett Salesforce-omfattande avbrott. Jämför samma lättviktsbegäran från en annan godkänd klient och kontrollera förtroendet. Om flera klienter misslyckas mot samma Salesforce-instans samtidigt pekar bevisen bort från enbart Workbench.
Dessa tyder generellt på autentiserings- eller sessionsproblem. Autentisera igen med OAuth istället för att kopiera gamla sessions-ID:n mellan webbläsare. Om normal Salesforce-inloggning också misslyckas och Trust rapporterar inloggningspåverkan, vänta på tjänståterställning innan du roterar autentiseringsuppgifter. Om Salesforce-inloggning fungerar men Workbench OAuth inte gör det, undersök sökvägen för Workbench-anslutna appen eller använd en alternativ klient som stöds.
Ett 403-fel betyder vanligtvis att begäran nådde en tjänst som avvisade den. Kontrollera användarbehörigheter, policy för anslutna appar, IP-begränsningar och den exakta Salesforce-felkoden. Ett känt Workbench-specifikt exempel är OAUTH_APP_BLOCKED, vilket kan inträffa när en administratör blockerar den anslutna Workbench-appen. Workbench-projektets vägledning för anslutna appar beskriver detta scenario.
Under ett misstänkt avbrott, diagnostisera inte med en bulkbelastning, metadatadistribution, lång SOQL-fråga eller flerstegsskript. Börja med en skrivskyddad slutpunkt som är billig att köra. I REST Explorer GET /services/data/kontrollerar en begäran som grundläggande API-nåbarhet. En begäran som GET /services/data/v66.0/limitskan hjälpa dig att inspektera organisationsgränser när API:et fungerar.
Salesforce dokumenterar Workbench REST Explorer som ett sätt att anropa REST-slutpunkter, men Workbench är inte idealiskt för stora eller prestandakrävande operationer. Den ursprungliga Workbench-dokumentationen noterar att timeouts för webbläsare och anslutningar gör den bättre lämpad för snabba API-interaktioner i realtid än stora datainläsningar eller exporter.
REQUEST_LIMIT_EXCEEDEDär inte samma sak som ett plattformsavbrott. Salesforce tillämpar API-förfrågningsallokeringar, och när en organisation överskrider sin rullande användningsgräns kan ytterligare API-anrop blockeras tills användningen sjunker under tröskeln. Salesforces supportartikel från juli 2026 bekräftar att REST API-, SOAP API-, Bulk API- och Bulk API 2.0-anrop alla bidrar till API-förbrukning. Se Salesforces vägledning för REQUEST_LIMIT_EXCEEDED och dess förklaring av rullande API-gränser .
Om felet är ett gränsvillkor förvärrar upprepade försök situationen genom att förbruka fler anrop när förfrågningar fortfarande accepteras. Identifiera integrationer med hög volym, pausa icke-nödvändiga jobb där det är driftsäkert och övervaka användningen i Salesforce-installationen. Vänta inte på en förtroendeincident för att lösa ett hyresgästspecifikt gränsproblem.
UNSUPPORTED_API_VERSIONförtjänar en egen gren. Salesforce publicerade en supportartikel i maj 2026 som förklarade att Workbench kan använda en nyare API-version som standard innan en produktions- eller Developer Edition-organisation stöder den. Den rekommenderade Workbench-åtgärden är att sänka standard-API-versionen till en som stöds av målorganisationen. Se Salesforces felsökningsartikel UNSUPPORTED_API_VERSION .
Detta är viktigt under utgivningsfönster eftersom en API-versionsmatchning kan se ut som ett avbrott om du bara fokuserar på tidpunkten. Verifiera själva versionsfelet innan du väntar på plattformsåterställning.
Om uppgiften är brådskande och Workbench är den enda komponenten som misslyckas, reproducera den minsta begäran med Salesforce CLI eller en annan klient som stöds och godkänts. Syftet är diagnos, inte att kringgå ett genuint Salesforce-avbrott. Om båda klienterna misslyckas mot samma organisation med jämförbara fel på serversidan, är det osannolikt att det återställer tjänsten att byta verktyg. Om CLI lyckas medan Workbench misslyckas, har du starkare bevis för att Workbench-värdskapet, webbläsarsessionen eller sökvägen till den anslutna appen är problemet.
Under ett bekräftat avbrott i tjänsten hjälper aggressiva manuella försök sällan. För automatiserade klienter, använd begränsade försök med exponentiell backoff och jitter där din integrationsdesign tillåter det. För manuell användning i Workbench, vänta på en meningsfull statusuppdatering eller ett rimligt intervall innan du upprepar samma begäran.
Var särskilt försiktig vid skrivåtgärder. En timeout bevisar inte alltid att Salesforce inte gjorde någonting; klienten kan ha förlorat svaret efter att servern bearbetade begäran. Innan du skickar in en ny åtgärd för att skapa, uppdatera, ta bort eller distribuera, kontrollera om den ursprungliga åtgärden har utförts. Dubbletter av skrivningar är ofta mer skadliga än ett fördröjt försök.
| Symptom | Mest användbar nästa kontroll | Undvika |
|---|---|---|
| Workbench-sidan laddas inte | Kontrollera Workbench-åtkomligheten och använd en annan godkänd klient | Ändra Salesforce-behörigheter omedelbart |
| OAuth-omdirigeringar misslyckas | Kontrollera Salesforce inloggning, förtroende och policy för anslutna appar | Dela sessions-ID:n eller inloggningsuppgifter |
| REST Explorer returnerar 5xx | Kontrollera förtroendet och upprepa ett minimalt skrivskyddat anrop från en andra klient | Köra större testjobb |
REQUEST_LIMIT_EXCEEDED | Granska organisationens API-förbrukning och rullande gränser | Snabba återförsök |
UNSUPPORTED_API_VERSION | Välj en API-version som stöds av målorganisationen | Väntar på ett avbrott som kanske inte existerar |
| Endast en komplex fråga har timeout | Förenkla frågan och inspektera selektivitet/volym | Förutsatt plattformsomfattande driftstopp |
errorCodeoch ett kort svarsutdrag.Klistra aldrig in åtkomsttokens, lösenord, sessions-ID:n, OAuth-auktoriseringskoder eller fullständiga känsliga nyttolaster i delade ärenden eller chattkanaler.
Växla från Workbench när felet är tydligt isolerat till Workbench, när operationen är för stor för ett webbläsarbaserat verktyg, när du behöver repeterbart skriptbeteende eller när du behöver ett utvecklingsarbetsflöde som stöds. Salesforces egna ersättningsriktlinjer hänvisar specifikt utvecklare till Code Builder, Salesforce CLI och Salesforce Extensions för VS Code.
Byt inte verktyg bara för att fortsätta att pressa på en otillgänglig Salesforce-tjänst. En annan klient kan inte åtgärda ett serveravbrott, och upprepade anrop kan göra diagnosen mer bullrig. Under driftstopp är det bästa resultatet en tydlig klassificering: bekräftad plattformsincident, fel endast på Workbench, problem med lokalt nätverk/webbläsare, API-versionsmatchning som inte matchar, behörighets-/autentiseringsproblem, API-gränsutmattning eller förfrågningsspecifikt fel.
Salesforce Workbench-fel är enklare att hantera när du behandlar dem som signaler, inte diagnoser. Kontrollera Salesforce Trust, bevara det exakta felet, minska antalet begäranden, jämför med en klient som stöds och följ felkoden. Den sekvensen hjälper dig att undvika onödiga konfigurationsändringar under avbrott samtidigt som du upptäcker problem som ser ut som driftstopp men som i själva verket är hyresgästspecifika eller Workbench-specifika.
Granska anmärkningsvärda Salesforce-avbrott under 2025, vad som misslyckades, hur länge utvalda incidenter varade och de praktiska lärdomar om motståndskraft som team kan tillämpa.
Skapa en praktisk Salesforce-plan för kontinuitet i driftstopp med konsekvensanalys, RTO/RPO-mål, manuella lösningar, integrationskontroller och återställningskontroller.
Lär dig hur du kontaktar Salesforce Support under ett större avbrott: kontrollera förtroendestatus, välj rätt kanal, öppna ett starkt ärende och spåra återställningen.
Felsök Salesforce Workbench-inloggning, REST Explorer, timeout, 503, API-version och begränsa fel under driftstopp med en praktisk diagnostisk checklista.
StoreForce issues can disrupt scheduling, timekeeping, and employee workflows. Learn how to assess impact, keep stores operating, verify recovery, and know when to escalate.
Förstå de främsta orsakerna till utbredda driftstopp i molnet, hur fel uppstår i flera steg, vad man ska kontrollera först och hur man utformar en mer motståndskraftig återställningsplan.
Om Datorama eller Marketing Cloud Intelligence verkar vara nere, använd den här evidensbaserade checklistan för att verifiera avbrottet, skydda rapporteringskvaliteten och veta när data är tillförlitliga igen.
A practical look at how Heroku outages can affect deployed apps, dynos, routing, databases, deploys, Heroku Connect, logs, and recovery.
Förstå hur Salesforce och AWS kopplas samman via Hyperforce, integrationer, nätverk, datalagring, avbrott och delat driftsansvar.
Ett AWS-avbrott betyder inte automatiskt att Salesforce ligger nere. Lär dig hur Hyperforce, regioner, instanser och Salesforce Trust avgör om din organisation påverkas.
