NexTool Solutions

In GLPI, l'"approvazione" nativa è una sola tornata. Richiedi la validazione a una o più persone, imposti una percentuale di accettazione e basta - non esiste un concatenamento gerarchico in cui l'ufficio finanziario viene coinvolto solo dopo l'approvazione del responsabile diretto. Il modulo Approval Flow di NexTool colma esattamente questa lacuna.

Il problema: l'approvazione gerarchica non esiste nel core

In ambito aziendale, approvare un ticket coinvolge spesso più di un livello: il responsabile diretto lo sblocca, poi l'ufficio finanziario valida il budget, poi la direzione firma. È un flusso sequenziale - ogni passo ha senso solo dopo l'approvazione del precedente. GLPI non modella tutto questo.

Ciò che il core offre è un'unica tornata di validazione. Apri la scheda delle approvazioni, scegli i validatori (utenti o gruppi) e imposti il campo validation_percent - la quota di approvazioni necessaria perché il ticket sia considerato validato. Tutti i validatori ricevono la richiesta nello stesso momento. Nessun ordine, nessun "il livello 2 scatta solo se il livello 1 approva", nessun percorso distinto in caso di rifiuto.

Perché emulare i livelli con validation_percent non funziona

Nella nostra attività di supporto e manutenzione, l'impostazione che vediamo più spesso è il tentativo di forzare una sequenza con il campo percentuale: il team richiede la validazione a tre persone e imposta 100%, aspettandosi una catena. Non lo è. I tre ricevono la richiesta contemporaneamente - la direzione la vede prima ancora che il responsabile diretto l'abbia guardata. Peggio: se uno rifiuta, il ticket passa a REFUSED, ma le richieste degli altri restano in sospeso nella loro coda "le mie validazioni", intasando la vista di ogni approvatore. E non c'è modo di dire "se rifiutato, inoltra a un altro livello" o "se approvato, chiudi automaticamente con questo modello di soluzione". Di solito il team abbandona la funzione nativa e gestisce la catena via e-mail, fuori dal sistema - il che azzera la tracciabilità e apre una falla di audit.

Come funziona Approval Flow

Il modulo Approval Flow aggiunge flussi di approvazione multilivello legati alle categorie ITIL dei ticket, riutilizzando i modelli di validazione nativi di GLPI (ITILValidationTemplate) - così chi approva continua a usare la scheda delle approvazioni standard, senza una schermata parallela.

• Un flusso per categoria ITIL - ogni categoria ha al massimo un flusso attivo, eliminando l'ambiguità su quale regola si applica a questo ticket.
• Livelli concatenati ad albero - ogni livello ha percorsi indipendenti per approvazione e rifiuto, così definisci esiti diversi per ciascun ramo.
• Azione configurabile per esito - all'approvazione o al rifiuto scegli cosa accade: non fare nulla, risolvere, chiudere o passare al livello successivo.
• Soluzione standardizzata - quando l'azione è risolvere o chiudere, collegare un SolutionTemplate è obbligatorio, garantendo lo stesso messaggio al richiedente su tutti i ticket.
• Attivazione automatica - alla creazione di un ticket in una categoria con flusso attivo, la validazione del primo livello viene richiesta da sola, senza che nessuno debba ricordarsi di aprire la scheda delle approvazioni.
• Utenti o gruppi per livello - ogni livello può puntare a una persona specifica o a un gruppo, con gli stessi destinatari del validatore nativo.

Diagnostica: dove leggere lo stato dell'approvazione

Prima di progettare un flusso, è utile sapere dove GLPI conserva lo stato nativo - è ciò che il modulo orchestra al di sotto. Due query coprono la lettura:

-- GLPI: ispezionare lo stato di validazione nativo di un ticket.
-- global_validation e status seguono CommonITILValidation:
--   1 = NONE     (non soggetto ad approvazione)
--   2 = WAITING  (in attesa)
--   3 = ACCEPTED (approvato)
--   4 = REFUSED  (rifiutato)

SELECT id, name, global_validation, validation_percent
FROM glpi_tickets
WHERE id = 12345;

-- Richieste individuali: nativamente sono tutte "pari" nella STESSA tornata.
-- Non esiste una colonna di "livello" né un ordine gerarchico.
SELECT tickets_id, status, submission_date, validation_date
FROM glpi_ticketvalidations
WHERE tickets_id = 12345
ORDER BY submission_date;

Se stai già cercando di simulare i livelli con più validatori, la seconda query rende evidente il problema: più righe in status = 2 (WAITING) nello stesso momento, senza alcuna colonna che esprima l'ordine. È questa la lacuna che il flusso concatenato colma.

Come attivarlo

1. Installa NexTool sul tuo GLPI (10.0+ o 11.0+).
2. Vai in Configurazione > NexTool > Moduli.
3. Attiva Approval Flow e fai clic su Configura.
4. Nella scheda Flussi, crea un flusso e collegalo alla categoria ITIL desiderata.
5. Definisci i livelli, gli approvatori (utente o gruppo) e l'azione di ciascun esito (approvare/rifiutare).
6. Per le azioni di risolvere o chiudere, collega il SolutionTemplate corrispondente.

A chi è rivolto (e quando non usarlo)

È adatto alle organizzazioni che hanno bisogno di una governance IT formale: richieste di accesso, acquisti, modifiche dell'infrastruttura, qualsiasi ticket che richieda una firma gerarchica con tracciabilità all'interno di GLPI. Anche ai team che operano in ottica ITIL e non vogliono che la catena di approvazione viva in una casella e-mail.

Non conviene se la tua approvazione è a un solo livello - in quel caso la validazione nativa di GLPI basta già, e aggiungere un flusso concatenato aggiunge solo configurazione senza vantaggi. Non sostituisce nemmeno un motore BPM completo: l'ambito è l'approvazione dei ticket, non l'orchestrazione di processi arbitrari con moduli e integrazioni esterne.

Compatibilità

• GLPI: 10.0+ e 11.0+
• Piano: PAID
• Plugin: NexTool 3.x+

Prossimo passo

Approval Flow fa parte di NexTool, un ecosistema di moduli che estende GLPI senza toccare il codice del core. Parla con il team per vedere il flusso multilivello all'opera sul tuo scenario.

Questo contenuto è stato prodotto con l'aiuto dell'intelligenza artificiale e revisionato dal team NexTool Solutions.