GLPI’s business rules engine is the backbone of all automation in the system. Every automatic ticket assignment, every SLA attachment, every notification trigger — they all run through the same mechanism: a rule with conditions and actions.
Understanding how rules work is the difference between a GLPI that runs itself and one that requires constant manual intervention.
How the rules engine works
A business rule in GLPI has three parts:
- Criteria — conditions that must be met (e.g., ticket category equals "Network", requester entity equals "Bratislava office")
- Actions — what happens when conditions match (e.g., assign to group "Network team", set SLA "P2 — 8h response")
- Processing order — rules are evaluated sequentially. First match wins (or all matches apply, depending on the rule type)
GLPI has several rule types, each triggered at a different point:
- Rules for assigning tickets — fires when a ticket is created. Sets technician group, SLA, priority.
- Rules for asset import — fires when an agent reports a new device. Assigns entity, location, status.
- Rules for authorization — fires on login. Maps LDAP groups to GLPI profiles and entities.
- Rules for mail collection — fires when GLPI receives an email. Creates or updates tickets based on headers and content.
Practical rule design
Start simple
The most valuable first rule: auto-assign tickets by category. If you have 10 ticket categories and 4 support groups, that’s 10 rules. Each one says: "If category = X, assign to group Y." This alone eliminates manual triage for most tickets.
Layer complexity gradually
Once category-based assignment works, add entity-based rules. A ticket from Entity A about software gets assigned to Entity A’s local IT team. A ticket from Entity B about the same category goes to Entity B’s team. Same category, different routing — handled automatically.
Use regex for mail rules
Mail collector rules can parse email subjects and bodies with regular expressions. A subject containing "SAP" can auto-categorize the ticket as "Applications > SAP" before any agent touches it. Combine with sender domain matching to route external vs. internal requests differently.
Common mistakes
- Too many rules with overlapping criteria — when rules conflict, the result depends on processing order, which is hard to debug. Keep criteria specific and non-overlapping.
- Forgetting the default rule — if no rule matches, the ticket gets no assignment. Always have a catch-all rule at the bottom that assigns to a triage group.
- Not testing after changes — GLPI has a rule testing tool (Administration > Rules > Test). Use it before going live. Create a test ticket, run it through the engine, verify the result.
When rules aren’t enough
Business rules handle if-then logic well. They don’t handle multi-step processes, parallel approvals, or conditional branching based on ticket progress. For those, you need a workflow plugin like Cascade, which adds visual process modeling on top of GLPI’s ticket system. But most organizations should exhaust what business rules can do before adding a workflow engine — rules cover 80% of automation needs with zero additional software.