FlowSharp - Items, Task e lavoro operativo

Dopo il disegno del Flow arriva il lavoro quotidiano: item reali, task, persone, dati, transizioni, storico e responsabilita.

1. Dalla definizione del Flow all'esecuzione reale

Il Flow e' il modello. L'item e' la pratica reale che attraversa quel modello.

Questa distinzione e' essenziale:

• il Flow dice come dovrebbe funzionare il processo;
• l'item mostra cosa sta accadendo in questo caso specifico;
• i task indicano cosa deve essere fatto ora;
• la timeline racconta cosa e' successo prima;
• le transizioni mostrano cosa puo' succedere dopo.

In FlowSharp il processo non resta un diagramma: diventa lavoro tracciato.

2. Items: le pratiche in corso

Un item puo' rappresentare un ordine, una richiesta cliente, un contratto, un ticket, una pratica amministrativa, una commessa o qualsiasi entita che deve attraversare un processo.

La lista Items consente di:

• filtrare per flow, stato, assegnatario, periodo e ricerca testuale;
• passare tra viste operative;
• esportare dati;
• creare nuovi item quando il Flow lo consente;
• aprire una quick view o il dettaglio completo.

3. Dettaglio item e timeline

Il dettaglio item mostra:

• stato corrente;
• dati dell'item;
• task attivi;
• transizioni disponibili;
• origine dell'item;
• item correlati;
• storico completo;
• eventuali esecuzioni o automazioni collegate;
• mappa del Flow;
• badge operativi: motivo di stato, coda WIP, priorita'.
• punteggio, esito finale e un eventuale avviso di deviazione dal percorso ideale.

L'obiettivo e' permettere a un operatore di capire cosa e' successo, cosa deve fare ora e cosa puo' succedere dopo.

4. Task come unita di lavoro

La pagina Tasks e' pensata per chi deve fare o monitorare lavoro operativo.

Permette di:

• vedere task pendenti, in corso, completati, falliti o saltati;
• filtrare per flow, tipo, stato, testo e "solo i miei";
• passare tra vista tabella, kanban e calendario;
• aprire il dettaglio del task;
• completare task manuali;
• inserire outcome, note, feedback e rating;
• riprovare task automatici quando previsto.

Questa area rende FlowSharp utile come workbench operativo, non solo come motore dietro le quinte.

5. Human-in-the-loop

Il lavoro umano non e' un'eccezione da tollerare: e' parte del disegno del processo.

FlowSharp permette di governare:

• approvazioni;
• controlli qualita;
• verifiche documentali;
• decisioni di responsabilita;
• escalation;
• richieste di integrazione dati;
• feedback su output AI;
• attivita di chiusura.

Un task manuale puo' essere assegnato, completato, commentato e misurato. Se e' bloccante, il processo aspetta. Se non e' bloccante, puo' convivere con automazioni in background.

Questo rende chiaro dove serve una persona, perche' serve e quanto pesa quel passaggio nel processo complessivo.

6. Origine, correlazioni e handoff

Quando un item nasce da un evento, da un altro item, da API o da automazioni, FlowSharp mostra l'origine in modo leggibile.

Gli item correlati aiutano a vedere piu' pratiche collegate alla stessa entita: per esempio una richiesta commerciale che genera una commessa e poi un processo di fatturazione.

Gli handoff diventano piu' chiari perche' non vivono piu' solo in una chat o in una email: sono passaggi tracciati, con stato, responsabilita e storico.

7. Eventi tra processi

Gli eventi sono il modo in cui FlowSharp collega parti diverse di un processo.

Un evento puo':

• essere generato da un task;
• avviare un altro Flow;
• notificare un sistema esterno;
• correlare item tra loro;
• rappresentare un segnale proveniente da un altro sistema.

Gli eventi permettono a piu' Flow di collaborare senza trasformare tutto in un unico processo enorme.

8. Workbench operativo

Items e Tasks insieme formano il workbench operativo.

Per un operatore significa:

• sapere cosa fare ora;
• vedere le pratiche assegnate;
• capire le priorita;
• completare attivita senza cercare informazioni altrove;
• lasciare traccia di outcome e note.

Per un responsabile significa:

• vedere carichi e blocchi;
• individuare task falliti o in ritardo;
• capire dove serve rinforzo umano;
• distinguere lavoro ripetitivo da lavoro decisionale.

9. Cosa cambia per i team

FlowSharp sposta il lavoro da "seguire il processo a memoria" a "lavorare dentro un processo visibile".

Questo riduce:

• dipendenza da email e fogli;
• passaggi non tracciati;
• ricerche manuali di stato;
• decisioni prese senza contesto;
• automazioni scollegate dal lavoro umano.

E aumenta:

• responsabilita;
• audit;
• coordinamento;
• misurabilita;
• capacita di miglioramento continuo.

10. Code WIP, motivo di stato e visibilita per ruolo

Quando un flow usa i limiti WIP (vedi la guida "Flow e designer"), la coda diventa visibile e operabile direttamente nel lavoro quotidiano.

Sul dettaglio item:

• un badge "motivo di stato" spiega perche' l'item si trova nella fase corrente (scaduto per timeout, max iterazioni raggiunte, deviato dal WIP, ecc.);
• un badge "In coda WIP" indica che l'item attende capacita, con la posizione in coda;
• quando la fase lo consente, un pulsante permette a un Amministratore di forzare l'ingresso oltre il limite, con motivazione obbligatoria;
• se una fase in modalita' "solo warning" supera il limite, gli item ammessi mostrano il badge "Oltre limite WIP".

Sulla board (Monitor):

• ogni item in attesa mostra il badge "In coda WIP" e una targhetta priorita' P{n};
• nella vista Kanban gli item in coda per capacita scendono sotto un separatore dedicato, distinti da quelli realmente in lavorazione;
• un filtro "In coda WIP" isola con un click tutto cio' che e' parcheggiato in attesa di capacita.

Visibilita per ruolo: gli utenti Operator e ReadOnly vedono solo i flow dove possono davvero operare — flow pubblicati avviabili dal loro ruolo o flow dove hanno (o hanno avuto) un item. La regola vale su tutte le viste: lista flow, item, storico, attivita e Process Maps. Admin e FlowDesigner continuano a vedere tutto.

11. Qualita del percorso e interventi eccezionali

Un item non racconta solo dove si trova: racconta anche come ci e' arrivato. Quando un Flow ha un percorso ideale, il dettaglio e il Monitor segnalano le pratiche deviate. La timeline conserva il passaggio che ha generato l'avviso, insieme alle normali transizioni e alle variazioni di punteggio.

Questo aiuta il team a separare tre situazioni diverse:

• una pratica in ritardo o in coda WIP, che aspetta capacita;
• una pratica deviata, che ha seguito un percorso non atteso ma continua a essere governata;
• una pratica bloccata in una fase di eccezione, che richiede un'azione prevista dal processo o uno sblocco autorizzato.

Quando serve rimediare a un caso realmente incastrato, un Amministratore puo' eseguire un cambio di stato forzato all'interno dello stesso Flow. Non sostituisce le regole quotidiane: e' una misura di continuita' operativa, riconoscibile nello storico dell'item.

12. Liste operative, colonne e viste per flusso

Le liste lavorano sull'intero archivio lato server: ricerca, stato, periodo e altri filtri non si fermano agli elementi gia' caricati. Task ed Eventi usano Carica altri con un cursore stabile, cosi inserimenti o eliminazioni concorrenti non fanno saltare o ripetere righe.

Nella tabella di un singolo Flow, il bottone Colonne permette di scegliere:

• colonne operative fisse;
• campi dichiarati nel registro del Flow, con la loro etichetta;
• campi osservati, segnalati come tipo inferito.

Numeri, booleani, oggetti e valori assenti vengono resi secondo il tipo. L'ordinamento avviene sul server su tutti gli item, non solo sulla pagina aperta. Chi progetta il Flow puo' salvare la disposizione come vista del team; ogni utente puo' mantenere un override personale e tornare alla vista condivisa. Un campo rimosso dal registro resta riconoscibile come mancante senza rompere la tabella. I campi sensibili restano mascherati per il ruolo ReadOnly e non sono ordinabili da quel ruolo.

La pagina Tutti gli Item offre anche export CSV sul Flow selezionato e calendario per data di avvio, pianificazione, scadenza o completamento. Se il campo data scelto non e' presente nel periodo, il calendario passa alla data di avvio e lo dichiara invece di mostrare una vista vuota.

Quando due persone modificano contemporaneamente i dati dello stesso item, il secondo salvataggio basato su una revisione superata viene fermato. La vista ricarica i dati piu' recenti, evitando che una modifica operativa cancelli l'altra in silenzio.

13. Note e Sintesi AI dell'item

Dal dettaglio si puo' aggiungere una nota umana: entra nella timeline e resta parte dell'audit della pratica. Il JSON dei dati puo' essere copiato direttamente per un controllo o un passaggio verso un'integrazione.

Quando la funzione e' abilitata, la scheda Sintesi AI presenta:

• un giudizio sintetico sullo stato dell'item;
• un livello leggibile, per esempio bene, attenzione o critico;
• poche frasi basate su dati, storia, note e punteggio.

La sintesi viene rigenerata in background quando l'item cambia stato e puo' essere aggiornata manualmente. Si puo' disattivare a livello di organizzazione, Flow o singola fase. Se il provider usa Data Shield, i campi sensibili vengono schermati prima della chiamata AI. La stessa sintesi e' disponibile al Flow Agent e, con i permessi corretti, al tool MCP che legge l'item.

14. Procedure operative e guide dei task

La pagina Procedure porta SOP, mansionari e istruzioni dentro il lavoro operativo. Ogni procedura ha versioni immutabili, autore, nota di modifica e impronta del contenuto. Il testo puo' essere scritto in Markdown oppure estratto da un PDF; i titoli diventano sezioni citabili.

Nel designer, una guida task puo' indicare la procedura, la versione e la sezione da cui deriva. Quando nasce una nuova versione della SOP:

• i collegamenti alle versioni precedenti vengono segnalati come da riallineare ad Admin e FlowDesigner;
• la pagina della procedura mostra copertura per Flow e task;
• il designer puo' verificare la guida e segnalarla come allineata alla versione corrente;
• l'operatore continua a vedere la guida e la citazione della fonte, senza gli avvisi di manutenzione.

La generazione premium propone guide a partire dalla procedura, ma richiede sempre revisione e conferma umana prima di applicarle. I collegamenti SOP restano negli export/import, nei template e nelle nuove versioni dei Flow.

Una procedura si puo' archiviare e ripristinare. L'eliminazione definitiva e' riservata agli Admin, richiede una conferma forte ed e' possibile solo quando la procedura archiviata non e' piu' collegata.

Per un'esigenza non prevista dal modello, i ruoli autorizzati possono anche aggiungere dal dettaglio item un task manuale ad hoc, scegliendo se deve bloccare il percorso. Il task resta limitato a quella pratica ed entra nello stesso storico degli altri task.

15. Alerting multicanale e presa in carico

Le policy di notifica governano il lavoro umano che resta in attesa. Una policy contiene step temporali e puo' usare email, webhook o evento; il Flow puo' usare la policy predefinita dell'organizzazione oppure una dedicata.

Per ridurre il rumore:

• gli avvisi per lo stesso destinatario possono essere raggruppati in un digest;
• le fasce orarie consentite rispettano il fuso dell'organizzazione e l'ora legale;
• email e webhook fuori fascia vengono rinviati, mentre le notifiche in-app restano immediate.

Il destinatario puo' prendere in carico l'avviso dalla campanella o da un link firmato ricevuto via email/webhook. Completare il task o far avanzare l'item risolve automaticamente l'attesa. In Gestione → Notifiche, gli Admin consultano anche i tempi di presa in carico e risoluzione.

Un Flow puo' essere escluso da Dashboard e Analytics quando rappresenta lavoro tecnico o di test. Puo' inoltre definire una retention per gli item completati: alla scadenza lo storico viene eliminato definitivamente, quindi la policy va scelta in base agli obblighi operativi e di conservazione.

16. Alert per automazioni ferme

Quando un item resta in uno stato Auto/AI per NO_RULES, NO_MATCH_NO_DEFAULT, ALL_RULES_ERROR o AI_EXECUTION_FAILED, FlowSharp crea un solo alert persistente AutomationStalled per item e stato. Gli Admin attivi del tenant ricevono l'alert secondo la policy del flusso e possono prenderlo in carico come gli altri alert.

L'alert si risolve quando l'item lascia lo stato che lo ha generato. Non va confuso con lo stallo statistico della Process Map: il primo descrive una causa runtime puntuale, il secondo un segnale calcolato sull'andamento del processo.

Il recupero eccezionale richiede un Admin e una motivazione. La forzatura REST e il tool MCP force_transition usano lo stesso servizio; saltano consapevolmente adiacenza e WIP, chiudono i task abbandonati e registrano l'audit. transition_item resta il canale ordinario e non accetta bypass.