GLPI workflows aren't about replacing paper. Most organizations stopped shuffling paper around years ago — the real baseline today is a mess of email threads, shared folders, and "I'll ping the guy in Teams." The honest question is what happens to an IT ticket between the moment it's submitted and the moment it's closed: who it's routed to, who has to approve it, when it escalates, what template fills in the blanks. GLPI handles a useful subset of that out of the box, and the Cascade plugin extends it for the cases where the built-in rules stop being enough.
What the built-in workflow actually does
GLPI has several mechanisms that together form what most people mean by "workflow":
- Business rules for tickets. Criteria-based rules that fire on ticket creation or update and set values — category, assigned technician, SLA, urgency, entity. The classic example: any ticket from the Sales entity with category "Printer" gets routed to the local IT group with SLA "Gold." Stack enough of these and the daily triage meeting disappears.
- Approval chains. Changes and tickets can require approval from specific users or groups before moving to the next state. Single-level for routine work, multi-level for high-impact changes. Each approval is logged with who, when, and what comment — that log is what makes changes auditable.
- SLA-driven escalations. When a ticket hits a percentage of its SLA time without being assigned or resolved, GLPI triggers actions — notify a manager, raise priority, reassign to a different group. The escalation is the workflow, not a reminder email.
- Ticket templates. Mandatory fields and pre-filled values per category. A "new laptop request" template can force serial number, delivery address, and approver to be filled before the ticket can even be submitted. That alone cuts the back-and-forth that wastes the first day of every standard request.
- Recurring tickets. Scheduled tickets for predictable maintenance — quarterly backup verification, annual certificate renewal, monthly patch rollouts. Not glamorous, but the alternative is someone's Outlook calendar reminder that nobody else can see.
Together these cover most day-to-day IT operations. The edge cases are where it gets interesting.
Where Cascade comes in
The built-in rules are shallow by design: fire on create or update, set fields, maybe send a notification. They don't model a multi-step workflow with branches, time-based transitions, or cross-object dependencies very well. Our Cascade plugin fills that gap — visual workflow designer, conditional branches, time-based triggers, actions across tickets and changes and assets. We built it because clients kept asking for things like "if the approver doesn't respond within 24 hours, route to their backup, and if that also fails, escalate to the department head" — the kind of thing you can barely express in stock business rules.
Where GLPI workflows stop
GLPI workflows are for IT operations. They are not a general-purpose BPM engine. If the use case is HR onboarding, invoice routing, contract review, or expense approval, GLPI will technically handle it — a ticket is still a ticket — but you'll be fighting the data model. Those flows belong in a dedicated tool, or at least a dedicated GLPI entity with its own categories and rules kept well away from IT operations.
The other honest limit: workflow quality depends on categorization discipline. If every ticket lands in "Other" with a two-word description, no business rule can route it anywhere useful. The first step of any workflow project is usually fixing the category tree — less glamorous than the rules themselves, but load-bearing.
Where to start
If your service desk runs on a person triaging the queue manually every morning, that's a skilled human doing work a handful of business rules could do in milliseconds. The smallest useful first step is two or three routing rules for your highest-volume categories — watch them run for a week, tune the criteria, then add approvals where they actually matter. Don't try to model the entire desk on day one. Workflows that start simple and grow tend to survive; workflows designed upfront for every case tend to break the first time reality diverges from the spec.