NexTool Solutions

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. Una categoria può avere più flussi, anche sullo stesso trigger, eseguiti nell'ordine definito in ciascuno.
• 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 attivare un altro flusso nella stessa operazione, 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ò aprire un ticket di prova a partire da un modello nella stessa schermata di configurazione, prima di rilasciare il flusso in produzione. Attenzione: il test crea un ticket reale e richiede un permesso dedicato.

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 Suoi 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

Come attivarlo

1. Installi il plugin NexTool sul Suo GLPI.
2. Vada in Configurazione > NexTool > Moduli.
3. Attivi Ticket Flow e clicchi su Configura.
4. Nella scheda Flussi, crei un flusso scegliendo la categoria, il trigger e il modello del ticket figlio.
5. Convalidare il modello nella scheda di test prima di lasciare attivo il flusso: non esiste un interruttore separato per il motore e, con il modulo attivo, ogni flusso attivo è già in esecuzione.

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 deve 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 era la vecchia regola di un solo flusso attivo per categoria, che faceva litigare due processi della stessa categoria per lo stesso posto; dalla versione 2.0 una categoria accetta più flussi, eseguiti nell'ordine definito in ciascuno. 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: riservi il trigger "chiuso" ai processi che devono davvero girare alla chiusura, preferisca "risolto" quando l'intenzione è reagire alla risoluzione, e validi sempre il modello figlio nella scheda di test prima di attivare il flusso.

Compatibilità

• GLPI: 11
• Piano: PAID
• Plugin: base NexTool 6.11.0 o superiore

Ticket Flow fa parte di NexTool, ecosistema di moduli per estendere GLPI senza personalizzazione di codice. Parli con il team per una dimostrazione.

Revisionato dal team NexTool Solutions.