Alcuni processi generano sempre un ticket derivato - e ogni volta che la fase viene dimenticata, il processo fallisce in silenzio. Il modulo Ticket Flow di NexTool trasforma questo concatenamento in automazione: quando un ticket soddisfa un criterio, crea il ticket successivo a partire da un modello nativo di GLPI, senza intervento umano.
Il problema
Molte categorie di ticket seguono sempre lo stesso copione. Quando si apre un ticket di "Contratto di Servizio", dovrebbe nascere automaticamente uno di "Approvazione Finanziaria". Quando un ticket di "Manutenzione" viene risolto, dovrebbe comparire un "Sondaggio di Qualità". In GLPI standard questa orchestrazione vive nella memoria del tecnico - quando se ne ricorda. Il risultato è noto: fasi saltate, processi incompleti e audit impossibile, perché non esiste traccia dei sotto-processi che si sarebbero dovuti aprire.
Siamo onesti su ciò che GLPI fa già. Le regole di business dei ticket (RuleTicket) sono ottime per instradare, assegnare e categorizzare - ma agiscono sul ticket stesso in fase di creazione o aggiornamento. Nessuna regola nativa crea un ticket nuovo a partire da un altro. È proprio questa la lacuna che Ticket Flow colma.
Come funziona Ticket Flow
Il modulo permette di configurare flussi che attivano la creazione di un nuovo ticket quando un ticket originale soddisfa un criterio. Ogni flusso è legato a una categoria ITIL e a un evento trigger, e usa i modelli di ticket nativi di GLPI per generare il ticket derivato:
- 3 trigger configurabili - ticket creato, ticket risolto e ticket chiuso. Ogni categoria ammette un solo flusso attivo, il che elimina l'ambiguità su quale regola valga.
- Integrazione con TicketTemplate - il ticket figlio nasce da un modello nativo di GLPI, ereditando categoria, titolo, descrizione, gruppi e priorità già configurati nel modello.
- Motore via hook nativi - l'esecuzione è automatica tramite gli hook item_add e item_update di Ticket, senza dipendere da un cron né da azione manuale.
- Guardia anti-loop - un meccanismo interno impedisce al ticket generato di riattivare il motore, tagliando il rischio di ricorsione infinita.
- Registro di esecuzione - ogni attivazione viene registrata con un collegamento al ticket originale e al ticket generato, creando tracciabilità completa.
- Scheda di test - si può simulare la creazione di un ticket a partire da un modello nella stessa schermata di configurazione, prima di rilasciare il flusso in produzione.
Perché il modello di ticket è il cuore del flusso
Poiché il ticket figlio è generato da un TicketTemplate, la qualità del flusso dipende interamente da come è compilato il modello. Prima di mettere un flusso in produzione, conviene auditare i campi predefiniti dei tuoi modelli. La query sotto elenca i modelli di ticket e i loro campi predefiniti - se il campo di gruppo o di responsabile è vuoto, il figlio nasce orfano:
-- Modelli di ticket e i loro campi predefiniti.
-- Ticket Flow copia questi valori nel ticket figlio.
-- Campo essenziale lasciato vuoto (gruppo/responsabile) = figlio orfano.
SELECT tt.id AS modello_id,
tt.name AS modello,
tp.num AS campo_num,
tp.value AS valore_predefinito
FROM glpi_tickettemplates tt
LEFT JOIN glpi_tickettemplatepredefinedfields tp
ON tp.tickettemplates_id = tt.id
ORDER BY tt.name, tp.num;
Ogni riga è un campo predefinito del modello. Il valore di num è l'opzione di ricerca di GLPI (titolo, categoria, gruppo richiedente, gruppo assegnato, priorità). Un modello senza gruppo assegnato genera un ticket figlio che nessuno vede in coda - e il processo si blocca esattamente dove dovrebbe avanzare.
Ticket Flow vs funzioni native di GLPI
| Esigenza | Funzione nativa di GLPI | Ticket Flow |
|---|---|---|
| Creare un ticket derivato automaticamente | Non esiste - le regole di business modificano solo il proprio ticket | Sì, per categoria + trigger |
| Riutilizzare i valori predefiniti dei campi | TicketTemplate, applicato manualmente all'apertura | TicketTemplate applicato al figlio in automatico |
| Attivare alla risoluzione o alla chiusura | Nessun trigger per generare un altro ticket | Trigger: creato, risolto, chiuso |
| Evitare il loop di creazione | Non applicabile | Guardia anti-ricorsione integrata |
| Tracciare il legame padre e figlio | Storico sparso sul ticket | Registro che collega il ticket padre al figlio |
Come attivarlo
- Installa il plugin NexTool sul tuo GLPI.
- Vai in Configurazione > NexTool > Moduli.
- Attiva Ticket Flow e clicca su Configura.
- Nella scheda Flussi, crea un flusso scegliendo la categoria, il trigger e il modello del ticket figlio.
- Attiva il motore di automazione nella scheda delle impostazioni e valida il comportamento nella scheda di test prima della produzione.
Per chi è - e quando non usarlo
Ticket Flow è per team con processi strutturati dove aprire un ticket è condizione perché un altro inizi: gestione dei cambiamenti, acquisti, progetti e processi di qualità, dove dimenticare una fase ha un impatto reale sull'operatività e sull'audit.
Non è lo strumento giusto quando devi concatenare attività all'interno dello stesso ticket (per questo c'è un flusso di sotto-attività), né quando la logica è semplicemente assegnare o categorizzare il ticket stesso - le regole di business native lo risolvono già. Ticket Flow acquista valore proprio quando un processo deve generare un altro ticket, con proprietario e scadenza propri.
Cosa abbiamo imparato mantenendolo
Nella manutenzione, l'errore numero uno di Ticket Flow non è mai nel motore: è il modello del ticket figlio senza gruppo assegnato - il figlio nasce senza proprietario e sparisce dalla coda. Il secondo è dimenticare che resta attivo un solo flusso per categoria, perciò due processi che dipendono dalla stessa categoria litigano per lo stesso posto. Il terzo è il più insidioso: il trigger "chiuso" si attiva anche quando GLPI chiude il ticket da solo, tramite la routine di chiusura automatica per inattività (il cron di autoclose). Abbiamo visto un cliente svegliarsi con un'infornata di ticket figli creati di notte, perché un lotto di vecchi ticket è stato chiuso dalla routine e ogni chiusura ha attivato il flusso. La raccomandazione che abbiamo standardizzato: riserva il trigger "chiuso" ai processi che devono davvero girare alla chiusura, preferisci "risolto" quando l'intenzione è reagire alla risoluzione, e valida sempre il modello figlio nella scheda di test prima di accendere il motore.
Compatibilità
- GLPI: 10.0+ e 11.0+
- Piano: PAID
- Plugin: NexTool 3.x+
Ticket Flow fa parte di NexTool, ecosistema di moduli per estendere GLPI senza personalizzazione di codice. Parla con il team per una dimostrazione.
Questo contenuto è stato prodotto con l'aiuto dell'intelligenza artificiale e revisionato dal team di Nextool Solutions.