When people say "GLPI workflows," they usually mean one of three different things: the business rules engine that routes tickets, the status lifecycle that moves a ticket from new to closed, or multi-step approvals — which GLPI's core handles weakly but a plugin handles well. Knowing which one you actually need saves a lot of wasted configuration.
1. The business rules engine
The business rules engine is what handles most "when X happens, do Y" logic in GLPI. It's a first-match rules list: you define conditions (category, requester group, location, urgency, entity, custom fields) and actions (assign group, set SLA, change priority, attach a template, notify). GLPI walks the list in order and applies the first matching rule.
This is the right tool for routing by category, automatic SLA assignment, entity splitting in multi-org deployments, and priority calculation from the urgency/impact matrix. It's stateless and synchronous — the rules run when the ticket is created or updated. There's no notion of "step 1, then step 2."
If what you need is "finance tickets about SAP go to the apps team, Košice hardware goes to local support," the business rules engine is the answer. No plugin required.
2. The status lifecycle
Every GLPI ticket moves through a status chain: new → assigned → planned → in progress → waiting → solved → closed. Changes and problems have their own variants. Transitions are mostly free — agents move tickets forward manually, and GLPI doesn't enforce a strict state machine.
What GLPI does enforce is that some transitions require a solution (closing), an assignee (moving out of "new"), or an approval (on Changes). The lifecycle is the thin framework you shape through categories, ITIL templates, and notification rules. It is not a workflow engine in the BPMN sense, and trying to force sequential steps into the status field always ends badly.
3. Multi-step approvals — where native GLPI stops
Native approval in GLPI is a single round: you attach a flat list of validators and wait for a quorum. There is no sequence (manager first, then security, then CAB), no configurable threshold per step, no automation after approval fires. For a simple document sign-off that's fine. For a regulated change process, it's nowhere near enough.
This is where our Cascade Workflow Plugin fits in. Cascade adds the approval layer GLPI lacks — for Changes, Incidents, and Service Requests:
- Unlimited sequential steps. Each step triggers only after the previous one is approved. Manager → security → CAB → compliance, in order.
- Configurable quorum per step. Simple majority for one step, 100% unanimity for the next. Set per round, not globally.
- Dynamic approvers from form fields. FormCreator on GLPI 10, native Forms on GLPI 11 — the form defines who approves, including multiple approvers pulled from form data.
- Audit trail in ITIL Follow-up. Every approval, rejection, and comment is written directly into the follow-up log with color-coded status. Ready for ISO 27001 and SOX evidence.
- Auto-created follow-up tickets. After the last approval, Cascade creates the Change, Incident, or Service Request with the form data, attachments, and assigned team already populated.
Cascade installs as a standard GLPI plugin — no core modifications, updates survive upgrades. It's the difference between "we asked a manager to click approve" and a documented, repeatable, auditable change process.
When to use which
- Business rules engine for routing, SLA, priority, and entity logic. Stateless and fast.
- Status lifecycle for the linear "where is this ticket right now" view. Light configuration.
- Cascade Workflow Plugin for anything that needs sequence, quorum, or audit evidence beyond a single approval round.
Most real GLPI deployments end up using all three. The mistake is trying to stretch one to cover another's job — encoding approvals in categories, building a state machine out of business rules, or expecting native approval to handle a regulated change process. Pick the right layer for the problem, and GLPI workflows become predictable instead of a configuration pile.