Pubblicare e monitorare
Un workflow che stai costruendo non gira per nessuno. Serve un passaggio esplicito per farlo entrare in servizio: la pubblicazione. È voluto, e significa che puoi mettere mano a un flusso attivo senza il timore di rompere quello che sta girando.
Bozza e versione pubblicata
Ogni workflow ha due facce.
La bozza è quello che vedi nel builder. Si salva da sola mentre lavori e non ha effetto su chi avvia il flusso da fuori: puoi spostare blocchi, cambiare condizioni, provare un’altra strada.
La versione pubblicata è la fotografia che il workflow esegue quando parte dalla chat, da un agente, da un’attività schedulata, da un webhook di produzione o da un evento di un’app. Resta ferma finché non ne pubblichi una nuova, anche se nel frattempo la bozza è cambiata dieci volte.
Le prove dentro il builder sono l’eccezione: fanno girare la bozza che hai sotto gli occhi. È comodo mentre costruisci, e va ricordato quando provi una correzione e la vedi funzionare: finché non pubblichi, tutti gli altri stanno ancora usando la versione vecchia. → Come gira un’esecuzione
Pubblicare
Rileggi il flusso dall'inizio
Guarda destinatari, identificativi e i rami che non hai mai provato. Se durante le prove avevi messo il tuo indirizzo al posto di quello vero, è adesso che va rimesso a posto.
Apri Pubblica
Il pannello mostra il numero della Nuova versione e l’elenco delle Modifiche rispetto all’ultima pubblicata. Se leggi Nessuna modifica rispetto all’ultima versione pubblicata, la bozza e la versione in servizio coincidono già.
Serve esattamente un trigger attivo. Se manca, il pannello dice Aggiungi un Trigger attivo prima di pubblicare.; se ce n’è più d’uno, ti chiede di disattivarli tutti tranne uno.
Le modifiche alle sole Impostazioni del workflow (destinatari degli avvisi, limiti di spesa) non contano fra le Modifiche: da sole non accendono Pubblica. Entrano in servizio con la prossima pubblicazione che contiene anche una modifica al flusso. → Costi e limiti
Disattivare e riattivare
Disattiva e Attiva stanno in Opzioni workflow, il menu accanto al titolo. Disattivare spegne il flusso senza perdere nulla: definizione, versioni e storico restano, e nessun nuovo avvio parte. Le esecuzioni già in corso o in coda arrivano comunque in fondo.
È la cosa da fare quando un flusso sta producendo risultati sbagliati e non hai ancora capito perché: molto meglio che smontarlo mentre gira. Ricorda che pubblicare una nuova versione lo riattiva.
Attiva su un workflow mai pubblicato non basta: ti chiede di pubblicare prima una versione.
Tornare a una versione precedente
Versioni precedenti, il pulsante con l’icona accanto a Pubblica, elenca tutte le versioni con il loro stato: Pubblicata quella in servizio, Sostituita quelle che l’hanno preceduta, Bozza quella su cui stai lavorando. Ognuna riporta la descrizione scritta al momento di pubblicarla.
Per ogni versione hai due comandi.
- Anteprima apre quella versione sulla tela, in sola lettura, con l’avviso Stai vedendo la versione v…. Da lì Impostalo la copia nella bozza (dopo una conferma, perché sostituisce la bozza attuale) e Annulla anteprima torna dove eri.
- Pubblica rimette in servizio quella versione così com’è, senza passare dalla bozza.
Nessuno dei due cancella niente: le altre versioni restano nell’elenco e puoi tornarci allo stesso modo.
Lo storico delle esecuzioni
Esecuzioni passate apre la Cronologia del workflow: ogni giro, dal più recente, con l’esito, l’origine e il momento in cui è partito. In cima trovi i totali di esecuzioni e costo; i filtri separano Da conversazione, Builder, Play (le prove sul singolo blocco) e Webhook. Aprendone una vedi lo stato per esteso e la versione che ha girato.
Per vedere tutte le esecuzioni dell’area di lavoro insieme, anche delle attività schedulate, c’è la pagina Le esecuzioni.
Leggere un fallimento
Aprendo un’esecuzione vedi la traccia: i passaggi in ordine, ciascuno con la sua durata e il suo costo. Il passaggio fallito riporta il messaggio di errore, e cliccandolo vedi il suo Output. Se un’esecuzione è partita da una chat, Apri conversazione ti porta lì; se è partita da un webhook, trovi il Payload ricevuto.
Leggi l'errore del passaggio fallito
Un riferimento che non trova il dato lo dice, con il percorso che cercava. Una chiamata HTTP fallita riporta la risposta del sistema chiamato. → La sintassi dei riferimenti
Risali all'Output del passaggio precedente
Confrontalo con quello che il riferimento si aspettava. Nella maggior parte dei casi il dato c’era, ma in una forma diversa: un elenco invece di un valore, un campo assente in quel caso specifico.
Controlla se il flusso ha imboccato il ramo giusto
Un flusso che finisce senza fare niente quasi sempre non è fallito. Guarda quali rami ha percorso: una Condizione senza rami veri si ferma lì senza errori, e il blocco Codice non esegue il codice durante le esecuzioni. → I blocchi disponibili
Fatti aiutare, se vuoi
Sul passaggio fallito, Chiedi all’AI apre la chat di Crea con l’AI con l’errore già descritto e ti propone una correzione da applicare alla bozza. → Costruire un workflow
Un’esecuzione In attesa umana non è un errore, ma nemmeno finita: resta aperta finché qualcuno non interviene, senza scadere da sola. Il timeout di Scala ad umano non è ancora attivo, quindi non contare su quello per sbloccarla. Se ti capita spesso, rivedi il punto in cui il flusso si ferma.
Farsi avvisare
Nelle Impostazioni del workflow, alla voce Notifiche, indichi chi deve ricevere gli Errori e avvisi sul budget. Gli indirizzi ricevono un’email quando un’esecuzione fallisce, quando la spesa del mese supera una soglia di avviso e quando scatta un limite. È la differenza fra accorgersi di un flusso rotto il giorno stesso e accorgersene a fine mese.
Metti almeno due destinatari, e non solo chi ha costruito il workflow.