New · Release 2026.04, Multi-tenant audit exports & SLA dashboards now liveSee changelog →
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.
Support tickets · 23 open
7 urgent
TKT-2841 · Production DB slowSLA 2h left
Assigned to Rohan · Critical
TKT-2840 · VPN access for new hireSLA 1d left
Awaiting owner approval
TKT-2838 · Email forwarding setupResolved 14m
Auto-resolved by knowledge base
Product proof
Already live in the product
Backed by app modules
Running in production today: problem management as part of the ITSM suite.
Protected app route: /problem-management
How it works
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
Workflow
What teams can do here
Step 1
Log a problem
Step 2
Investigate and record the root cause
Step 3
Publish a workaround / known error
Step 4
Close with a permanent fix
How it works
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.
Example
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.
FAQ
Frequently asked questions
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.
What is the known-error database?
Problems flagged as known errors — those with a documented workaround while a permanent fix is pending — are exposed through a dedicated known-errors endpoint, so agents can look up an accepted workaround instead of re-diagnosing a recurring issue.
Can one problem cover several incidents?
Yes. A problem can be linked to many incidents (and the serializer reports the incident count), which is how a wave of duplicate tickets collapses into one root-cause investigation.
What lifecycle does a problem move through?
New → Investigating → Root Cause Identified → Known Error → Resolved → Closed. Priority and impact are tracked separately, and resolved/closed times are stamped as it progresses.
How does a problem connect to fixing the cause for good?
A change can reference the problem it resolves, so the permanent fix is delivered through Change Management with its own approval, implementation and rollback plans — keeping the RCA and the deployment linked.
Can we keep investigation notes private?
Yes. Problem comments can be marked internal, so RCA discussion stays with the team separate from anything shared more widely.
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.