Helpdesk automation in GLPI: ticket categorization and routing

Most GLPI installations start as a ticketing system. Someone submits a request, an agent picks it up, resolves it, closes it. That works at 20 tickets a day. At 200, it stops working — agents spend more time sorting and assigning than actually solving problems. This is where GLPI's business rules come in. Not AI, not machine learning — just well-configured rules that make the repetitive decisions for you, so agents can focus on the actual work.

The business rules engine

You configure ticket rules in Administration → Rules → Rules for assigning a category, with similar entries for Rules for assigning a ticket created through a mail collector and other types. The engine works on a first-match basis: rules have an order, GLPI walks them top-down and applies the first match. It's the same engine GLPI uses for SLA assignment, notification routing, and entity-based ticket splitting.

Each rule has two halves:

• Conditions — boolean over ticket fields (category, requester, email subject, body, location, etc.). Operators include equals, contains, regex, is empty, is not empty.
• Actions — what to set: category, assign to group, assign to technician, set priority, urgency, impact, status.

What can be automated

Ticket routing

GLPI can automatically assign tickets based on category, requester group, location, or any combination of fields. A ticket from the finance department about SAP goes straight to the applications team. A hardware request from the Košice office goes to the local support group. No manual triage needed.

A concrete rule:

Name: Route SAP requests to apps team
Conditions:
  Requester group  contains  "Finance"
  Subject          regex     /sap|s4hana|fiori/i
Actions:
  Set category     →  Software → Applications → SAP
  Assign group     →  Apps team
  Set priority     →  Medium

Priority and SLA assignment

Instead of relying on users to set priority (they always pick "urgent"), GLPI can calculate priority from a combination of urgency and impact — the standard ITIL prioritization matrix. SLA rules then attach automatically based on the resulting priority and category. A P1 incident gets a 4-hour response SLA without anyone manually setting it. And escalation rules fire automatically if the clock runs out.

Notifications that make sense

Out of the box, GLPI sends too many emails. The automation layer lets you control this: notify the requester on status changes, notify the team lead on escalation, notify the manager on approval requests — but stop there. No one needs an email for every internal note.

What not to automate

Automation works for decisions that follow clear rules. It does not work for judgment calls. Common mistakes:

• Auto-closing tickets after X days of inactivity — sounds efficient, frustrates users whose issues weren't resolved.
• Auto-assigning everything to the smallest team — distributes load but ignores skill match.
• Auto-resolving based on template responses — works for password resets, fails for anything requiring diagnosis.

The goal is to automate routing and administration so agents spend their time on resolution, not on sorting.

A practical starter set

If your GLPI helpdesk is still fully manual, start with three rules:

1. Auto-assign by category — map each ticket category to a responsible group. This alone is 80% of the value.
2. Auto-set SLA by priority — define 3–4 priority levels with matching response and resolution times.
3. Notify on escalation only — reduce email noise to the signals that matter.

These three rules make SLA tracking meaningful instead of aspirational, without overwhelming the team with brittle automation.

Cascade for richer scenarios

Native business rules cover linear "if X then Y" patterns well. For multi-step workflows with branching and custom logic, see our Cascade workflow plugin — built on top of business rules so it stays compatible with GLPI's native mechanisms.

How to verify a rule works

After creating a rule, GLPI offers a Test button on each rule — you supply sample field values and see whether the rule would apply and which actions it would fire. That avoids deploying a rule that catches nothing or, worse, catches everything.

A second check after deployment: 24 hours later, run a saved search over the field the rule sets. If it has 0 records, the rule never fired and needs investigation. If it has 100% of tickets, the rule is too broad.