Problems
A problem is the underlying cause behind one or more incidents. Working a problem is about finding and removing that root cause so the incidents it generates stop recurring.
Creating a problem
Section titled “Creating a problem”A problem needs a Short description and a Problem statement — a clear statement of what’s being investigated. A problem is often created from an incident: the First reported by task field links back to the incident that first surfaced it, and the incident’s related list can point at the problems raised from it.
States
Section titled “States”| State | What it means | Typical next action |
|---|---|---|
| New | Just logged (often auto-created from an incident). Awaiting triage. | Assess, or Mark Duplicate if it duplicates an existing problem |
| Assess | A coordinator is confirming the problem is genuine, sizing its impact/priority, and assigning it. | Confirm to move into investigation, or Accept Risk to close without fixing |
| Root Cause Analysis | Confirmed and under investigation. Analysts document the cause, and where possible a workaround and a known error. | Fix, once the root cause and a fix are agreed — or Re-Analyze to go back to Assess |
| Fix in Progress | Root cause known, permanent fix agreed and being implemented (often via a linked change). | Resolve once the fix is applied |
| Resolved | Fix applied (or the risk formally accepted). A resolution code and cause notes are recorded. | Complete, once reviewed — or Re-Analyze if the resolution is rejected or incidents recur |
| Closed | Terminal, after review. Major problems record a review outcome and close notes. | Reopen if the problem recurs |
Transitions at a glance
Section titled “Transitions at a glance”- Assess (New → Assess) — problem confirmed as worth investigating.
- Mark Duplicate (New → Closed) — duplicates an existing master problem.
- Confirm (Assess → Root Cause Analysis) — assessment confirms it’s genuine.
- Accept Risk (Assess → Resolved) — the business decides not to fix it.
- Fix (Root Cause Analysis → Fix in Progress) — root cause identified, fix agreed.
- Re-Analyze (Root Cause Analysis → Assess, or Resolved → Root Cause Analysis) — analysis inconclusive, or the resolution didn’t hold.
- Resolve (Fix in Progress → Resolved) — fix applied.
- Complete (Resolved → Closed) — resolution reviewed.
- Reopen (Closed → Root Cause Analysis) — the problem recurs after closure.
Root cause fields
Section titled “Root cause fields”As you work a problem you fill in: Cause, Root cause, Cause notes, Root cause analysis, Workaround (a temporary measure that restores service before a permanent fix), and Fix notes (the permanent fix). At resolution you record a Resolution code (Fix Applied, Risk Accepted, Canceled, Duplicate, Cannot Reproduce, or No Action Required).
Major problems and the review
Section titled “Major problems and the review”Flagging a problem as a Major problem makes the review mandatory: you cannot Complete it until a Review outcome (Successful, Partially Successful, or Unsuccessful) is recorded alongside close notes. Non-major problems can close without that review.
Problem tasks
Section titled “Problem tasks”The Problem Tasks related list holds the sub-tasks that coordinate the investigation work under a problem — use it to break the root-cause analysis into assignable pieces.
Known errors
Section titled “Known errors”A problem carries a Known error flag. Publishing a known error is its own small workflow, separate from the problem’s own state: a known-error article moves through Draft → Published → Retired, and it can only be published once it has both a cause and a workaround recorded. While published, it deflects further incidents against the same root cause. The Known Errors related list on a problem shows the published articles associated with it.
Distinct roles gate different actions: a Problem Coordinator typically drives Confirm, Resolve, Mark Duplicate, and Reopen; a Problem Manager owns Accept Risk and Complete; and a Problem Analyst does the investigation work itself.