Flow & Workflow

Flow & Workflow è il motore di automazione e orchestrazione dei processi al centro di Nashua 360. Governa un problema aziendale inevitabile: il lavoro non resta all'interno di un'unica schermata, quindi i ticket devono essere instradati, le fatture approvate, i contratti in scadenza segnalati e i cambi di stato notificati. Lasciata ai singoli moduli, quella coordinazione si frammenta in regole cablate nel codice e solleciti via posta. Un designer visuale consente ai responsabili aziendali di modellare i processi come trigger, condizioni, azioni e approvazioni, sostenuto da un event bus esteso all'intera suite, trasformando un insieme di moduli robusti in un sistema operativo coordinato per l'azienda.

Cosa fa il motore

Flow & Workflow fornisce un toolkit completo e no-code per l'automazione dei processi. Al suo cuore c'è un designer visuale di flussi in cui i processi vengono disegnati come un grafo di nodi uniti da archi: un trigger avvia il flusso, i nodi condizione lo instradano, i nodi azione svolgono il lavoro, i nodi di approvazione e notifica coinvolgono le persone, i nodi di ritardo trattengono l'esecuzione fino a un momento prescelto, i nodi webhook raggiungono i sistemi esterni e un nodo finale chiude l'esecuzione. I flussi vengono attivati in tre modi: da un evento su un qualsiasi record, secondo una pianificazione ricorrente oppure su richiesta da parte di una persona o di un AI Worker.

I nodi azione coprono le operazioni di cui un processo aziendale ha realmente bisogno: invio di email, creazione o aggiornamento di record in qualsiasi modulo, chiamata di un servizio registrato attraverso la piattaforma, invio a un endpoint esterno e generazione di notifiche in-app. La diramazione condizionale consente a un unico flusso di gestire ogni percorso che un caso può seguire, così che un solo progetto assorba le eccezioni invece di generare varianti. Un form builder integrato acquisisce gli input richiesti da un trigger manuale o da una decisione di approvazione, mentre i timer SLA vincolano ogni fase alla propria scadenza, effettuando escalation automatiche quando un passaggio si prolunga. Il risultato è che un processo che prima viveva nella testa di qualcuno, o disperso in una catena di email, diventa un asset esplicito, versionato e osservabile che l'azienda possiede e può modificare in pochi minuti.

Il dominio e il modello dati

Il modello concettuale è ridotto, e lo è deliberatamente: è proprio questo che lo rende universale. L'oggetto centrale è il flow: una descrizione denominata e autoconsistente di come un'attività debba procedere. Un flow è espresso come un grafo. I suoi passaggi sono i singoli elementi di comportamento, ciascuno con un proprio tipo e una propria configurazione, e le connessioni tra di essi trasportano la logica che decide quale passaggio segue quale altro, comprese le condizioni che devono verificarsi affinché un determinato percorso venga intrapreso. Poiché la forma di un processo è dato e non codice, un flow può essere ispezionato, copiato, affinato e analizzato senza toccare la piattaforma stessa.

Ogni volta che un flow viene messo in moto, il motore crea un run: un'istanza attiva con una propria memoria. Il run registra il punto in cui si trova attualmente l'esecuzione, trasporta il contesto raccolto lungo il percorso, l'input che lo ha avviato e l'output prodotto da ciascun passaggio, e mantiene il proprio stato dal momento in cui inizia fino al momento in cui si completa, si sospende o fallisce. Questa separazione tra la progettazione di un processo e le sue singole esecuzioni è l'idea chiave. Un solo flow può avere migliaia di run in corso, ciascuno sul proprio percorso, ciascuno riprendibile in modo indipendente dopo un'approvazione o una pausa pianificata. Accanto a questi si colloca l'approval workflow, una policy riutilizzabile che stabilisce, per un dato tipo di record e un dato insieme di condizioni, chi debba dare l'assenso e in quale ordine. La policy di approvazione è quindi definita una sola volta e applicata in modo coerente, invece di essere ridefinita all'interno di ogni flow che necessita di una decisione.

Workflow principali

Tre pattern coprono la maggior parte di ciò che le organizzazioni costruiscono. Il primo è l'automazione basata sugli eventi: un autore progetta un flow, sceglie l'evento del record che dovrebbe avviarlo, come la creazione di un caso o il cambiamento di uno stato, e definisce le azioni e le diramazioni che ne conseguono. Da quel momento il motore osserva il bus di eventi e attiva un run corrispondente nell'istante in cui l'evento si verifica, senza intervento umano. Il secondo è l'instradamento delle approvazioni: un flow raggiunge un nodo di approvazione, il motore crea una richiesta di approvazione, mette in pausa il run e notifica gli approvatori responsabili. Approvazioni a più passaggi, parallele e con escalation condizionale sono tutte esprimibili qui, così che una richiesta di basso valore possa essere risolta con una sola firma mentre una di alto valore percorra diversi livelli, il tutto a partire dallo stesso progetto.

Il terzo pattern è l'elaborazione pianificata: flow associati a una pianificazione cron vengono eseguiti a orari prestabiliti per gestire attività periodiche come promemoria, rinnovi, riconciliazioni e operazioni di manutenzione. Uno scheduler principale valuta ogni minuto i flow in scadenza, riprende gli eventuali run il cui ritardo è trascorso e previene esecuzioni duplicate all'interno della stessa finestra. In tutti e tre i casi, ogni run è completamente tracciato. Gli operatori possono vedere quali flow sono attivi, seguire un run nodo per nodo, leggere il contesto che ha trasportato e comprendere esattamente perché un determinato percorso è stato scelto e dove si è verificato un errore.

TriggerEvaluateconditionsExecute nodesComplete run
An event or schedule starts a run, the engine routes it through conditions, and nodes execute the work until completion.

Profondità funzionale che conta

La precisione di un motore di processi risiede nella sua logica di instradamento, ed è qui che Flow & Workflow non scende a compromessi. Il valutatore di condizioni supporta un ricco insieme di operatori che comprende uguaglianza e disuguaglianza, confronto numerico, test sulle stringhe come contains, starts-with, ends-with e pattern matching, appartenenza a insiemi con in e not-in e verifiche di presenza per stabilire se un campo esista affatto. Le condizioni si compongono: qualsiasi gruppo può essere combinato con gli operatori logici and, or e not per esprimere regole arbitrariamente sfumate, e i valori vengono letti tramite dot-path in modo che i campi profondamente annidati del record in valutazione siano direttamente indirizzabili. Gli archi vengono valutati in un ordine definito con la regola del first-match-wins, garantendo ogni volta una diramazione deterministica e verificabile.

L'esecuzione stessa è regolata per sicurezza e prevedibilità. Ogni run avanza passo dopo passo con il proprio stato persistito a ogni movimento, così che un run sopravviva a un'interruzione e riprenda in modo pulito. Un limite massimo di passaggi previene flow fuori controllo o ciclici. I nodi webhook che raggiungono l'esterno della piattaforma sono protetti contro la server-side request forgery e vincolati a un timeout rigoroso, così che una dipendenza esterna non possa bloccare un processo. Il catalogo del bus di eventi pubblica ogni evento che la piattaforma è in grado di emettere, con nomi in notazione a punti e sottoscrizione con wildcard, così che un flow possa mettersi in ascolto di un evento preciso o di un'intera famiglia di eventi. Le pause di ritardo e di approvazione sono stati terminali di prima classe, non soluzioni di ripiego: è proprio questo che consente a processi di lunga durata, con l'uomo nel ciclo, di eseguire per giorni senza tenere occupate le risorse.

Come si inserisce nella suite Nashua 360

Flow & Workflow è il livello di automazione su cui ogni altro modulo si fonda, e conquista quella posizione grazie a un'integrazione profonda e nativa anziché tramite connettori. Attinge direttamente dal service bus della piattaforma, così che qualsiasi nodo azione possa invocare una capacità registrata da un altro modulo senza cablaggi ad hoc. Dispaccia attraverso la Notification Engine condivisa, così che i messaggi di un flow raggiungano gli utenti in-app e via email attraverso lo stesso canale usato dal resto della suite. Viene eseguito insieme alla pipeline ETL sulla pianificazione principale, così che i flow pianificati e il movimento dei dati siano coordinati su un unico orologio.

Poiché il bus di eventi trasporta gli eventi del ciclo di vita da tutta la suite, il modulo di fatto collega tutto insieme. Una modifica nel CRM può aprire un caso in Service Management. Una richiesta di acquisto approvata in Procurement può creare un record in Finance. Un accordo in scadenza in Contract Management può avviare una revisione per il rinnovo e notificare il responsabile del cliente. Una nuova assunzione in HR può attivare un flow di onboarding che predispone gli accessi e pianifica le attività. L'identità e i permessi vengono rispettati in ogni fase, così che un flow operi entro le stesse regole di accesso delle persone che serve. Flow & Workflow non affianca la suite: è il meccanismo grazie al quale la suite si comporta come un unico sistema.

Come operano gli AI Worker al suo interno

Gli AI Worker sono partecipanti di prima classe in Flow & Workflow, trattati dal motore come utenti a pieno titolo. Attraverso la conversazione, una persona può chiedere a un Worker di spiegare cosa fa un flow, perché una determinata esecuzione ha seguito quel percorso o quali processi toccano un dato record, e il Worker risponde interrogando i dati di flow e di run del modulo stesso. I Worker inoltre agiscono: progettano e modificano i flow a partire da intenti espressi in linguaggio naturale, avviano run, riprendono quelli in pausa e reinstradano il lavoro quando le circostanze cambiano, sempre entro i permessi loro concessi.

La loro portata si estende a ogni tipo di nodo. Un AI Worker monitora i run alla ricerca di anomalie ed eccezioni, portando alla luce un'approvazione bloccata, uno SLA violato o un picco di errori prima che diventi un problema. Laddove un flow necessiti di informazioni chiuse in un documento o in un payload non strutturato, un Worker le estrae e le struttura affinché le condizioni a valle possano operare su dati puliti. Cosa più significativa, un Worker può fungere esso stesso da nodo di approvazione o di revisione: il motore mette in pausa il run, il Worker valuta la richiesta rispetto alla policy e al contesto e o decide entro il proprio mandato o effettua l'escalation verso una persona con una raccomandazione chiara e il proprio ragionamento allegato. Questo trasforma Flow & Workflow da pura automazione a genuino supporto decisionale, riservando il giudizio umano ai casi che ne hanno davvero bisogno.