A single business rule that auto-assigns tickets to the right group saves a few clicks. Useful, but not transformative. The real value of GLPI's workflow capabilities shows up when you chain multiple steps together -- building processes that span teams, require approvals, and generate sub-tasks automatically.
The building blocks
GLPI provides several native mechanisms that combine to form multi-step workflows:
- Business rules for tickets -- fire on creation or update, matching criteria like category, requester group, urgency, or title content. Actions include setting fields, assigning groups, changing status, or adding watchers
- Ticket tasks -- sub-work items within a ticket, each assignable to a different technician or group, with their own status and time tracking
- Approval requests -- built-in approval workflows where a ticket or task pauses until a designated approver (or a member of a group) accepts or refuses
- Follow-ups and notifications -- automated messages triggered by status changes, SLA thresholds, or manual events
- Satisfaction surveys -- sent automatically after ticket closure, with configurable delay and survey content
Example: simple ticket routing
A basic automated flow: user submits a ticket via the self-service portal, selects category "Network access request." A business rule fires on creation, sets the technician group to "Network team," sets urgency to medium, and sends a notification to the group. The first available technician takes ownership. When resolved, a satisfaction survey goes out after 24 hours. This requires zero plugins -- just business rules and notification configuration.
Example: employee onboarding with sub-tasks
Onboarding is where multi-step workflows prove their worth. A manager submits a ticket under the "New employee" category. Here is what happens:
- Business rules auto-categorize and assign the ticket to the IT coordinator group
- The coordinator opens the ticket and creates five tasks: provision laptop (assigned to hardware team), create AD/email account (identity team), issue access card (facilities), schedule orientation training (HR), install required software (desktop support)
- Each task group works independently, updating their task status as they complete their part
- The parent ticket stays open until all tasks are done
- An approval step notifies the manager to confirm everything is in order before the ticket closes
With a workflow plugin like Cascade, steps 2 through 5 happen automatically when the ticket is created -- no manual task creation needed. Cascade defines task templates, conditional branching (different software list for developers vs. finance), and parallel execution.
Beyond single-action rules
Native GLPI business rules execute one set of actions per rule. To build complex flows, stack multiple rules that fire in sequence based on field changes. For example: Rule 1 fires on creation and sets the group. Rule 2 fires when status changes to "assigned" and adds a watcher. Rule 3 fires when urgency is changed to "very high" and sends a notification to the service delivery manager.
Each rule has a ranking number that controls execution order. Getting this sequence right is critical -- test each rule individually before combining them.
When native rules are not enough
GLPI's built-in business rules handle linear flows well. For conditional branching (if department = finance, create tasks A, B, C; if department = engineering, create tasks A, D, E), approval chains with multiple levels, or deadline-driven escalations that go beyond SLA notifications, a workflow plugin fills the gap. The choice between native rules and a plugin comes down to complexity: if you can draw the workflow as a straight line, native rules work. If it branches, loops, or requires human decisions at multiple points, use a dedicated workflow engine.