In GLPI ist die native Genehmigung eine einzige Runde. Sie fordern die Genehmigung einer oder mehrerer Personen an, legen einen Zustimmungsprozentsatz fest, fertig - es gibt keine hierarchische Verkettung, bei der die Finanzabteilung erst eingebunden wird, nachdem die direkte Führungskraft genehmigt hat. Genau diese Lücke schließt ein Modul namens Approval Flow von NexTool.
Ein Problem: Hierarchische Genehmigung gibt es nativ nicht
In Unternehmensumgebungen umfasst die Genehmigung eines Tickets meist mehr als eine Stufe: Die direkte Führungskraft gibt frei, danach prüft die Finanzabteilung ein Budget, danach zeichnet die Geschäftsleitung ab. Dies ist ein sequenzieller Ablauf - jede Stufe ergibt erst Sinn, wenn die vorherige genehmigt hat. GLPI bildet dies nicht ab.
Der Core bietet eine einzige Genehmigungsrunde. Sie öffnen den Reiter für Genehmigungen, wählen Genehmigende (Benutzer oder Gruppen) und legen ein Feld validation_percent fest - den Prozentsatz an Zustimmungen, der nötig ist, damit ein Ticket als genehmigt gilt. Alle Genehmigenden erhalten die Anfrage gleichzeitig. Es gibt keine Reihenfolge, kein "Stufe 2 löst nur aus, wenn Stufe 1 genehmigt", keinen anderen Weg für den Fall, dass jemand ablehnt.
Warum es nicht funktioniert, Stufen mit validation_percent nachzubilden
Im Betrieb sehen wir am häufigsten den Versuch, mit dem Prozentfeld eine Reihenfolge zu erzwingen: Ein Team fordert die Genehmigung von drei Personen an und setzt 100 %, in der Annahme, dies ergebe eine Kette. Tut es nicht. Alle drei erhalten die Anfrage gleichzeitig - die Geschäftsleitung sieht sie, bevor die direkte Führungskraft sie überhaupt angeschaut hat. Schlimmer noch: Lehnt einer ab, geht ein Ticket auf REFUSED, doch die Anfragen der anderen bleiben in deren Liste "meine Genehmigungen" offen und verstopfen die Ansicht jedes Genehmigenden. Und es gibt keine Möglichkeit zu sagen "bei Ablehnung an eine andere Stufe eskalieren" oder "bei Genehmigung automatisch mit dieser Lösungsvorlage schließen". Üblicherweise gibt ein Team die native Funktion auf und löst die Kette per E-Mail außerhalb des Systems - was die Nachvollziehbarkeit zerstört und eine Audit-Lücke öffnet.
So funktioniert Approval Flow
Ein Modul namens Approval Flow ergänzt mehrstufige Genehmigungsworkflows, die an die ITIL-Kategorien der Tickets gebunden sind, und nutzt dabei die nativen Genehmigungsvorlagen von GLPI (ITILValidationTemplate) - wer genehmigt, verwendet also weiterhin den Standard-Reiter für Genehmigungen, ohne parallele Ansicht.
- Ein Workflow pro ITIL-Kategorie - jede Kategorie hat höchstens einen aktiven Workflow, womit Unklarheit darüber entfällt, welche Regel für ein Ticket gilt.
- Verkettete Stufen in Baumstruktur - jede Stufe hat unabhängige Pfade für Genehmigung und Ablehnung, Sie legen also für jeden Zweig unterschiedliche Ergebnisse fest.
- Konfigurierbare Aktion je Ergebnis - bei Genehmigung oder Ablehnung wählen Sie, was passiert: nichts tun, lösen, schließen oder zur nächsten Stufe weitergehen.
- Standardisierte Lösung - wenn die Aktion Lösen oder Schließen ist, ist die Verknüpfung mit einer SolutionTemplate Pflicht, damit der Anforderer in allen Tickets dieselbe Nachricht erhält.
- Automatische Auslösung - beim Erstellen eines Tickets in einer Kategorie mit aktivem Workflow wird die Genehmigung der ersten Stufe von selbst angefordert, ohne dass jemand daran denken muss, den Reiter für Genehmigungen zu öffnen.
- Benutzer oder Gruppen je Stufe - jede Stufe kann auf eine bestimmte Person oder eine Gruppe verweisen, mit denselben Zielen wie bei der nativen Genehmigung.
| Aspekt | Native Genehmigung in GLPI | Approval Flow |
|---|---|---|
| Runden | Eine flache Runde | Verkettete Stufen in Baumstruktur |
| Reihenfolge | Alle erhalten gleichzeitig | Die nächste Stufe löst erst aus, nachdem die vorherige genehmigt hat |
| Ablehnung | global_validation = REFUSED, ohne Folgeaktion | Eigener Ablehnungspfad (lösen, schließen oder eskalieren) |
| Auslösung | Manuell, über den Reiter für Genehmigungen | Automatisch je ITIL-Kategorie beim Erstellen des Tickets |
| Genehmigende | Benutzer oder Gruppen, alle gleichrangig | Benutzer oder Gruppe je Stufe festgelegt |
| Aktion nach der Entscheidung | Keine automatische | Lösen/Schließen per SolutionTemplate oder weitergehen |
Diagnose: wo Sie den Genehmigungsstatus ablesen
Bevor Sie einen Workflow entwerfen, lohnt es sich zu verstehen, wo GLPI den nativen Status speichert - genau diesen orchestriert ein Modul im Hintergrund. Zwei Abfragen genügen zum Auslesen:
-- GLPI: inspecionar o estado de validação nativo de um chamado.
-- global_validation e status seguem CommonITILValidation:
-- 1 = NONE (não sujeito a aprovação)
-- 2 = WAITING (aguardando)
-- 3 = ACCEPTED (aprovado)
-- 4 = REFUSED (recusado)
SELECT id, name, global_validation, validation_percent
FROM glpi_tickets
WHERE id = 12345;
-- Pedidos individuais: no nativo são todos "pares" na MESMA rodada.
-- Não existe coluna de "nível" nem ordem hierárquica.
SELECT tickets_id, status, submission_date, validation_date
FROM glpi_ticketvalidations
WHERE tickets_id = 12345
ORDER BY submission_date;
Wenn Sie bereits versuchen, Stufen mit mehreren Genehmigenden zu simulieren, macht die zweite Abfrage ein Problem offensichtlich: mehrere Zeilen mit status = 2 (WAITING) gleichzeitig, ohne jede Spalte, die eine Reihenfolge ausdrückt. Genau diese Lücke schließt ein verketteter Workflow.
So aktivieren Sie es
- Installieren Sie NexTool in Ihrem GLPI (10.0+ oder 11.0+).
- Öffnen Sie Einrichten > NexTool > Module.
- Aktivieren Sie Approval Flow und klicken Sie auf Konfigurieren.
- Erstellen Sie im Reiter Workflows einen Workflow und ordnen Sie ihn der gewünschten ITIL-Kategorie zu.
- Legen Sie Stufen, Genehmigende (Benutzer oder Gruppe) und eine Aktion je Ergebnis fest (genehmigen/ablehnen).
- Verknüpfen Sie für die Aktionen Lösen oder Schließen die entsprechende SolutionTemplate.
Für wen geeignet (und wann nicht)
Sinnvoll ist es für Organisationen, die formale Governance in der IT brauchen: Zugriffsanfragen, Beschaffungen, Infrastrukturänderungen, jedes Ticket, welches eine hierarchische Freigabe mit Nachvollziehbarkeit innerhalb von GLPI selbst erfordert. Ebenso für Teams, die nach ITIL arbeiten und keine Genehmigungskette im E-Mail-Postfach wollen.
Es lohnt sich nicht, wenn Ihre Genehmigung nur eine Stufe hat - dann genügt bereits die native Genehmigung von GLPI, und ein verketteter Workflow fügt nur Konfiguration ohne Nutzen hinzu. Es ersetzt auch keine vollständige BPM-Engine: Der Geltungsbereich ist die Genehmigung von Tickets, nicht die Orchestrierung beliebiger Prozesse mit Formularen und externen Integrationen.
Kompatibilität
- GLPI: 10.0+ und 11.0+
- Plan: PAID
- Plugin: NexTool 3.x+
Nächster Schritt
Approval Flow ist Teil von NexTool, einem Ökosystem von Modulen, welches GLPI ohne Codeanpassungen im Core erweitert. Sprechen Sie mit dem Team, um den mehrstufigen Workflow in Ihrem Szenario in Aktion zu sehen.
Geprüft vom Team der NexTool Solutions.