Errori di Salesforce Workbench: Risoluzione dei problemi degli strumenti API durante i periodi di inattività

Verificato il 16 settembre 2026. Gli errori di Workbench sono facili da interpretare erroneamente durante un incidente di Salesforce. Un accesso non riuscito può derivare da una sessione scaduta, un ambiente errato, un percorso di Workbench non funzionante o un'interruzione dell'API di Salesforce. Una richiesta che restituisce 503 Service Unavailableun errore punta in una direzione diversa da un errore 401 Invalid Session, anche se entrambi possono verificarsi quando uno sviluppatore sta cercando di lavorare rapidamente.

L'obiettivo della risoluzione dei problemi non è forzare una singola richiesta, bensì identificare quale livello del sistema non funziona, proteggere i dati mentre il sistema è instabile e capire quando le prove sono sufficientemente solide per attendere, cambiare strumento o contattare il canale di supporto appropriato.

Diagnosi rapida: cosa indica con maggiore probabilità l'errore?

Ciò che vedistrato più probabileLa mossa migliore da fare ora
La pagina Workbench non si caricaSito Workbench, browser, DNS o percorso di reteApri Salesforce Trust Status e testa il sito da una rete alternativa autorizzata.
Workbench si carica, ma l'accesso fallisce con un errore 401.Sessione, OAuth, nome utente, password o flusso di accessoAvvia un nuovo accesso autorizzato e conferma l'ambiente selezionato.
La richiesta API restituisce 403Autorizzazioni, criteri per le app connesse o limiti APIVerifica i limiti relativi all'utente, all'app connessa e alle richieste; non considerarli una prova di interruzione del servizio.
Diverse chiamate API restituiscono 500, 502 o 503Piattaforma Salesforce, routing edge, manutenzione o sovraccaricoConfronta il tempo di errore con lo stato della tua istanza e del tuo prodotto su Trust.
Solo una query o un oggetto non riesceSintassi della richiesta, accesso all'oggetto, condivisione dei record o problema relativo ai datiRiduci la richiesta a una lettura innocua e sicura e analizza il corpo della risposta.

Questa tabella è un punto di partenza, non una diagnosi. Lo stesso codice HTTP può avere cause diverse a seconda dell'endpoint, del metodo di autenticazione e delle policy aziendali.

Innanzitutto, è necessario comprendere i limiti di supporto di Workbench.

Workbench è una suite basata su browser per interagire con le organizzazioni Salesforce tramite diverse API, tra cui REST, SOAP, Bulk, Streaming, Metadati e strumenti correlati ad Apex. Tuttavia, il sito di Workbench dichiara che non si tratta di un prodotto ufficiale Salesforce e che il supporto Salesforce non è disponibile per Workbench stesso. La pagina "Informazioni" avverte inoltre gli utenti di non utilizzare l'applicazione con dati di produzione.

Questo avviso modifica il modo in cui dovresti comportarti durante i periodi di inattività. Il supporto Salesforce può esaminare un problema relativo a un servizio, un'istanza o un'API di Salesforce, ma potrebbe non essere in grado di risolvere ogni comportamento dell'interfaccia di Workbench. Viceversa, un problema segnalato solo da Workbench potrebbe essere correlato a Workbench stesso o al percorso del browser, anziché alla piattaforma Salesforce.

Se possibile, mantieni le sezioni di risoluzione dei problemi in sola lettura. Non incollare password, segreti OAuth, ID di sessione, token di accesso, dati dei clienti o intestazioni di richiesta non oscurate in screenshot, messaggi di chat o segnalazioni di problemi pubbliche.

Schermata di accesso di Workbench a scopo illustrativo, che mostra i campi Standard, Avanzato, OAuth, Ambiente, Versione API, Nome utente, Password, ID sessione e URL del server.
Inizia identificando il percorso di accesso a Workbench e l'ambiente selezionato. L'interfaccia mostrata è un modello illustrativo, non una schermata di accesso reale né una richiesta di inserimento delle credenziali in un'immagine dell'articolo.

Passaggio 1: Verifica lo stato di attendibilità di Salesforce prima di modificare le impostazioni di Workbench

Apri Salesforce Trust Status in una scheda separata. La documentazione di supporto di Salesforce indirizza i clienti a questa pagina in caso di interruzioni del prodotto o degrado del servizio, e il sito Trust può mostrare informazioni sia sui prodotti che su casi specifici.

Controlla due visualizzazioni:

  1. Panoramica generale del prodotto: cerca incidenti, degrado del servizio, interruzioni o interventi di manutenzione che interessano il servizio Salesforce che utilizzi.
  2. Visualizzazione della tua istanza: cerca la tua istanza o Il mio dominio e apri il risultato corrispondente.

Un'istanza contrassegnata come Disponibile non garantisce il funzionamento di tutte le operazioni API. Significa che l'istanza e i relativi servizi sono disponibili in base alla definizione di stato di Salesforce. Degrado delle prestazioni indica che l'accesso potrebbe funzionare con latenza o con funzionalità parziali; Interruzione del servizio indica che l'istanza non è disponibile; Manutenzione indica un evento di manutenzione che potrebbe influire o meno sull'accesso.

Esempio di pagina Stato attendibilità di Salesforce con un campo Cerca istanza o dominio contenente mycompany e un risultato Istanza disponibile.
Passaggio 1: confrontare le informazioni generali sullo stato di attendibilità con l'istanza dell'organizzazione interessata. La schermata mostrata è una guida illustrativa al flusso di lavoro di ricerca documentato, non la prova di un incidente reale.

Passaggio 2: Confermare l'ambiente e l'organizzazione prima di riprovare

Workbench può connettersi a diversi ambienti Salesforce. Prima di concludere che un'API non funziona, è necessario verificare se la richiesta non riuscita è indirizzata all'ambiente di produzione, a un ambiente sandbox o a un altro ambiente autorizzato. Un test che ha successo in un ambiente non esclude che il problema si verifichi nell'ambiente in cui si verifica effettivamente l'errore.

Utilizzate il vostro dominio personale o l'identificativo dell'istanza per l'organizzazione interessata. Salesforce documenta che il prefisso del vostro dominio personale può essere utilizzato in Stato di attendibilità, mentre un amministratore può trovare l'istanza in Configurazione, nella sezione Informazioni sull'azienda . Annotate l'istanza, l'ambiente, la versione dell'API, l'ora approssimativa dell'errore e l'endpoint. Questa semplice informazione evita un errore comune: confrontare un errore di produzione con lo stato corretto di un ambiente di test.

Se la pagina di accesso di Workbench mostra un metodo di accesso non supportato o reindirizza alla schermata di accesso, consideralo un problema di autenticazione o di Workbench separato finché lo stato di attendibilità e un accesso diretto a Salesforce non indichino il contrario. Non inviare ripetutamente le credenziali durante un'interruzione sospetta; tentativi eccessivi possono causare blocchi o complicare l'indagine.

Passaggio 3: Classifica la risposta dell'API invece di fare supposizioni

La documentazione dell'API REST di Salesforce spiega che l'intestazione della risposta contiene un codice di stato HTTP e che il corpo di solito contiene un messaggio e, se pertinente, il campo o l'oggetto associato all'errore. Conserva entrambe le prove.

CodiceIndizio documentato da SalesforceCome interpretarlo durante i periodi di inattività
400La richiesta non è stata compresa, spesso perché il corpo JSON o XML non è valido.Di solito è meglio risolvere la richiesta prima di considerarla un'interruzione del servizio.
401L'ID di sessione o il token OAuth è scaduto o non valido.Riautenticati tramite un flusso approvato; un errore 401 da solo non è prova di un'interruzione della piattaforma.
403La richiesta è stata rifiutata, spesso a causa di problemi di autorizzazioni o di limiti dell'API.Prima di segnalare un problema di disponibilità, verificare l'accesso e i limiti.
500Si è verificato un errore nella piattaforma Lightning.Riprova solo dopo aver registrato la risposta; confronta i ripetuti errori con lo stato di affidabilità.
502Salesforce Edge non è riuscito a comunicare correttamente con l'istanza.È possibile che si tratti di un problema di routing o lato piattaforma, soprattutto in presenza di più richieste.
503Il server non è disponibile; potrebbe essere in corso una manutenzione o essere sovraccarico.Verificare la presenza di incidenti o interventi di manutenzione ed evitare tentativi di ripristino inefficaci.
Schermata illustrativa della richiesta API di Workbench che mostra una richiesta GET sicura e le righe di risposta per 401 Sessione non valida, 502 Salesforce Edge, 503 Servizio non disponibile e 500 Errore interno del server.
Passaggio 3: Registra il codice HTTP e il significato della risposta prima di modificare le credenziali o le richieste. L'esempio non contiene token, dati del cliente o identificativo di incidente reale.

Passaggio 4: Eseguire un test di confronto sicuro

Una volta noti lo stato e l'ambiente, utilizzare il test di sola lettura più piccolo consentito. Un buon confronto ha tre caratteristiche: si rivolge all'organizzazione interessata, non modifica i dati ed è sufficientemente semplice da rendere improbabile un errore nel formato della richiesta.

  1. Ripeti la stessa richiesta innocua una seconda volta dopo aver registrato la prima risposta.
  2. Se la richiesta restituisce 401, avvia un nuovo flusso di autenticazione autorizzato anziché riutilizzare una sessione precedente.
  3. Se restituisce 400, 403 o 404, esamina l'endpoint, la versione dell'API, il nome dell'oggetto, le autorizzazioni e il corpo della richiesta.
  4. Se restituisce ripetutamente i codici 500, 502 o 503, confronta l'ora e l'istanza con lo stato di attendibilità.
  5. Se l'interfaccia utente del browser funziona ma Workbench non funziona, testa lo stesso percorso API autorizzato con un client interno approvato o con uno strumento di diagnostica dell'integrazione.

Non utilizzare richieste di scrittura, eliminazione, aggiornamento in blocco, distribuzione di metadati o migrazione come controllo di integrità. Durante un incidente, una scrittura può generare risultati parziali, duplicazione del lavoro o una falsa impressione di ripristino avvenuto.

Quando è opportuno modificare il proprio approccio alla risoluzione dei problemi?

Cambia approccio quando lo stato di attendibilità segnala un incidente

Smetti di riprogettare la query a meno che tu non abbia prove indipendenti che la richiesta non sia formattata correttamente. Salva il numero dell'incidente, il servizio interessato, l'istanza, l'ora di inizio e l'ultimo aggiornamento. Segui i messaggi di ripristino di Salesforce e proteggi il lavoro in coda da tentativi duplicati.

Cambiare approccio quando lo stato di attendibilità è disponibile ma Workbench da solo non funziona.

Concentrati su Workbench, sul browser, sulla rete, sull'autenticazione o sui criteri locali. Prova una finestra di navigazione in incognito, un browser alternativo supportato e un confronto con una rete consentita. Il sito di Workbench indirizza il supporto specifico per Workbench alle risorse della sua community open source, mentre la Guida di Salesforce rimane il canale di supporto per i prodotti e gli account Salesforce.

Cambiare approccio quando l'errore è sempre 401 o 403.

Passiamo all'analisi di identità e autorizzazione. Verifichiamo l'utente, i criteri dell'app connessa, l'ambito OAuth, la durata della sessione, l'accesso alle API, il profilo o il set di autorizzazioni e i limiti dell'organizzazione. Aggiornare ripetutamente il browser non risolverà un'autorizzazione mancante o un token non valido.

Cambia approccio quando un endpoint non funziona ma le letture semplici funzionano.

Analizza l'endpoint, l'oggetto, il campo, la condivisione dei record, la versione dell'API, il corpo della richiesta e il corpo della risposta. Un errore circoscritto non è sufficiente per etichettare Salesforce come inutilizzabile a livello globale. Riduci la richiesta fino a quando non riesci a identificare se il problema riguarda la sintassi, l'accesso, i dati o un servizio dipendente.

Pagina "Informazioni su Workbench" a scopo illustrativo, che mostra avvisi relativi al fatto che Workbench non è un prodotto ufficiale di Salesforce, non è supportato da Salesforce, non deve essere utilizzato con dati di produzione e gode del supporto della community open source.
Passaggio 4: Rispetta i limiti di supporto e sicurezza di Workbench. Utilizza il supporto Salesforce approvato per gli incidenti della piattaforma e le risorse della community open source per i comportamenti specifici di Workbench.

Quali prove dovresti inviare all'assistenza?

Se il problema con Salesforce persiste, consulta le linee guida ufficiali del supporto Salesforce disponibili tramite il canale previsto dal tuo Piano di Successo. Includi:

  • Identificatore dell'organizzazione, istanza e ambiente
  • Indicazione oraria UTC e fuso orario locale
  • Pagina Workbench o operazione API coinvolta
  • Codice HTTP, codice di errore e corpo della risposta oscurato
  • Sia che si verifichi un errore nell'interfaccia utente di Salesforce, in un altro utente o in un altro client approvato
  • Numero di incidente di Trust Status o una nota che indica che non è stato visualizzato alcun evento corrispondente

Prima di inviare i log, rimuovi credenziali, ID di sessione, token di accesso, nomi dei clienti, ID dei record e payload sensibili. Se il problema riguarda solo Workbench, utilizza il percorso di supporto indicato nella pagina di aiuto di Workbench ; Salesforce non fornisce supporto per Workbench.

Come verificare il ripristino

Un indicatore di stato verde è incoraggiante, ma non rappresenta il traguardo finale. Verifica il recupero a più livelli:

  1. Verificare che la pagina dell'incidente mostri una risoluzione o che l'istanza torni allo stato Disponibile.
  2. Accedi tramite il flusso Salesforce o Workbench approvato, senza riutilizzare una sessione obsoleta.
  3. Esegui la stessa richiesta di sola lettura innocua che in precedenza aveva fallito.
  4. Confronta il codice HTTP, il tempo di risposta e il corpo della risposta con l'errore registrato.
  5. Verifica le integrazioni, i processi in coda e le notifiche a valle per individuare eventuali attività ritardate o duplicate.

Il risultato che desideri non è semplicemente "l'apertura della pagina". Desideri che l'operazione originale autorizzata abbia successo, con la risposta prevista e senza effetti collaterali non verificati.

Lista di controllo per l'autovalutazione

  • Ambito: Hai controllato sia la pagina di attendibilità a livello di prodotto che l'istanza interessata?
  • Ambiente: Hai verificato se l'ambiente di produzione è quello di test e se hai utilizzato il dominio My Domain o l'istanza corretti?
  • Prove: Hai salvato il codice HTTP esatto, il codice di errore, l'ora e la risposta con le informazioni oscurate?
  • Sicurezza: avete evitato richieste di scrittura, cancellazione, elaborazione in blocco, distribuzione e migrazione durante l'incidente?
  • Decisione: Hai distinto il comportamento specifico di Workbench dal fallimento dell'API di Salesforce?
  • Ripristino: Hai eseguito nuovamente il test dell'operazione originale e ispezionato i lavori a valle ritardati?

In conclusione

Per gli errori di Salesforce Workbench durante i periodi di inattività, iniziare con lo stato di attendibilità e l'istanza interessata, quindi classificare la risposta HTTP prima di modificare le credenziali o riscrivere le richieste. Un errore 500, 502 o 503 ripetuto in semplici test di sola lettura e un incidente di attendibilità corrispondente supportano una spiegazione lato Salesforce. Un errore 401, 403, 400 o un errore che si verifica solo in Workbench di solito richiede invece la risoluzione dei problemi di autenticazione, autorizzazioni, richiesta, browser o Workbench. Poiché Workbench non è un prodotto supportato da Salesforce, è necessario non utilizzare dati di produzione, documentare chiaramente i confini e utilizzare le linee guida ufficiali più recenti in materia di stato e supporto quando le prove cambiano.

Fonti ufficiali

Lascia un commento

Tech-Enabled Senior Care in 2026: What AI and Smart Homes Can—and Can’t—Do for Aging in Place

Tech-Enabled Senior Care in 2026: What AI and Smart Homes Can—and Can’t—Do for Aging in Place

A practical 2026 guide to AI, smart-home sensors, remote monitoring, fall safety, privacy, and how technology can support aging in place without replacing care.

Pianificazione urbana basata sui dati: costruire città intelligenti, sostenibili e a misura di pedone

Pianificazione urbana basata sui dati: costruire città intelligenti, sostenibili e a misura di pedone

Scopri come le città possono trasformare i dati relativi a mobilità, uso del suolo, clima e comunità in quartieri più sicuri, più verdi e più vivibili, senza anteporre la tecnologia alle persone.

Dove studiare ingegneria dei droni nel 2026: i migliori programmi aerospaziali in base all'obiettivo di carriera

Dove studiare ingegneria dei droni nel 2026: i migliori programmi aerospaziali in base all'obiettivo di carriera

Confronta i principali programmi di ingegneria aerospaziale e UAV per droni, autonomia, sistemi di controllo, operazioni UAS e ricerca di dottorato, con aggiornamenti verificati fino al 2026.

Robotica chirurgica basata sull'intelligenza artificiale: una guida pratica alla precisione, all'autonomia e a ciò che accade realmente in sala operatoria.

Robotica chirurgica basata sull'intelligenza artificiale: una guida pratica alla precisione, all'autonomia e a ciò che accade realmente in sala operatoria.

Una guida pratica alla robotica chirurgica basata sull'intelligenza artificiale: capacità attuali, livelli di autonomia, vantaggi in termini di precisione, limiti, regolamentazione e criteri di valutazione.

Ampliamento dell'implementazione della cattura e utilizzo del carbonio (CCUS): la cattura del carbonio può davvero invertire le emissioni globali?

Ampliamento dell'implementazione della cattura e utilizzo del carbonio (CCUS): la cattura del carbonio può davvero invertire le emissioni globali?

Gli investimenti nella cattura e utilizzo del carbonio (CCUS) sono in aumento, ma la cattura del carbonio può davvero invertire le emissioni globali? Scopri dove funziona, quali sono i limiti di scala e quali sono le evidenze scientifiche rilevanti.

Where to Study Cross-Border Digital Supply Chain Management: 7 Programs to Compare

Where to Study Cross-Border Digital Supply Chain Management: 7 Programs to Compare

Compare seven global programs for digital supply chains, logistics, analytics, global trade, and operations, with practical guidance on choosing the right fit.

Dalla fantascienza alla realtà: come la tecnologia BCI sta restituendo mobilità e parola.

Dalla fantascienza alla realtà: come la tecnologia BCI sta restituendo mobilità e parola.

Scopri come le interfacce cervello-computer decodificano i segnali neurali per ripristinare la comunicazione e il movimento, quali risultati hanno ottenuto gli studi più recenti e cosa limita ancora l'utilizzo delle BCI.

Anatomia dei droni commerciali: innovazioni hardware e volo autonomo

Anatomia dei droni commerciali: innovazioni hardware e volo autonomo

Scopri come i droni commerciali combinano sensori, intelligenza artificiale edge, batterie, sistemi di comunicazione e software di controllo del volo, e in che modo l'autonomia dipende ancora dalla missione e dalle normative.

Where Should You Study Energy Storage Engineering? 7 Battery Tech Programs Compared

Where Should You Study Energy Storage Engineering? 7 Battery Tech Programs Compared

Compare seven strong battery and energy storage master's options by materials, systems, research, industry exposure, flexibility, language, and cost trade-offs.

Progettare il cielo: come i droni industriali possono superare i limiti di batteria e carico utile

Progettare il cielo: come i droni industriali possono superare i limiti di batteria e carico utile

Scopri come la massa del carico utile, i limiti della batteria, le condizioni meteorologiche, l'efficienza della propulsione e l'architettura del velivolo influenzano l'autonomia dei droni industriali e come migliorarla.