Assigning each ticket to the right technician looks trivial, yet in real service desks that manual decision becomes a bottleneck: someone has to read the queue, understand the category and dispatch - and meanwhile the SLA clock is already running. NexTool's Smart Assign module automates that step with rules by category or group, applying load balancing or sequential round-robin the instant the ticket is created.
The problem
An operation without automatic assignment always has a single point of decision: someone opens the queue of newly created tickets, reads category and subject and decides where to route them. That role usually falls to the coordinator or the most experienced analyst - exactly the person you least want stuck doing repetitive triage.
The practical effect shows up in two ways. First, the queue grows during peak hours because no one has picked up the ticket yet; it exists, it is open, but it still has no owner while the deadline runs. Second, the distribution gets uneven: one technician piles up fifteen tickets while another has three, not because of skill but because of who happened to be looking at the screen. Both scenarios erode the SLA and the user's perception of quality.
Smart Assign removes that middleman. As soon as the ticket is created, the module evaluates the configured rules and sets the owner before the queue is even opened by a human. Triage stops depending on who is on screen duty.
How Smart Assign works
The module hooks into GLPI's ticket creation and update events. Configuration is done by category or by group, with two distribution modes that can coexist in the same operation:
- Assignment by category - defines which technician or group receives tickets from a specific category. Ideal for specialized teams where each area (infrastructure, ERP, networks) has a fixed owner.
- Assignment by group - distributes tickets among the members of a group using one of the two modes below.
- Balancing mode (fewest tickets) - the ticket goes to the group technician with the smallest number of open tickets at that moment. It equalizes real load, not theoretical load.
- Round-robin mode (sequential) - tickets are distributed in order, one technician after another, regardless of load. Useful when everyone has equivalent capacity and volume is not the criterion.
- Automatic adaptation - when someone joins or leaves the group, round-robin and balancing adjust on their own, with no manual reconfiguration.
- Dedicated log - every decision is recorded in
plugin_nextool_smartassign.log, giving traceability for process audits and for investigating "why did this ticket land on me" complaints.
Smart Assign vs native business rules
GLPI already solves part of this with Business rules for tickets (Setup > Rules). They can assign by criteria such as category, but statically: they always point to the same destination. The table below shows where each approach ends:
| Feature | Native business rules | Smart Assign |
|---|---|---|
| Assign by category or group | Yes (fixed destination) | Yes |
| Load balancing (fewest open tickets) | No | Yes |
| Sequential round-robin | No | Yes |
| Adapts to technicians joining/leaving the group | Manual | Automatic |
| Dedicated record of the assignment decision | Generic history | Own auditable file |
How to enable it
- Install the NexTool plugin in GLPI.
- Go to Setup > NexTool > Modules.
- Enable the Smart Assign module.
- Open the module configuration and register the rules: choose assignment by category and/or by group and, for each group, the distribution mode (balancing or round-robin).
- Open a test ticket in the configured category and confirm the assigned technician on the ticket itself and on the matching line in the log.
What we learned running this
In client operations we sustain, the pattern that breaks most is not a missing rule - it is the "rule that points to one person". The customer creates a native business rule sending the whole "Network" category to technician X. It works for months, until technician X goes on vacation: tickets keep being assigned to them, they sit idle, and the SLA breaches silently because the queue "had an owner". The common mistake is confusing having an owner with being handled. That is why, for groups with more than three technicians, we migrate these static rules to Smart Assign's balancing mode: instead of a fixed name, the ticket lands on whoever has the least load at that minute, and whoever is on vacation simply does not receive any. A detail that only shows up in operation: balancing counts open tickets, not those closed during the day, so a technician who resolves quickly starts receiving again soon - that is how you equalize real load, not the theoretical one.
The same count the module uses to decide the destination can be reproduced in the database to audit the distribution. This query lists open tickets per assigned technician, exactly the number the balancing mode minimizes:
SELECT u.name AS technician, COUNT(t.id) AS open_tickets
FROM glpi_tickets t
JOIN glpi_tickets_users tu ON tu.tickets_id = t.id AND tu.type = 2
JOIN glpi_users u ON u.id = tu.users_id
WHERE t.status IN (1,2,3,4) -- new, processing, planned, pending
AND t.is_deleted = 0
GROUP BY u.id
ORDER BY open_tickets DESC;And every decision is written in plain text in the module log, which greatly shortens the "why did this ticket come to me" investigation:
[2026-03-12 09:41:22] smartassign: ticket #10482 category "Infra/Network" -> group "N2 Networks" mode=balancing technician=marina.souza (open=3)
[2026-03-12 09:43:05] smartassign: ticket #10483 group "N1 Support" mode=roundrobin technician=paulo.lima (next in line)Who it is for (and when not to use it)
Smart Assign delivers clear value in:
- Teams with three or more technicians where uneven distribution is recurring.
- Service desks with volume peaks where the coordinator becomes a triage bottleneck.
- Environments with well-defined categories and teams specialized by area.
- Operations that must prove, in an audit, how tickets were distributed.
When it is not worth it: in teams of one or two technicians the gain is marginal - manual sharing costs nothing. And when assignment depends on sensitive context (VIP customer, a specific expert for a critical system), that fine routing is still better in native business rules; in that case use Smart Assign for common volume and reserve native rules for exceptions, instead of stacking both decisions on the same ticket.
Compatibility
- GLPI: 10.x and 11.x
- Plan: FREE
- Plugin: NexTool 3.x+
- PHP: 8.1+
Next step
Smart Assign is part of NexTool, a modular plugin for GLPI. Explore the other modules or talk to the team for a demo in your environment.
This content was produced with the help of artificial intelligence and reviewed by the Nextool Solutions team.
