Cambia il processo senza rompere il lavoro in corso.
Ogni versione pubblicata è una fotografia immutabile. Prima di andare in produzione, FlowSharp verifica che il processo possa davvero finire.
- Per
- Process owner
- IT
- Compliance
Il problema
In molti strumenti modificare un workflow significa modificarlo per tutti, anche per le pratiche già avviate. Oppure si scopre in produzione che un ramo non ha uscita e le pratiche restano bloccate per sempre. E quando un auditor chiede "con quale versione del processo è stata gestita questa pratica?", la risposta non c'è. Il processo diventa così qualcosa che nessuno osa toccare: ogni miglioria è un rischio, ogni correzione urgente va fatta a mani nude sul sistema vivo, e la storia delle modifiche si ricostruisce a memoria. FlowSharp separa il lavoro di progettazione da quello di esecuzione: si progetta su una bozza, si controlla prima di pubblicare e ogni versione pubblicata resta quella che era.
v1
Archiviata
v2
Pubblicata
v3
Bozza
Come funziona
- 1
Una sola bozza per famiglia
Lavori sulla bozza mentre la versione pubblicata continua a girare. Modificare una versione pubblicata crea automaticamente una nuova bozza, così non c'è modo di toccare per errore ciò che è in produzione.
- 2
Controlli prima della pubblicazione
FlowSharp verifica che esista almeno un finale raggiungibile e che non ci siano trappole, cioè fasi non finali da cui non si esce. Considera tutti i canali: scelta umana, regole, timeout, WIP, iterazioni, eventi, SLA. Controlla anche timeout senza destinazione, script non sicuri e automazioni senza via d'uscita.
- 3
Avvisi navigabili
Ogni problema ha "Vai allo stato", che porta direttamente al punto da correggere sul canvas. Se il pulsante Pubblica è disattivato, dice perché: non resta mai un blocco senza spiegazione.
- 4
Le pratiche restano sulla loro versione
Le nuove pratiche usano la nuova versione; quelle in corso finiscono il percorso con la versione con cui sono nate. Il lavoro già avviato non cambia regole a metà strada.
Specifiche
| Stati di ciclo di vita | Bozza · Pubblicato · Non pubblicato · Disabilitato · Archiviato |
|---|---|
| Controlli di terminazione | finale raggiungibile, assenza di trappole non finali, fallback delle automazioni |
| Altri controlli | timeout con destinazione, niente auto-loop, lint di sicurezza degli script |
| Diagnostica post-pubblicazione | task non validi, con sanatoria automatica all'avvio e ogni ora |
| Co-progettazione | controllo di revisione: nessuna sovrascrittura silenziosa |
| Portabilità | export flowsharp.flow/v2, import come nuova versione in bozza |
Un esempio operativo: tre versioni dello stesso flusso
Un flusso ha una v1 archiviata, una v2 pubblicata con 128 pratiche in corso e una v3 in bozza (valori illustrativi). Il team lavora sulla v3 senza interferire con le 128 pratiche della v2, che continuano a seguire le regole con cui sono nate. Quando la v3 è pronta, si avvia la pubblicazione. I controlli verificano che lo stato finale sia raggiungibile, che non ci siano trappole, cioè stati senza uscita, e segnalano le anomalie, per esempio un timeout senza destinazione: in quel caso la correzione è impostare Vai allo stato. Solo a controlli superati la v3 diventa la versione pubblicata e la v2 passa nel ruolo di versione precedente. Lo schema mostra questa linea del tempo con il ramo di bozza accanto alla versione pubblicata, in forma schematica e non come schermata ufficiale. Il vantaggio è poter cambiare un processo vivo senza rompere il lavoro già avviato.
Come verificare una pubblicazione
Dopo la pubblicazione controlla tre cose. Primo, che la versione indicata come pubblicata sia quella attesa e che la precedente risulti archiviata o in uso solo per le pratiche già avviate. Secondo, che i controlli di pubblicazione non abbiano segnalato avvisi ignorati: un avviso su un timeout senza destinazione, per esempio, è il tipo di dettaglio che conviene chiudere prima, non dopo. Terzo, che le nuove pratiche nascano sulla versione nuova mentre quelle in corso proseguano sulla vecchia, così nessuno lavoro cambia regole a metà strada. Per la governance, ogni pubblicazione lascia una traccia con la versione e la persona che l'ha eseguita, utile quando un revisore chiede da quando una regola è in vigore. Se qualcosa non va, la versione precedente resta consultabile e si può preparare una nuova bozza correttiva senza perdere la storia.
Funzionalità collegate
- Designer visuale dei flussiUn canvas dove le fasi sono nodi e le transizioni sono collegamenti, con tutto il dettaglio nel pannello laterale.
- Export/import portabile dei flussiFormato aperto JSON con verifica preventiva "tutto o niente".
- Storico immutabile e audit atomicoLo storico delle pratiche è write-once, protetto a livello di database.
- Versioni della mappa con racconto delle differenzeDa bozza a pubblicata a nuova versione con nota, e un confronto descritto in linguaggio naturale.
- Condividi con link temporaneoUn link pubblico a una fotografia del flusso, con scadenza da 30 minuti a 30 giorni.
Casi d'uso
Domande frequenti
Posso modificare un flusso mentre è in uso?
Sì: lavori su una bozza, e le pratiche in corso non cambiano.
Cosa succede alle pratiche vecchie quando pubblico?
Proseguono con la loro versione. Il Kanban fonde le colonne omonime e mostra il badge di versione.
Due persone possono lavorare sullo stesso flusso?
Sì, con protezione dalle sovrascritture: in caso di conflitto le modifiche locali vengono conservate.
Posso tornare indietro?
Le versioni precedenti restano consultabili; puoi ripubblicarle o crearne una nuova a partire da esse.