Když se Salesforce Workbench náhle přestane přihlašovat, REST Explorer vrátí chybu nebo dotaz, který fungoval před několika minutami, začne vypršet časový limit, nejrychlejší cestou je neklikat na tlačítko Opakovat. Nejprve zjistěte, která vrstva selhává: webová aplikace Workbench, váš prohlížeč nebo síť, ověřování Salesforce, vaše konkrétní instance Salesforce nebo samotný požadavek API.
Toto rozlišení je důležité, protože Workbench je webový API nástroj spravovaný komunitou, nikoli plně podporovaný produkt Salesforce. Salesforce výslovně uvádí, že Workbench neudržuje, a doporučuje podporované alternativy, jako je Salesforce CLI, Code Builder a Salesforce Extensions for Visual Studio Code. Samotný projekt Workbench také popisuje nástroj jako nástroj určený pouze pro údržbu. Viz pokyny k nahrazení Workbenche od Salesforce a původní repozitář zdrojového kódu Workbenche .
Tuto stránku použijte jako praktickou referenci v případě podezření na výpadek nebo zhoršenou kvalitu služby. Cílem je zachovat důkazy, vyhnout se zbytečným opakováním pokusů a rozhodnout se, zda počkat, změnit nástroje nebo opravit něco lokálně.
| Kontrola | Na co se zaměřit | Co vám to říká |
|---|---|---|
| Důvěra Salesforce | Dopad na incident, degradaci, údržbu nebo specifický pro danou instanci | Zda Salesforce hlásí problém na straně platformy |
| Samotný pracovní stůl | Může se načíst přihlašovací stránka? Přesměrovává OAuth správně? | Zda je nástroj hostovaný komunitou dostupný |
| Přihlášení do Salesforce | Můžete se normálně přihlásit do organizace? | Zda je ověřování obecně ovlivněno |
| Minimální volání API | Zkuste odlehčený koncový bod, například /services/data/nebo/services/data/v66.0/limits | Zda cesta API funguje nezávisle na složitém dotazu |
| Kód chyby | 401, 403, 404, 5xx, časový limit, REQUEST_LIMIT_EXCEEDED,UNSUPPORTED_API_VERSION | Kterou větev pro řešení problémů sledovat |
| Druhý klient | Rozhraní Salesforce CLI, existující integrace nebo jiný schválený klient API | Zda je selhání specifické pro Workbench |
Přejděte na oficiální web věnovaný důvěryhodnosti Salesforce a vyhledejte instanci, doménu, pod nebo tenanta relevantního pro vaši organizaci. Incidenty Salesforce mohou být regionální nebo specifické pro danou instanci, takže zelený stav pro nesouvisející instanci nedokazuje, že je vaše organizace v pořádku.
Pokud Trust nahlásí narušení služby, snížení výkonu, problém s přihlášením nebo údržbu ovlivňující vaše prostředí, zaznamenejte si ID a čas incidentu. Poté se vyhněte provádění spekulativních změn v připojených aplikacích, přihlašovacích údajích, profilech, sadách oprávnění, síťových zásadách nebo verzích API, pokud chyba konkrétně neodkazuje na tato nastavení. Změny konfigurace provedené během výpadku mohou po obnovení platformy způsobit druhý problém.
Workbench často propouští chybové odpovědi Salesforce API s malou interpretací. To je užitečné pro řešení problémů: přesný stav HTTP, kód chyby Salesforce, koncový bod a zpráva vám obvykle řeknou více než obecný banner v prohlížeči.
Časový limit, chyba 502, 503 nebo jiná odpověď 5xx může souviset se zhoršením služby, přetíženou infrastrukturou nebo přechodným selháním sítě. Nepředpokládejte, že chyba 5xx dokazuje výpadek celého systému Salesforce. Porovnejte stejný odlehčený požadavek od jiného schváleného klienta a zkontrolujte důvěryhodnost. Pokud dojde k selhání více klientů u stejné instance Salesforce současně, důkazy nesměřují pouze k systému Workbench.
Tyto problémy obvykle poukazují na problémy s ověřováním nebo relací. Místo kopírování starých ID relací mezi prohlížeči proveďte opětovné ověřování pomocí OAuth. Pokud selže i normální přihlášení k Salesforce a Trust hlásí dopad na přihlášení, počkejte na obnovení služby před otočením přihlašovacích údajů. Pokud přihlášení k Salesforce funguje, ale OAuth k Workbench ne, prozkoumejte cestu k připojené aplikaci Workbench nebo použijte podporovaného alternativního klienta.
Kód chyby 403 obvykle znamená, že požadavek dorazil ke službě, která jej odmítla. Zkontrolujte uživatelská oprávnění, zásady pro připojené aplikace, omezení IP adres a přesný kód chyby Salesforce. Jedním známým příkladem specifickým pro Workbench je chyba , která může nastat, když správce zablokuje připojenou aplikaci Workbench. Tento scénář popisuje návod k připojeným aplikacímOAUTH_APP_BLOCKED projektu Workbench .
Během podezření na výpadek neprovádějte diagnostiku hromadným načítáním, nasazením metadat, dlouhým dotazem SOQL ani vícekrokovým skriptem. Začněte s koncovým bodem pouze pro čtení, který se snadno spustí. V REST Exploreru požadavek, jako například , GET /services/data/kontroluje základní dostupnost API. Požadavek, jako například , GET /services/data/v66.0/limitsvám může pomoci kontrolovat limity organizace, když API funguje.
Salesforce dokumentuje Workbench REST Explorer jako způsob volání REST koncových bodů, ale Workbench není ideální pro rozsáhlé nebo výkonově náročné operace. Původní dokumentace Workbenchu uvádí, že časové limity prohlížeče a připojení jej činí vhodnějším pro rychlé interakce s API za běhu než pro velké načítání nebo exporty dat.
REQUEST_LIMIT_EXCEEDEDnení totéž co výpadek platformy. Salesforce používá alokace požadavků API a když organizace překročí svůj limit průběžného využití, další volání API mohou být blokována, dokud využití neklesne pod prahovou hodnotu. Článek podpory Salesforce z července 2026 potvrzuje, že volání REST API, SOAP API, Bulk API a Bulk API 2.0 přispívají ke spotřebě API. Viz pokyny Salesforce pro REQUEST_LIMIT_EXCEEDED a vysvětlení jeho průběžného limitu API .
Pokud je chyba limitní podmínkou, opakované pokusy situaci zhoršují tím, že spotřebovávají více volání, i když jsou požadavky stále přijímány. Identifikujte integrace s vysokým objemem, pozastavte nepodstatné úlohy tam, kde je to provozně bezpečné, a sledujte využití v nastavení Salesforce. Nečekejte na incident důvěryhodnosti, abyste vyřešili problém s limitem specifickým pro daného klienta.
UNSUPPORTED_API_VERSIONzaslouží si vlastní větev. Salesforce publikoval v květnu 2026 článek podpory, který vysvětluje, že Workbench může standardně používat novější verzi API dříve, než ji bude podporovat produkční organizace nebo organizace pro vývojáře. Doporučená oprava Workbench je snížit výchozí verzi API na verzi podporovanou cílovou organizací. Viz článek Salesforce o řešení problémů s UNSUPPORTED_API_VERSION .
To je důležité během období vydání, protože nesoulad mezi verzí API může vypadat jako výpadek, pokud se zaměříte pouze na načasování. Než budete čekat na obnovení platformy, ověřte samotnou chybu verze.
Pokud je úkol naléhavý a Workbench je jedinou selhávající součástí, reprodukujte nejmenší požadavek pomocí rozhraní příkazového řádku Salesforce nebo jiného podporovaného a schváleného klienta. Účelem je diagnostika, nikoli obcházení skutečného výpadku Salesforce. Pokud oba klienti selžou ve stejné organizaci se srovnatelnými chybami na straně serveru, je nepravděpodobné, že by přepnutí nástrojů obnovilo službu. Pokud rozhraní příkazového řádku uspěje, zatímco Workbench selže, máte silnější důkaz, že problém je v hostování Workbenchu, relaci prohlížeče nebo cestě připojené aplikace.
Během potvrzeného přerušení služby agresivní manuální opakované pokusy málokdy pomohou. U automatizovaných klientů používejte omezené opakované pokusy s exponenciálním zpožděním a jitterem, pokud to váš integrační návrh umožňuje. Pro manuální použití Workbenchu počkejte na smysluplnou aktualizaci stavu nebo na rozumný interval, než stejný požadavek zopakujete.
U operací zápisu buďte obzvláště opatrní. Časový limit ne vždy dokazuje, že Salesforce nic neudělal; klient mohl ztratit odpověď poté, co server zpracoval požadavek. Před opětovným odesláním příkazu create, update, delete nebo deployment ověřte, zda byla původní akce potvrzena. Duplicitní zápisy jsou často škodlivější než opožděný opakování.
| Příznak | Nejužitečnější další kontrola | Vyhněte se |
|---|---|---|
| Stránka Workbenchu se nenačítá | Zkontrolujte dosažitelnost Workbenche a použijte jiného schváleného klienta | Okamžitá změna oprávnění Salesforce |
| Přesměrování OAuth selhalo | Zkontrolujte přihlášení do Salesforce, důvěryhodnost a zásady pro propojené aplikace | Sdílení ID relací nebo přihlašovacích údajů |
| REST Explorer vrací 5xx | Zkontrolujte důvěryhodnost a zopakujte minimální volání pouze pro čtení od druhého klienta. | Spouštění rozsáhlejších testovacích úloh |
REQUEST_LIMIT_EXCEEDED | Spotřeba API organizace Review a postupné limity | Rychlé opakované pokusy |
UNSUPPORTED_API_VERSION | Vyberte verzi API podporovanou cílovou organizací | Čekání na výpadek, který nemusí existovat |
| Časový limit pouze jednoho komplexního dotazu vyprší. | Zjednodušte dotaz a zkontrolujte selektivitu/objem | Za předpokladu výpadku celé platformy |
errorCodea krátký výňatek z odpovědi.Nikdy nevkládejte přístupové tokeny, hesla, ID relací, autorizační kódy OAuth ani plně citlivé datové části do sdílených tiketů nebo chatovacích kanálů.
Přepněte z Workbenchu na Workbench, pokud je selhání jasně izolované, pokud je operace příliš rozsáhlá pro nástroj založený na prohlížeči, pokud potřebujete opakovatelné chování skriptů nebo pokud vyžadujete podporovaný vývojový pracovní postup. Vlastní pokyny k nahrazení od Salesforce konkrétně odkazují vývojáře na Code Builder, Salesforce CLI a Salesforce Extensions pro VS Code.
Neměňte nástroje jen proto, abyste neustále ztěžovali práci s nedostupnou službou Salesforce. Jiný klient nedokáže opravit výpadek na straně serveru a opakovaná volání mohou diagnostiku zkomplikovat. Během výpadku je nejlepším výsledkem jasná klasifikace: potvrzený incident platformy, selhání pouze Workbench, problém s lokální sítí/prohlížečem, nesoulad verzí API, problém s oprávněními/autentizací, vyčerpání limitu API nebo selhání specifické pro daný požadavek.
Chyby Salesforce Workbench se snáze řeší, když se s nimi zachází jako se signály, nikoliv jako s diagnózami. Zkontrolujte důvěryhodnost Salesforce, zachovejte přesnou chybu, snižte počet požadavků, porovnejte s jedním podporovaným klientem a řiďte se kódem chyby. Tato sekvence vám pomůže vyhnout se zbytečným změnám konfigurace během výpadků a zároveň odhalí problémy, které vypadají jako prostoje, ale ve skutečnosti jsou specifické pro daného klienta nebo Workbench.
Projděte si významné výpadky Salesforce v roce 2025, co selhalo, jak dlouho trvaly vybrané incidenty a praktické ponaučení z odolnosti, které mohou týmy uplatnit.
Vytvořte praktický plán pro zajištění kontinuity výpadků v Salesforce s analýzou dopadů, cíli RTO/RPO, manuálními řešeními, integračními kontrolami a kontrolami obnovy.
Zjistěte, jak kontaktovat podporu Salesforce během velkého výpadku: zkontrolujte stav důvěryhodnosti, vyberte správný kanál, začněte s důkladným podáním žádosti a sledujte obnovení.
Řešení problémů s přihlášením do Salesforce Workbench, REST Explorerem, časovým limitem, chybou 503, verzí API a omezením chyb během výpadků pomocí praktického diagnostického kontrolního seznamu.
StoreForce issues can disrupt scheduling, timekeeping, and employee workflows. Learn how to assess impact, keep stores operating, verify recovery, and know when to escalate.
Pochopte hlavní příčiny rozsáhlých výpadků cloudu, jak se selhání kaskádovitě šíří, co zkontrolovat jako první a jak navrhnout odolnější plán obnovy.
Pokud se zdá, že Datorama nebo Marketing Cloud Intelligence nefungují, použijte tento kontrolní seznam založený na důkazech k ověření výpadku, ochraně kvality reportů a zjištění, kdy jsou data opět důvěryhodná.
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.
An AWS outage does not automatically mean Salesforce is down. Learn how Hyperforce, regions, instances, and Salesforce Trust determine whether your org is affected.
