NexTool Solutions

Incidents that keep coming back are the symptom of a problem nobody has opened yet. In GLPI, noticing that ten tickets from the same category landed in the same entity within two weeks depends on someone looking at the right report at the right time. The Problem Flow module does that reading on its own and creates the ITIL Problem automatically when the pattern is confirmed.

The problem: the bridge from incident to problem is manual

Anyone running ITIL knows that Problems are the root cause behind repeated incidents. GLPI has the Problem itemtype and lets you link incidents to it, but it does not detect the recurrence: that part is human. Someone has to notice that several tickets share the same category, in the same entity, in the same time window - and only then create the Problem and link the incidents.

That gap has a cost. The interval between the pattern appearing and the Problem being opened is filled with more incidents, more rework and more load on the queue. In high-volume operations, the pattern usually goes unnoticed until the impact is already large - and then the manager's question is always the same: "why did nobody see this earlier?".

How Problem Flow works

The module automatically evaluates tickets that are already solved and closed, looking for a concentration by category and entity within a configurable time window. When the number of occurrences reaches the rule's threshold, an ITIL Problem is created in GLPI, already in context.

• Dual triggers - the evaluation runs in real time, when a ticket is closed or solved, and also via a periodic cron, ensuring coverage even during volume peaks.
• Configurable rules - each rule defines the minimum number of tickets, the analysis period, the category and the monitored entity. Several rules coexist to cover different scenarios.
• Focused scope - the module analyzes only Incident-type tickets, aligned with the ITIL practice of associating Problems with repetitive incidents.
• Full traceability - every detection is recorded in the module log, referencing the tickets that triggered the rule and the generated Problem.

The pattern the module automates

To understand what Problem Flow does, it helps to see the detection done by hand. The query below lists, by category and entity, the incidents solved or closed in the last 30 days and highlights the groups with five or more occurrences - exactly the candidates to become a Problem. Run it on a read replica or during a low-usage window:

-- MANUAL detection of the pattern that Problem Flow automates:
-- solved/closed incidents in the last 30 days, grouped by category and entity.
-- Groups with 5+ occurrences are candidates to become an ITIL Problem.
SELECT c.completename          AS category,
       e.completename          AS entity,
       COUNT(*)                AS occurrences
FROM glpi_tickets t
JOIN glpi_itilcategories c     ON c.id = t.itilcategories_id
JOIN glpi_entities e           ON e.id = t.entities_id
WHERE t.type = 1                       -- 1 = Incident
  AND t.status IN (5, 6)               -- 5 = Solved, 6 = Closed
  AND t.is_deleted = 0
  AND t.solvedate >= NOW() - INTERVAL 30 DAY
GROUP BY t.itilcategories_id, t.entities_id
HAVING COUNT(*) >= 5
ORDER BY occurrences DESC;

It is this work, repeated for every window and every rule, that the module takes over, without depending on anyone remembering to run the report.

Module feature vs native behavior

How to enable it

1. Install the NexTool plugin in GLPI.
2. Go to Setup > NexTool > Modules.
3. Enable the Problem Flow module.
4. Register the detection rules: category, entity, ticket threshold and time window.
5. Watch the module log for the first few weeks to calibrate the threshold before trusting the automation fully.

What we learned in maintenance

Maintaining ITIL operations, Problem Flow gets it right or wrong on the threshold calibration, not on the technology. Too low a threshold and the module generates a Problem per category per week, becoming noise nobody handles; too high and it never fires, and you are back to manual detection. We standardized starting conservative, watching the log for two or three weeks and only then tightening. Two details you only see in operation: first, counting still-open tickets inflates the number, because the same reopened incident shows up several times - which is why the analysis on solved and closed tickets is the correct one. Second, the most common field mistake is pointing the rule at a parent category expecting it to sum the children: because the count is by the chosen category, incidents scattered across sibling subcategories do not group, and the rule seems "broken" when it is really looking at the wrong level of the tree.

Who it is for (and when not to use it)

Problem Flow is for operations that formally adopt ITIL and want to close the gap between incident management and problem management, especially:

• High-volume environments, where manual pattern detection is impractical;
• Operations with multiple entities or distributed teams;
• Managers who need a traceable record of ITSM maturity for audit.

It makes no sense in operations that do not yet practice problem management or have very low volume: the threshold will rarely be reached and the module sits idle. And poorly calibrated, it produces too many Problems the team cannot handle - the side effect is a queue of abandoned Problems, worse than not having the automation. Calibration first, trust later.

Compatibility

• GLPI: 10.0+ and 11.0+
• Plan: Enterprise
• Plugin: NexTool 3.x or higher

Problem Flow is part of NexTool, a modular plugin for GLPI. To implement ITIL problem management with automatic, traceable detection, talk to the team.

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