A ticket arrives. Someone reads it, decides who should handle it, and manually assigns it. At 20 tickets a day, this takes a few minutes. At 200, it becomes a full-time job — and the person doing it becomes a bottleneck.
GLPI’s ticket assignment rules eliminate manual triage by automatically routing tickets to the right group based on ticket properties.
How assignment rules work
Assignment rules in GLPI fire when a ticket is created. They evaluate conditions against the ticket’s fields and perform actions — typically setting the assigned group, technician, or both.
A rule has:
- Criteria — field conditions (category equals X, entity equals Y, requester group equals Z)
- Logical operator — AND (all conditions must match) or OR (any condition matches)
- Actions — assign to group, assign to user, set SLA, set priority
Rules are processed in order. You can set processing to stop at the first match (most common) or continue through all matching rules (useful when you want to set group AND SLA in separate rules).
Practical routing patterns
By category
The simplest pattern. Map each ticket category to a support group:
- Hardware → Desktop Support
- Network → Network Team
- Applications > SAP → SAP Team
- Applications > Other → Application Support
This alone handles 70-80% of assignment in most organizations.
By entity
In multi-entity setups, the same category may route to different teams depending on where the ticket comes from. A hardware ticket from Entity "Bratislava" goes to Bratislava IT, while one from Entity "Košice" goes to Košice IT. Add entity as a second criterion on the category-based rules.
By requester attribute
VIP users, specific departments, or external contractors can route differently. GLPI lets you match against requester profile, group membership, or even custom user fields. A ticket from the CEO’s assistant could auto-assign to a senior agent and set priority to P2 minimum.
By source
Tickets created via email, self-service portal, or API can route differently. Email tickets from a monitoring system might go straight to the infrastructure team, while self-service portal requests go through normal triage.
The catch-all rule
Always create a final rule with no specific criteria that assigns to a general triage group. If no other rule matches — because someone submitted a ticket with an unexpected category or from a new entity — it lands somewhere visible instead of being unassigned and forgotten.
Testing and debugging
GLPI has a rule testing tool under Administration > Rules. You can simulate a ticket with specific properties and see which rules fire and what actions they perform. Use this before deploying a new rule set — one misplaced rule can send hundreds of tickets to the wrong team.
When debugging unexpected assignments, check the rule processing log on the ticket itself. GLPI records which rules matched and which actions were applied. If a ticket ended up with the wrong group, the log tells you exactly which rule did it.
When to revisit rules
Review assignment rules when:
- A new team or support group is created
- Ticket categories are added or reorganized
- A new entity or location is onboarded
- The "unassigned" or catch-all queue is growing — rules aren’t covering new ticket types
Good assignment rules are invisible. Users submit tickets, tickets appear in the right queue, agents work them. No triage step, no dispatcher, no delay.