ITSM · ITIL
Problem management for root-cause analysis and known errors
Find and fix the root cause behind recurring incidents — record the RCA, a temporary workaround, and the permanent resolution, and flag confirmed issues as known errors.
How is a problem different from an incident?
An incident is a single disruption to be restored quickly; a problem is the underlying cause of one or more incidents. Problem records add root-cause analysis, a workaround, a known-error flag and a permanent resolution on top of the linked incidents.
Already live in the product
Running in production today: problem management as part of the ITSM suite.
Built around real workflows
Highlights below describe capabilities already present in the protected app behind this page.
- Priority and impact triage
- Root-cause analysis (RCA)
- Workarounds and known-error register
- Permanent resolution tracking
What teams can do here
- Step 1Log a problem
- Step 2Investigate and record the root cause
- Step 3Publish a workaround / known error
- Step 4Close with a permanent fix
How it works
- 01
Open a problem
Log a problem with a title, description, priority (Critical / High / Medium / Low) and impact (Enterprise-wide / High / Medium / Low). Each problem is auto-numbered (PRB-00001, PRB-00002…) and scoped to your organisation.
- 02
Link the incidents behind it
Attach the incidents this problem is causing. A problem can carry many related incidents and can be tied to a specific affected asset, so recurring tickets roll up to one underlying cause instead of being fought individually.
- 03
Investigate and record the root cause
Move the problem through its lifecycle — New, Investigating, Root Cause Identified, Known Error, Resolved, Closed — and capture the confirmed root_cause. Add internal or shared comments as the RCA progresses.
- 04
Publish a workaround and known error
Record a temporary workaround while a permanent fix is pending, and flag the problem as a known error. Known errors surface through a dedicated known-error database endpoint so the desk can find documented workarounds fast.
- 05
Close with a permanent fix
Record the permanent resolution and close the problem; resolved and closed timestamps are captured. A stats endpoint tracks totals, open problems and how many known errors exist.
A worked example
Say a school network with 400 managed desktops logs three "printing fails after login" incidents in a single week. Rather than fight each one, the desk links all three to problem PRB-00007, marked High priority. Investigation traces the root cause to a bad print-driver push; while the corrected package is prepared, the team records the workaround — reinstall the local driver — and flags the problem as a known error, so it surfaces in the known-error database on the very next duplicate. When the fixed package ships, the permanent resolution is recorded, the problem is closed, and the deployment change links back to it for the full trail.
Frequently asked questions
See also: Incident management · Change management · Blog: What is a helpdesk? · Blog: What is a ticketing system? · IT knowledge base
Fix the cause once instead of the symptom weekly
Roll duplicate incidents into one auto-numbered problem, run root-cause analysis through a real lifecycle, and hand the desk a known-error database of accepted workarounds.