NexTool Solutions

Incidents that keep coming back are the symptom of a problem nobody has opened yet. In GLPI, noticing that ten Wi-Fi tickets landed at the same branch within two weeks, or that the same device is back in the queue for the fourth time, 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, the same location or the same device, 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 evaluates tickets that are already solved and closed and detects recurring incidents with rules in GLPI's own format: category, location, associated item, solution type, priority, request source, groups, requester and text in the title, the description or the solution. When the rule's minimum number of tickets is reached within the period, an ITIL Problem is opened in GLPI with the tickets that caused it already linked.

• Dual triggers - the evaluation runs whenever a ticket is solved or closed and also through GLPI's automatic action, every 6 hours by default, ensuring coverage even during volume peaks.
• Rules in GLPI's format - each rule defines the criteria, with the same operators as native rules (including "under", for subcategories and sublocations), the minimum number of tickets in the period, how to group (item, location, category, technician group, requester or department), the minimum number of distinct requesters, the minimum interval between Problems and how the Problem is created (title, template, category, urgency, impact, technician group, technician, observer group). Several rules coexist to cover different scenarios.
• One Problem per common cause - grouping by location with a minimum of 5, five Wi-Fi incidents at the Downtown branch and five at the North branch open two Problems, one per branch. The minimum number of distinct requesters keeps a single person from raising the alarm, and the minimum interval prevents repeated Problems.
• 27 ready-made templates, inactive - the same device failing again and again; Wi-Fi, printing, power and telephony at the same location; email, VPN, login, backup, security and digital certificates; same category; recurring workarounds; and every critical incident. They arrive switched off: you turn on only what makes sense in your environment.
• Recurring workarounds - one of the templates reads the ticket solution text: when the same workaround keeps being applied, it becomes a Problem, ITIL's "known error candidate".
• Test button - simulates the rule on the period's tickets without creating anything: it shows each group, how many tickets and requesters it added up against the minimum, and a preview of the Problem that would be opened.
• Scope aligned with ITIL - the 27 ready-made templates count only incidents, as ITIL recommends; in a rule of your own, the ticket type is a criterion you choose.
• Full traceability - for every detection, the Logs tab records the rule, the generated Problem, the group and the tickets that caused it.

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;

The module does this work on its own, at every evaluation and for every rule, and not only by category and entity: any combination of criteria works (location, associated item, requester, solution text and the rest), with the count split by the grouping you choose and without depending on anyone remembering to run the report.

Module feature vs native behavior

How to enable it

1. With the NexTool plugin installed on GLPI 11, go to NexTool > Modules and enable Problem Flow.
2. In the Rules tab, pick one of the 27 ready-made templates (they arrive inactive) or create your own rule.
3. Click Test: the simulation runs on the period's tickets and creates nothing.
4. Once the result is calibrated, turn the rule on.
5. Follow the Logs tab to see which rule opened each Problem, for which group and with which tickets.

What we learned in maintenance

Maintaining ITIL operations, Problem Flow gets it right or wrong on the calibration of the minimum number of tickets, not on the technology. Too low a minimum 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 and running the Test button before turning a rule on: the simulation shows, on your own tickets, each group the rule would form, how many tickets and requesters it added up against the minimum, and a preview of the Problem. You adjust right there, creating nothing, instead of waiting weeks of log. 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 used to be pointing the rule at a parent category expecting it to sum the children, and then seeing incidents scattered across sibling subcategories fail to group. In the current rules this is solved by the operator: use "under" to include the subcategories; with "is", only the chosen category counts. The same applies to locations.

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, branches 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 minimum 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 (that is what the Test button is for), trust later.

Compatibility

• GLPI: 11
• Plan: licensed module
• Plugin: NexTool 6.24.1 or higher (the current public release meets it)

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

Reviewed by the NexTool Solutions team.