NexTool Solutions

When a ticket rule in GLPI does not do what it should, the diagnosis usually eats hours of whoever runs the environment. The NexTool Rule Inspector module flips that work around: instead of opening the rules one by one in the manager, it shows, inside the ticket itself, which ticket rules were evaluated, which matched, and why.

The problem

Ticket business rules are among GLPI's most powerful features: they assign technicians, set category and SLA, fire notifications and even close tickets. But when something does not work - a ticket that arrived without a technician, a category that was not applied, an SLA that never stuck - the diagnosis is done by hand. The administrator opens the rule manager, reads criterion by criterion, checks the execution order and tries to reconstruct from memory what happened the moment that ticket came in. In environments with dozens or hundreds of rules inherited from years of operation, this turns into a treasure hunt.

What makes it worse is that the rule that "did not apply" almost always applied partially. It matched, but lost to a lower-ranked rule that had the "Stop rule processing" action turned on - and from there no following rule runs. Without a tool that shows the evaluation in the ticket's context, that detail goes unnoticed.

How Rule Inspector works

Once the module is installed and enabled, a Rules tab appears on every ticket. From it you get:

• Evaluate rules - one click evaluates every active ticket rule in the ticket's entity and shows which were applied, which matched but did not execute and which failed the criteria, with the detail of each evaluated criterion.
• Per-ticket persistence - the result is saved on the ticket. When you reopen it, the button becomes "Re-run evaluation", signalling that a previous evaluation already exists to compare against.
• Test by ID - on the module's standalone page, the Test tab lets you enter any ticket number and see which rules are true for it, without opening the ticket.
• Entity-filtered history - the History tab lists every evaluation, restricted to the entities the user can see. There is no data leak between entities.
• CSV export - the history exports to CSV with a criteria column in the format criteria | condition | value, ready for audit and reporting.

The evaluation processes up to 1000 rules at a time, ordered by ranking, with a visual indicator when that limit is reached - relevant in environments that piled up rules over time.

What GLPI stores underneath

To understand why the manual diagnosis is painful, it helps to look at how rules sit in the database. The query below lists the active ticket rules, by ranking, with their criteria. Run it on a read replica or during a low-usage window:

-- Active ticket rules, by ranking, with their criteria.
-- criteria and condition are numeric codes, not readable text.
SELECT r.ranking,
       r.name              AS rule_name,
       rc.criteria         AS criteria_code,
       rc.condition        AS condition_code,
       rc.pattern          AS value
FROM glpi_rules r
JOIN glpi_rulecriterias rc ON rc.rules_id = r.id
WHERE r.sub_type = 'RuleTicket'
  AND r.is_active = 1
ORDER BY r.ranking, rc.id;

The result already explains the pain: criteria points to an internal field of the rule and condition is a code (for example, "is equal to", "is not equal to", "regular expression"). Reading that with the naked eye means decoding table by table and cross-referencing the ranking order. Rule Inspector delivers that same information already decoded and, more importantly, evaluated against a real ticket.

Manual diagnosis vs Rule Inspector

How to enable it

1. Install the NexTool plugin on your GLPI.
2. Go to Setup > NexTool > Modules.
3. Enable the Rule Inspector module.
4. Sync permissions from the NexTool panel so the right profiles start seeing the Rules tab on the ticket.

Who it is for - and when not to use it

Rule Inspector is for whoever configures and maintains ticket rules: administrators validating a new rule, quality analysts auditing automatic assignments, service desk managers investigating why certain tickets get no category or SLA, and teams that just migrated versions and need to confirm the rules still hold.

It is not the right tool if your environment does not use ticket rules, or if the question is about another GLPI rule type - dropdown dictionaries, asset import rules, LDAP rights assignment. The module focuses on what runs when a ticket is created or changed.

What we learned maintaining this

Maintaining environments with lots of rules, the ticket that "was not assigned" is almost never a GLPI bug: it is ranking order. We have opened dozens of tickets where the correct rule was perfectly right, but an earlier rule - lower ranking, therefore evaluated first - had the stop-processing action and cut the queue before reaching it. Without seeing the evaluation in the ticket's context, the client swears the rule "vanished", when in fact it never got the chance to run. The second recurring pattern is entity: someone creates the rule on the child entity thinking it applies everywhere, but the ticket came in through another entity and the rule simply was not in scope. Rule Inspector shortens that diagnosis from hours to seconds because it shows, for that specific ticket, what matched and what was blocked - including when the culprit is a "stop" rule three positions above.

Compatibility

• GLPI: 10.x and 11.x
• Plan: FREE
• Plugin: NexTool 3.x+

Rule Inspector is part of NexTool, a modular plugin for GLPI. Explore the other modules or talk to the team for a demo.

This content was produced with the help of artificial intelligence and reviewed by the Nextool Solutions team.