Keď niekto povie „GLPI workflow“, väčšinou má na mysli jednu z troch rôznych vecí: business rules engine, ktorý smeruje tikety, stavový životný cyklus, ktorý posúva tiket od vzniku po uzavretie, alebo viacúrovňové schvaľovania — ktoré GLPI jadro zvláda slabo, ale plugin zvláda dobre. Vedieť, čo z toho naozaj potrebujete, ušetrí veľa zbytočnej konfigurácie.
1. Business rules engine
Business rules engine rieši väčšinu logiky typu „keď sa stane X, vykonaj Y". Je to zoznam pravidiel vyhodnocovaný po prvé zhodné: definujete podmienky (kategória, skupina žiadateľa, lokalita, urgentnosť, entita, vlastné polia) a akcie (priradiť skupinu, nastaviť SLA, zmeniť prioritu, pripojiť šablónu, notifikovať). GLPI prechádza zoznam v poradí a aplikuje prvé vyhovujúce pravidlo.
Toto je správny nástroj na smerovanie podľa kategórie, automatické priradenie SLA, rozdelenie podľa entity v multi-org nasadeniach a výpočet priority z matice urgentnosť/dopad. Je to bezstavové a synchrónne — pravidlá sa vykonajú pri vytvorení alebo úprave tiketu. Žiadny koncept „krok 1, potom krok 2".
Ak potrebujete pravidlo typu „tikety z financií o SAP idú do tímu aplikácií, hardvér z košickej pobočky ide na lokálnu podporu", business rules engine je odpoveď. Žiadny plugin netreba.
2. Stavový životný cyklus
Každý GLPI tiket prechádza reťazcom stavov: nový → priradený → naplánovaný → v riešení → čaká → vyriešený → uzavretý. Changes a problémy majú vlastné varianty. Prechody sú väčšinou voľné — agenti posúvajú tikety manuálne a GLPI nevynucuje prísny stavový automat.
Čo GLPI vynucuje, je že niektoré prechody vyžadujú riešenie (uzavretie), priradeného (odchod zo stavu „nový") alebo schválenie (pri Changes). Životný cyklus je tenký rámec, ktorý tvarujete cez kategórie, ITIL šablóny a notifikačné pravidlá. Nie je to workflow engine v zmysle BPMN a snaha natlačiť sekvenčné kroky do poľa stavu vždy skončí zle.
3. Viacúrovňové schvaľovanie — kde natívne GLPI končí
Natívne schvaľovanie v GLPI je jedno kolo: pripojíte plochý zoznam schvaľovateľov a čakáte na kvórum. Neexistuje sekvencia (najprv manažér, potom bezpečnosť, potom CAB), žiadny konfigurovateľný prah na úrovni kroku, žiadna automatizácia po schválení. Na jednoduchý podpis dokumentu to stačí. Na regulovaný change proces ani zďaleka.
Tu nastupuje náš Cascade Workflow Plugin. Cascade pridáva schvaľovaciu vrstvu, ktorú GLPI nemá — pre Changes, Incidenty aj Service Requesty:
- Neobmedzený počet sekvenčných krokov. Každý krok sa spustí až po schválení predchádzajúceho. Manažér → bezpečnosť → CAB → compliance, v poradí.
- Konfigurovateľné kvórum na krok. Jednoduchá väčšina pre jeden krok, 100 % jednomyseľnosť pre ďalší. Nastavené na kolo, nie globálne.
- Dynamickí schvaľovatelia z polí formulára. FormCreator v GLPI 10, natívne Forms v GLPI 11 — formulár definuje, kto schvaľuje, vrátane viacerých schvaľovateľov z dát formulára.
- Auditný záznam v ITIL Follow-up. Každé schválenie, zamietnutie aj komentár sa zapíše priamo do follow-up logu s farebne odlíšeným stavom. Pripravené ako dôkaz pre ISO 27001 a SOX.
- Automatické vytvorenie nadväzného tiketu. Po poslednom schválení Cascade vytvorí Change, Incident alebo Service Request s prenesenými dátami z formulára, prílohami a priradeným tímom.
Cascade sa inštaluje ako štandardný GLPI plugin — bez zásahu do jadra, updaty prežijú upgrady. Je to rozdiel medzi „poprosili sme manažéra, nech klikne schváliť" a zdokumentovaným, opakovateľným, auditovateľným change procesom.
Kedy použiť čo
- Business rules engine na smerovanie, SLA, prioritu a entitnú logiku. Bezstavové a rýchle.
- Stavový životný cyklus na lineárny pohľad „kde tiket práve je". Ľahká konfigurácia.
- Cascade Workflow Plugin na všetko, čo vyžaduje sekvenciu, kvórum alebo auditný dôkaz za hranicou jedného schvaľovacieho kola.
Reálne GLPI nasadenia väčšinou využívajú všetky tri vrstvy. Chybou je snažiť sa jednou nahradiť inú — kódovať schvaľovania do kategórií, stavať stavový automat z business rules, alebo čakať, že natívne schvaľovanie zvládne regulovaný change proces. Keď vyberiete správnu vrstvu na problém, GLPI workflow sa stáva predvídateľným, nie kopou konfigurácií.