> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.userbot.ai/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.userbot.ai/_mcp/server. # Come gira un'esecuzione Un workflow che funziona in prova e si comporta in modo strano in servizio quasi sempre incontra uno dei limiti di questa pagina. Sono pochi, sono fissi, e sapendoli si progetta il flusso in modo che non li tocchi. ## Una alla volta Di uno stesso workflow gira **una sola esecuzione completa per volta**. Se ne parte un'altra mentre la prima è in corso, viene messa in coda e parte appena la precedente finisce. Nella pagina [Le esecuzioni](/esecuzioni-automazioni) un'esecuzione in attesa del suo turno risulta **In coda**. Nella cronologia del builder invece risulta **Esecuzione in corso**, come quella che sta girando: se ne vedi due e i passaggi si muovono solo in una, l'altra sta aspettando. Le prove sul singolo blocco seguono una regola separata: **Esegui solo questo nodo** non si mette in coda dietro un'esecuzione completa, ma non ne parte una seconda finché la prima non ha finito. ![Il pulsante Esegui solo questo nodo sull'intestazione di un blocco, evidenziato: la prova del singolo blocco non si mette in coda dietro un'esecuzione completa](/_fern-img/9d376dfc27531d831793a88ea766929fe287208cd9b66db00af1c887ded77dca.webp) > **Info** > > Un'esecuzione ferma su un'attesa (un modulo da compilare, un pulsante da > premere, un operatore, una **Pausa**) libera il posto, quindi non trattiene le > altre. Non scade da sola: resta lì finché qualcuno non risponde o la pausa non > finisce. ## I tempi massimi Sono fissi e non si configurano. | Cosa | Tempo massimo | Cosa succede oltre | | -------------------------------------------------------- | ------------- | ----------------------------------------------------------- | | Una chiamata **HTTP request** | 30 secondi | Il blocco fallisce | | Un invio con **Invia email** | 30 secondi | Il blocco fallisce | | Una **Ricerca web** | 45 secondi | Il blocco esce da **Errore** | | Una **Ricerca knowledge** o un'azione di un'integrazione | 90 secondi | Il blocco esce da **Errore**, o segue **In caso di errore** | | Un blocco **AI Core**, strumenti compresi | 180 secondi | Il blocco segue **In caso di errore** | | Un'esecuzione completa che resta in corso | 15 minuti | Viene chiusa come fallita | | Una prova su un singolo blocco | 2 minuti | Viene chiusa come fallita | I 15 minuti si contano da quando l'esecuzione è stata creata, quindi comprendono il tempo passato in coda e le attese. Il controllo non è continuo: un'esecuzione bloccata viene chiusa la volta dopo che qualcuno avvia quel workflow, prova un suo blocco o ne apre l'elenco delle esecuzioni. La risposta di una chiamata HTTP viene troncata a 256 KB. Se stai leggendo un elenco lungo, chiedi al sistema di paginare invece di scaricare tutto: oltre quel limite il corpo arriva tagliato, e un riferimento a un campo in fondo non trova niente. ## Niente ritentativi, niente annullamento Un passaggio che fallisce **non viene ritentato**. Il suo ramo si ferma e i blocchi a valle non girano. L'esecuzione risulta fallita solo se nessun ramo arriva in fondo: se un altro ramo finisce bene, risulta completata anche se una parte si è fermata. Dove la chiamata può fallire per motivi temporanei, la strada è la **Gestione errori** del blocco: **Aggiungi callback di errore** non ritenta, ma devia su un percorso di recupero che costruisci tu. → [I blocchi disponibili](/blocchi) ![La Gestione errori di un blocco HTTP con il menu In caso di errore aperto: Interrompi workflow, Continua con output di errore e Aggiungi callback di errore](/_fern-img/53a42e2f78e621af58e6f2bbf587443a6e430d910c19a3d3a22211bba4371ff9.webp) Non c'è nemmeno un modo di fermare un'esecuzione avviata. **Disattiva** impedisce gli avvii successivi, ma quelle in corso o in coda arrivano dove devono arrivare. Fanno eccezione i limiti di spesa del workflow, che possono interrompere un'esecuzione a metà. → [Costi e limiti](/costi-workflow) È la ragione per cui i destinatari veri si mettono per ultimi, e solo quando il resto funziona. ## Chiamare un altro workflow **Chiama workflow** avvia un secondo flusso e ne aspetta l'esito. Il workflow chiamato deve essere attivo e pubblicato, e gira la sua versione pubblicata. * **Profondità massima 5.** Un workflow che ne chiama un altro, che ne chiama un altro, e così via: oltre il quinto livello la chiamata viene rifiutata. * **Niente cicli.** Se il workflow che stai per chiamare è già più su nella catena, la chiamata viene rifiutata. Un workflow può richiamare se stesso una volta sola: A che chiama A va bene, A che chiama A che chiama A no. Se la chiamata fallisce, il flusso chiamante prosegue con l'errore registrato nel passaggio. Ogni workflow chiamato conta come esecuzione propria verso la quota mensile. → [Costi e limiti](/costi-workflow) ## Quale definizione gira Dipende da dove parte l'esecuzione, ed è la differenza che confonde di più. | Da dove parte | Cosa esegue | | ---------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------- | | Dal builder, con una prova del flusso o **Esegui solo questo nodo** | La bozza che hai sulla tela in quel momento | | Dall'indirizzo **Test** del webhook | La bozza salvata | | Dalla chat, da un agente, da un'attività schedulata, dall'indirizzo **Produzione** del webhook, da un evento di un'app, da **Chiama workflow** | La versione pubblicata | > **Warning** > > È il motivo per cui una correzione può funzionare nel builder e non cambiare > niente per i colleghi. Finché non pubblichi, tutti gli altri avvii usano la > versione vecchia. → [Pubblicare e monitorare](/pubblicare-workflow) ## Progettare tenendone conto * **Spezza le chiamate lente.** Se un sistema esterno impiega più di 30 secondi, chiedi l'avvio del lavoro con una chiamata, aspetta con **Pausa** e chiedi il risultato con una seconda chiamata. * **Non contare su un ritentativo.** Dove la chiamata può fallire, metti **Aggiungi callback di errore** e decidi tu cosa fare. * **Tieni le esecuzioni corte.** Il tetto dei 15 minuti vale per il flusso intero, attese comprese. Se ti serve aspettare più a lungo, spezza il lavoro in due workflow e collegali con **Chiama workflow**. * **Evita di far partire lo stesso workflow in raffica.** Con una sola esecuzione per volta, la coda cresce e il ritardo si accumula.