Building Blocks
Workflow
Il ciclo di vita di un ticket, configuration item o attività — una sequenza di stati più le regole su chi può passare da quale stato a quale.
Aggiornato il 23 gen 2026
Configurazione · Building Block · 3.6
Un workflow è un insieme di stati + le transizioni tra di essi + chi può eseguire quale transizione. Ogni ticket, ogni configuration item, ogni attività è collegato a un tipo, e il workflow dipende da quel tipo. Workflow ben progettati = un flusso di processo chiaro; mal progettati = “quindi qual è davvero lo stato di questo ticket?”.
Perché è importante per il business
"Nessuno sa quando qualcosa è fatto"
Nomi di stato che il business comprende — non "Stato 3" o "In revisione".
"Tutti chiudono ogni ticket"
Le transizioni sono specifiche per ruolo — solo i manager possono chiudere, gli operatori possono risolvere.
"L'approvazione vive in un Excel"
Lo stato di approvazione all'interno del workflow stesso — incluso chi può approvare e cosa viene dopo.
"Flusso diverso per tipo"
Un incident ha passaggi diversi da una richiesta di accesso — ciascuno ha il proprio workflow.
Il meccanismo
Tipo
Tipo di ticket, tipo di CI o tipo di attività. Decide quale workflow si applica a un record.
Stati
Le fasi attraverso cui passa un record. Un nuovo tipo arriva con quattro stati predefiniti (vedi sotto).
Transizioni
I passaggi consentiti tra stati, più quali gruppi di autorizzazione sono autorizzati ad eseguirli.
I quattro stati predefiniti
Per ogni nuovo tipo di ticket, CI o attività Gfacility crea automaticamente quattro stati:
| Tipo di stato | Ruolo |
|---|---|
| Stato predefinito | Punto di partenza. Ogni nuovo record arriva qui automaticamente. |
| Stato di approvazione | In attesa di approvazione. Facoltativo ma utile per i flussi change/finance. |
| Stato di annullamento | Ritirato dal richiedente — non è lo stesso che rifiutato. |
| Stato di rifiuto | Rifiutato dall'operatore/approvatore. Stato finale. |
Oltre a questi quattro può aggiungere liberamente i propri stati (In corso, Pianificato, Bloccato, In attesa del cliente, Risolto, Verificato, …). Ogni stato ha il proprio colore del testo e del background per il riconoscimento visivo.
Quali decisioni prenderà?
Quanti stati per tipo?
Si consigliano 5-7. Di più = confusione; di meno = troppo grossolano per il reporting.
Quali transizioni sono consentite?
Bloccato → Risolto è aperto a tutti, ma Verificato → Riaperto solo al segnalatore.
Quale gruppo può eseguire quale transizione?
Discende direttamente dalla RACI: chi è la "A" per un passaggio può eseguire la transizione allo stato successivo.
Un workflow o uno per tipo?
Se i processi differiscono significativamente → workflow separato. Altrimenti un workflow con varianti tramite campi personalizzati.