Acasă
» Tehnologie
»
Salesforce Workbench Errors: Troubleshooting API Tools During Downtime
Salesforce Workbench Errors: Troubleshooting API Tools During Downtime
Verified September 16, 2026. Workbench errors are easy to misread during a Salesforce incident. A failed login may come from an expired session, a wrong environment, a broken Workbench route, or a Salesforce API outage. A request that returns 503 Service Unavailable points in a different direction from a 401 Invalid Session, even though both can appear when a developer is trying to work quickly.
The goal of troubleshooting is not to force one request through. It is to identify which layer is failing, protect data while the system is unstable, and know when the evidence is strong enough to wait, switch tools, or contact the right support channel.
Quick diagnosis: what does the error most likely indicate?
What you see
Most likely layer
Best next move
Workbench page will not load
Workbench site, browser, DNS, or network path
Open Salesforce Trust Status and test the site from a permitted alternate network.
Workbench loads, but login fails with 401
Session, OAuth, username, password, or login flow
Start a fresh authorized login and confirm the selected environment.
API request returns 403
Permissions, connected-app policy, or API limit
Check the user, connected app, and request limits; do not treat it as proof of downtime.
Several API calls return 500, 502, or 503
Salesforce platform, edge routing, maintenance, or overload
Compare the error time with your instance and product status on Trust.
Only one query or object fails
Request syntax, object access, record sharing, or data issue
Reduce the request to a harmless, known-good read and inspect the response body.
This table is a starting point, not a diagnosis. The same HTTP code can have different causes depending on the endpoint, authentication method, and organization policy.
First, understand Workbench’s support boundary
Workbench is a browser-based suite for interacting with Salesforce organizations through several APIs, including REST, SOAP, Bulk, Streaming, Metadata, and Apex-related tools. However, the Workbench site states that it is not an official Salesforce product and that Salesforce support is not available for Workbench itself. Its About page also warns users not to use the application with production data.
That warning changes how you should respond during downtime. Salesforce Support can investigate a Salesforce service, instance, or API problem, but it may not troubleshoot every Workbench interface behavior. Conversely, an issue reported only by Workbench may belong to Workbench or to the browser path rather than the Salesforce platform.
Keep the troubleshooting read-only whenever possible. Do not paste passwords, OAuth secrets, session IDs, access tokens, customer records, or unredacted request headers into screenshots, chat messages, or public issue reports.
Start by identifying the Workbench login path and selected environment. The interface shown is an illustrative mockup, not a live login screen or a request to enter credentials into an article image.
Step 1: Check Salesforce Trust Status before changing Workbench settings
Open Salesforce Trust Status in a separate tab. Salesforce’s help documentation directs customers to this page for product outages and service degradation, and the Trust site can show information for products as well as specific instances.
Check two views:
The broad product view: look for an incident, service degradation, disruption, or maintenance event affecting the Salesforce service you use.
Your instance view: search for your instance or My Domain and open the matching result.
An instance marked Available is not a guarantee that every API operation will work. It means the instance and its services are available according to Salesforce’s status definition. Performance Degradation suggests access may work with latency or partial functionality; Service Disruption means the instance is unavailable; Maintenance indicates a maintenance event that may or may not affect access.
Step 1 — Compare the broad Trust Status information with the affected org’s instance. The screen shown is an illustrative guide to the documented lookup workflow, not evidence of a live incident.
Step 2: Confirm the environment and org before retrying
Workbench can connect to different Salesforce environments. Before concluding that an API is down, confirm whether the failing request targets production, a sandbox, or another authorized environment. A test that succeeds in one environment does not clear the environment that is actually failing.
Use the My Domain or instance identifier for the affected org. Salesforce documents that the My Domain prefix can be used in Trust Status, while an administrator can find the instance in Setup under Company Information. Write down the instance, environment, API version, approximate failure time, and endpoint. This small record prevents a common mistake: comparing a production error with a healthy sandbox status.
If the Workbench login page itself shows an unsupported login method or loops back to the login screen, treat that as a separate authentication or Workbench issue until Trust Status and a direct Salesforce login indicate otherwise. Do not repeatedly submit credentials during a suspected outage; excessive retries can create lockouts or add noise to the investigation.
Step 3: Classify the API response instead of guessing
Salesforce’s REST API documentation explains that the response header contains an HTTP status code and that the body usually contains a message and, when relevant, the field or object associated with the error. Preserve both pieces of evidence.
Code
Indiciu documentat al Salesforce
Cum să o interpretezi în timpul perioadelor de nefuncționare
400
Cererea nu a putut fi înțeleasă, adesea deoarece corpul JSON sau XML este nevalid.
De obicei, remediați solicitarea înainte de a o trata ca pe o întrerupere.
401
ID-ul sesiunii sau token-ul OAuth a expirat sau este nevalid.
Reautentificați-vă printr-un flux aprobat; un cod 401 în sine nu constituie o dovadă a unei întreruperi a platformei.
403
Cererea a fost refuzată, adesea din cauza permisiunilor sau a unei limite API.
Verificați accesul și limitele înainte de a escalada situația ca un incident de disponibilitate.
500
A apărut o eroare în platforma Lightning.
Reîncercați numai după înregistrarea răspunsului; comparați eșecurile repetate cu Statusul de încredere.
502
Salesforce Edge nu a putut comunica cu succes cu instanța.
O problemă de rutare sau de pe partea platformei este posibilă, în special în cazul mai multor cereri.
503
Serverul nu este disponibil; pot fi implicate lucrări de întreținere sau supraîncărcare.
Verificați dacă există un incident sau un eveniment de întreținere și evitați reîncercările distructive.
Pasul 3 — Înregistrați codul HTTP și semnificația răspunsului înainte de a modifica acreditările sau solicitările. Exemplul nu conține niciun token, date despre clienți sau identificator real de incident.
Pasul 4: Rulați un test de comparație sigur
După ce cunoașteți starea și mediul, utilizați cel mai mic test permis, doar pentru citire. O comparație bună are trei proprietăți: vizează organizația afectată, nu modifică datele și este suficient de simplă încât o eroare de format a cererii este puțin probabilă.
Repetați aceeași solicitare inofensivă o dată după înregistrarea primului răspuns.
Dacă solicitarea returnează codul 401, începeți un nou flux de autentificare autorizată în loc să reutilizați o sesiune veche.
Dacă returnează 400, 403 sau 404, verificați endpoint-ul, versiunea API, numele obiectului, permisiunile și corpul cererii.
Dacă returnează 500, 502 sau 503 în mod repetat, comparați ora și instanța cu Statusul de încredere.
Dacă interfața browserului funcționează, dar Workbench eșuează, testați aceeași cale API autorizată cu un client intern aprobat sau o diagnosticare de integrare.
Nu utilizați o solicitare de scriere, ștergere, actualizare în bloc, implementare de metadate sau migrare ca verificare a stării de funcționare. În timpul unui incident, o scriere poate crea rezultate parțiale, poate duplica munca sau poate crea o impresie falsă că a avut loc recuperarea.
Când ar trebui să vă schimbați abordarea de depanare?
Schimbați abordarea atunci când Statusul de Încredere indică un incident
Opriți reproiectarea interogării decât dacă aveți dovezi independente că solicitarea este incorectă. Salvați numărul incidentului, serviciul afectat, instanța, ora de începere și cea mai recentă actualizare. Urmați mesajele de recuperare Salesforce și protejați lucrările din coadă de încercările duplicate.
Schimbați abordarea când Statusul de încredere este disponibil, dar Workbench-ul singur eșuează
Concentrați-vă pe Workbench, browser, rețea, autentificare sau politică locală. Încercați o fereastră privată de browser, un browser alternativ acceptat și o comparație de rețele permisă. Site-ul Workbench direcționează asistența specifică Workbench către resursele comunității sale open-source, în timp ce Salesforce Help rămâne ruta pentru asistența pentru produsele și conturile Salesforce.
Schimbați abordarea când eroarea este constantă 401 sau 403
Treceți la analiza identității și a autorizării. Confirmați utilizatorul, politica aplicației conectate, domeniul de aplicare OAuth, vechimea sesiunii, accesul API, profilul sau setul de permisiuni și limitele organizației. Reîmprospătarea repetată a browserului nu va repara o permisiune lipsă sau un token nevalid.
Schimbați abordarea când un endpoint eșuează, dar citirile simple funcționează
Investigați endpoint-ul, obiectul, câmpul, partajarea înregistrărilor, versiunea API, corpul cererii și corpul răspunsului. O eroare limitată nu este suficientă pentru a eticheta Salesforce la nivel global. Reduceți cererea până când puteți identifica dacă problema este sintaxa, accesul, datele sau un serviciu dependent.
Pasul 4 — Respectați limitele de asistență și siguranță ale Workbench. Folosiți asistența Salesforce aprobată pentru incidentele platformei și resursele comunității open-source pentru comportamentul specific Workbench.
Cod HTTP, cod de eroare și corp de răspuns redactat
Dacă interfața cu utilizatorul Salesforce, un alt utilizator sau un alt client aprobat eșuează, de asemenea
Numărul incidentului de Stare de Încredere sau o notă care indică faptul că nu a fost vizibil niciun eveniment corespondent
Eliminați acreditările, ID-urile de sesiune, token-urile de acces, numele clienților, ID-urile de înregistrare și sarcinile utile sensibile înainte de a trimite jurnalele. Dacă problema este doar legată de Workbench, utilizați ruta de asistență identificată pe pagina de ajutor Workbench ; Salesforce nu oferă asistență pentru produsul Workbench în sine.
Cum se verifică recuperarea
Un indicator de stare verde este încurajator, dar nu reprezintă linia de sosire. Verificați recuperarea în straturi:
Confirmați că pagina incidentului afișează o rezoluție sau instanța revine la starea Disponibilă.
Conectați-vă prin fluxul Salesforce sau Workbench aprobat fără a reutiliza o sesiune învechită.
Executați aceeași solicitare doar în citire inofensivă care a eșuat anterior.
Comparați codul HTTP, timpul de răspuns și corpul răspunsului cu eroarea înregistrată.
Verificați integrările, joburile aflate în coadă și notificările din aval pentru lucrări întârziate sau duplicate.
Rezultatul dorit nu este pur și simplu „pagina deschisă”. Doriți ca operațiunea autorizată inițială să aibă succes, cu răspunsul așteptat și fără efecte secundare neravizuite.
Listă de verificare pentru autoevaluare
Domeniu de aplicare: Ați verificat atât pagina de încredere la nivel de produs, cât și instanța afectată?
Mediu: Ați confirmat producția versus sandbox și Domeniul meu sau instanța corectă?
Dovadă: Ați salvat codul HTTP exact, codul de eroare, ora și răspunsul redactat?
Siguranță: Ați evitat solicitările de scriere, ștergere, implementare în bloc, implementare și migrare în timpul incidentului?
Decizie: Ați făcut distincția între comportamentul Workbench-ului exclusiv și eșecul API-ului Salesforce?
Recuperare: Ați retestat operațiunea inițială și ați inspectat lucrările ulterioare întârziate?
Concluzie
Pentru erorile Salesforce Workbench în timpul perioadelor de nefuncționare, începeți cu Starea de încredere și instanța afectată, apoi clasificați răspunsul HTTP înainte de a modifica acreditările sau a rescrie cererile. O eroare repetată 500, 502 sau 503 în teste simple doar de citire și un incident de încredere corespunzător susține o explicație din partea Salesforce. O eroare 401, 403, 400 sau doar Workbench necesită de obicei autentificare, permisiuni, cereri, browser sau depanare Workbench. Deoarece Workbench nu este un produs acceptat de Salesforce, păstrați datele de producție în afara acestuia, documentați clar limita și utilizați cea mai recentă stare oficială și îndrumări de asistență atunci când dovezile se modifică.