"Automation" is one of the most oversold words in ITSM marketing, and the GLPI business rules engine catches some of that glare. The honest picture is narrower and more useful: business rules are a condition-and-action engine that runs on ticket creation and update. They're good at a specific kind of work, bad at others, and if you know which is which you'll get a lot out of them without setting yourself up for disappointment.
What a business rule actually is
A business rule in GLPI is effectively a row in a table: match these conditions on a ticket, then assign these values to these fields. "If the requester's entity is Sales and the category is Printer, set the assigned group to IT-Bratislava and the SLA to Gold." That's it. It runs once when the ticket is created, and optionally once more on each update. The engine is intentionally simple — conditions are field comparisons, actions are field assignments — because simple rules are the ones that don't break silently six months later when nobody remembers why they existed.
What rules are genuinely good at
Field-setting automations are where the rule engine earns its keep. A handful of patterns show up in almost every install:
- Routing by category and entity. Every ticket of category X from entity Y goes to group Z. This one pattern, done well, eliminates the daily triage meeting from most service desks.
- SLA assignment. Conditional SLA by ticket type, priority, or requester. Done at creation, recorded once, no manual step.
- Urgency overrides. "If the requester is in group VIP, urgency is always High" — enforced consistently without anyone having to remember.
- Field defaults by template. Pre-filling location, requester type, or responsible group based on category. Cleaner tickets, fewer back-and-forth follow-ups.
- Auto-close on inactivity. "If status is Solved and nothing has happened in 7 days, close." One rule, a measurable drop in stale-ticket reports.
None of this is glamorous. It's just the work that removes a repetitive touch from every ticket. Twenty carefully-tuned rules can do more for a service desk than a sprint of plugin development.
What rules aren't for
The things that look like automation but aren't:
- Multi-step approvals with delays. "Route to manager, wait 24 hours, escalate if no response" — business rules can't express a delay. That's a workflow engine.
- Branching based on earlier decisions. Rules can react to new state, but coordinating a multi-step decision chain isn't their job.
- Cross-object actions. "When a ticket closes, mark the related change complete." Rules don't reach across object types.
- External calls. Calling a Jira API, pushing a message to Slack, writing to an external database — out of scope for the rule engine. That's what webhooks and the REST API are for.
Forcing business rules into any of these produces brittle configurations that almost work, and that's worse than no automation at all.
Where to start
Before writing any rule, pull your busiest category's tickets from the last 90 days and look at how they were actually triaged. The patterns you see — "everything from this entity always goes to this group," "everything with this keyword always needs this SLA" — are the first rules to write. Start with five, watch them for a week, fix the misclassifications, add more. The common failure mode is a rule engine with 80 entries that contradict each other because someone tried to model every edge case on day one. Fewer rules, better tuned, beat a tall stack of stale ones every time.
When to reach for Cascade
If what you actually need is a multi-step workflow with delays, branches, or approval chains, business rules won't get you there. Our Cascade plugin exists for exactly that layer — visual workflows, conditional branches, time-based triggers, and actions across objects. The rule engine stays useful underneath it for the "set field on create" work it does well, and Cascade handles what rules were never designed for.