Dans GLPI, l'"approbation" native tient en une seule ronde. Vous demandez la validation d'une ou plusieurs personnes, définissez un pourcentage d'acceptation, et c'est tout - il n'existe pas d'enchaînement hiérarchique où la finance n'est sollicitée qu'après l'approbation du responsable direct. Le module Approval Flow de NexTool comble précisément ce manque.
Le problème : l'approbation hiérarchique n'existe pas dans le core
En entreprise, approuver un ticket couvre souvent plus d'un niveau : le responsable direct valide, puis la finance vérifie le budget, puis la direction signe. C'est un flux séquentiel - chaque étape n'a de sens qu'après l'approbation de la précédente. GLPI ne modélise pas cela.
Ce que le core propose, c'est une ronde de validation unique. Vous ouvrez l'onglet des approbations, choisissez des validateurs (utilisateurs ou groupes) et définissez le champ validation_percent - la part d'approbations nécessaire pour que le ticket soit considéré comme validé. Tous les validateurs reçoivent la demande en même temps. Pas d'ordre, pas de "le niveau 2 ne se déclenche que si le niveau 1 approuve", pas de chemin distinct en cas de refus.
Pourquoi émuler des niveaux avec validation_percent ne marche pas
Dans notre activité de support et de maintenance, le montage que l'on voit le plus souvent est la tentative de forcer une séquence avec le champ de pourcentage : l'équipe demande la validation de trois personnes et met 100%, en s'attendant à une chaîne. Ce n'en est pas une. Les trois reçoivent la demande simultanément - la direction la voit avant même que le responsable direct l'ait regardée. Pire : si l'un refuse, le ticket passe à REFUSED, mais les demandes des autres restent en attente dans leur file "mes validations", encombrant la vue de chaque approbateur. Et impossible de dire "en cas de refus, escalade vers un autre niveau" ou "en cas d'approbation, ferme automatiquement avec ce modèle de solution". Le plus souvent, l'équipe abandonne la fonction native et gère la chaîne par e-mail, hors du système - ce qui tue la traçabilité et ouvre une faille d'audit.
Comment fonctionne Approval Flow
Le module Approval Flow ajoute des flux d'approbation multiniveaux liés aux catégories ITIL des tickets, en réutilisant les modèles de validation natifs de GLPI (ITILValidationTemplate) - ainsi, celui qui approuve continue d'utiliser l'onglet d'approbations standard, sans écran parallèle.
- Un flux par catégorie ITIL - chaque catégorie a au plus un flux actif, ce qui supprime l'ambiguïté sur la règle qui s'applique à ce ticket.
- Niveaux enchaînés en arbre - chaque niveau a des chemins indépendants pour l'approbation et le refus, vous définissez donc des issues différentes par branche.
- Action configurable par issue - à l'approbation ou au refus, vous choisissez ce qui se passe : ne rien faire, résoudre, clôturer ou passer au niveau suivant.
- Solution normalisée - quand l'action est résoudre ou clôturer, lier un SolutionTemplate est obligatoire, ce qui garantit le même message au demandeur sur tous les tickets.
- Déclenchement automatique - à la création d'un ticket dans une catégorie avec un flux actif, la validation du premier niveau est demandée d'elle-même, sans que personne ait à penser à ouvrir l'onglet d'approbations.
- Utilisateurs ou groupes par niveau - chaque niveau peut pointer vers une personne précise ou un groupe, avec les mêmes cibles que le validateur natif.
| Aspect | Validation native GLPI | Approval Flow |
|---|---|---|
| Rondes | Une seule ronde plate | Niveaux enchaînés en arbre |
| Séquence | Tout le monde la reçoit en même temps | Le niveau suivant ne se déclenche qu'après approbation du précédent |
| Refus | global_validation = REFUSED, sans action ultérieure | Chemin de refus propre (résoudre, clôturer ou escalader) |
| Déclenchement | Manuel, via l'onglet d'approbations | Automatique par catégorie ITIL à l'ouverture du ticket |
| Approbateurs | Utilisateurs ou groupes, tous pairs | Utilisateur ou groupe défini par niveau |
| Action après la décision | Aucune automatique | Résoudre/clôturer via SolutionTemplate ou avancer |
Diagnostic : où lire l'état de l'approbation
Avant de concevoir un flux, il est utile de savoir où GLPI conserve l'état natif - c'est ce que le module orchestre en dessous. Deux requêtes couvrent la lecture :
-- GLPI : inspecter l'état de validation natif d'un ticket.
-- global_validation et status suivent CommonITILValidation :
-- 1 = NONE (non soumis à approbation)
-- 2 = WAITING (en attente)
-- 3 = ACCEPTED (approuvé)
-- 4 = REFUSED (refusé)
SELECT id, name, global_validation, validation_percent
FROM glpi_tickets
WHERE id = 12345;
-- Demandes individuelles : nativement, ce sont toutes des "pairs" dans la MÊME ronde.
-- Il n'existe ni colonne de "niveau" ni ordre hiérarchique.
SELECT tickets_id, status, submission_date, validation_date
FROM glpi_ticketvalidations
WHERE tickets_id = 12345
ORDER BY submission_date;
Si vous tentez déjà de simuler des niveaux avec plusieurs validateurs, la deuxième requête rend le problème évident : plusieurs lignes en status = 2 (WAITING) en même temps, sans aucune colonne exprimant l'ordre. C'est le manque que comble le flux enchaîné.
Comment l'activer
- Installez NexTool sur votre GLPI (10.0+ ou 11.0+).
- Allez dans Configuration > NexTool > Modules.
- Activez Approval Flow et cliquez sur Configurer.
- Dans l'onglet Flux, créez un flux et liez-le à la catégorie ITIL voulue.
- Définissez les niveaux, les approbateurs (utilisateur ou groupe) et l'action de chaque issue (approuver/refuser).
- Pour les actions résoudre ou clôturer, liez le SolutionTemplate correspondant.
Pour qui (et quand ne pas l'utiliser)
Il convient aux organisations qui ont besoin d'une gouvernance IT formelle : demandes d'accès, achats, changements d'infrastructure, tout ticket exigeant une signature hiérarchique avec traçabilité au sein même de GLPI. Aussi aux équipes qui pratiquent ITIL et ne veulent pas que leur chaîne d'approbation vive dans une boîte mail.
Cela ne vaut pas la peine si votre approbation tient sur un seul niveau - dans ce cas la validation native de GLPI suffit déjà, et ajouter un flux enchaîné ne fait qu'empiler de la configuration sans gain. Cela ne remplace pas non plus un moteur BPM complet : le périmètre est l'approbation de tickets, pas l'orchestration de processus arbitraires avec formulaires et intégrations externes.
Compatibilité
- GLPI : 10.0+ et 11.0+
- Offre : PAID
- Plugin : NexTool 3.x+
Étape suivante
Approval Flow fait partie de NexTool, un écosystème de modules qui étend GLPI sans toucher au code du core. Parlez à l'équipe pour voir le flux multiniveau fonctionner sur votre scénario.
Ce contenu a été produit avec l'aide de l'intelligence artificielle et revu par l'équipe NexTool Solutions.