When the same printer jams every Monday, that is not ten incidents. That is one problem. The difference matters, and GLPI has a dedicated module to handle it.
Most teams live entirely in the ticket queue. They fix each incident, close it, and move on. The same failure comes back next week, and they fix it again. Problem management breaks this cycle by asking a different question: why does this keep happening?
How the problem module works in GLPI
GLPI's Problem module (under Assistance > Problems) is separate from the ticket system. A problem is its own object with its own lifecycle: New, Assigned, Planned, Solved, Closed. It tracks root cause analysis, documents solutions, and links to the incidents that triggered the investigation.
The workflow is straightforward:
- An agent notices a pattern: the same incident type appears repeatedly.
- They create a problem ticket from the Problems menu.
- They link related incident tickets to the problem using the "Tickets" tab on the problem form.
- The team investigates the root cause and documents findings in the problem's solution field.
- If a fix requires infrastructure changes, they create a change request linked to the problem.
- After the fix is deployed and verified, the problem is closed.
All linked incidents now reference the problem, creating a clear chain from symptom to root cause to fix.
Incident vs. problem: different goals
Incident management restores service. The printer is jammed: clear it, get it printing again. Speed matters. You are not trying to understand why it happened; you are trying to get the user back to work.
Problem management prevents recurrence. The printer jams every Monday because a specific paper tray has a worn feed roller. Replacing the roller eliminates future incidents. Thoroughness matters more than speed here.
Mixing these two modes in a single ticket leads to neither being done well. Agents rush the root cause analysis because the incident SLA is ticking, or they delay restoring service because they are investigating. GLPI's separate modules enforce the right mindset for each.
Building a known error database
Not every problem can be fixed immediately. Budget constraints, vendor dependencies, or scheduled maintenance windows might delay the permanent solution. In the meantime, you need a workaround.
GLPI problems support a "Known Error" approach. When you identify the root cause but cannot deploy a fix yet, document the workaround in the problem's solution field and leave the problem open with a status of Observed or Planned. Agents handling future incidents of the same type can check the linked problem, find the documented workaround, and resolve the incident faster.
Over time, this builds an internal knowledge base of known issues and their workarounds. It is more valuable than any wiki because it is directly connected to real ticket data.
When to create a problem (and when not to)
Not every incident deserves a problem investigation. A good rule of thumb:
- Three or more incidents with the same root symptom within 30 days: create a problem.
- A single major incident affecting many users: create a problem, even if it only happened once, because the blast radius justifies the investigation.
- A one-off incident with a clear, non-recurring cause (user error, one-time misconfiguration): close the incident normally. No problem needed.
The goal is not to create a problem for every incident. It is to catch the patterns that waste the most time when left unaddressed.
Connecting problems to changes
GLPI's Change module links directly to problems. When root cause analysis identifies a fix that requires a change to infrastructure, software, or configuration, create a change request from within the problem. This gives you traceability from the original incidents through the problem analysis to the approved change and its implementation. Auditors and managers can follow the entire chain without digging through ticket comments.
The cycle looks like this: recurring incidents spotted, problem created, root cause identified, change requested, change approved and deployed, problem closed. Each step is a linked object in GLPI, not a note buried in a ticket.