ITIL Problems

Route: /org/resolve/problems · Permission: View problem cards and root-cause details Creating and editing needs Create, analyze, and resolve problems.

---

1. What a problem is

A problem is the cause; an incident is the effect.

Five customers reporting "checkout is slow" are five incidents. The unindexed database query behind them is one problem. Restoring each customer closes five tickets and changes nothing — the sixth customer is already on their way.

	Incident	Problem
Represents	One customer's experience	The underlying fault
Counted in	Ticket volume	Problem records
Closed when	Service is restored for that customer	The fault is eliminated
Owned by	The agent on the queue	Whoever investigates
Customer sees	A reply	A workaround, then a permanent fix
Typical life	Hours	Days to weeks

The page states its own purpose: "Investigate root causes, log structural vulnerabilities, and publish temporary workarounds."

The signal to raise a problem is repetition, not severity

One severe incident is an incident. Three mild incidents with the same shape are a problem. If you are pasting the same reply into a third ticket, stop and raise a problem record.

---

2. How a problem spreads across the application

Surface	Role
Resolution Queue	Where the incidents that reveal the problem arrive
Ticket → ITIL & RMA tab	Where an incident is bound to its problem
Problems (this page)	Where the analysis lives
Changes	Where the permanent fix is approved
Executive Telemetry	Incidents Linked to Problems — only meaningful if you bind them

---

3. The screen

Figure 1 — Problems, as a table.

Titled a board, rendered as a table

The heading reads Problems Board (ITIL), but unlike Changes and Releases this is a flat table — no columns, no swimlanes, nothing to drag.

Column	Holds
Problem	The recurring fault, stated once
Root cause	Your analysis of why
Workaround	What agents tell customers now
Status	Open · Under Investigation · Resolved · Closed
Created at

---

4. Creating a problem — the drawer

Figure 2 — Create Problem Record.

+ New Problem opens Create Problem Record:

#	Field	Control	Required	Notes
1	Problem Title	Text	✅	e.g. "Memory leak in API v1 billing worker"
—	Status	Dropdown		Open · Under Investigation · Resolved · Closed
2	Risk Level	Dropdown		Low Risk · Medium Risk · High Risk
—	Description	Textarea	✅	"Explain structural vulnerabilities, scope, or background description…"
3	Root Cause	Textarea		"Describe root failure causes identified…"
4	Workaround / temporary fix	Textarea		"Describe temporary operations mitigations…"

Only Title and Description are required — and that is the point

Root cause and workaround are optional because you rarely know them when you open the record. Raise the problem the moment you spot the pattern, then fill in the analysis as it emerges. A problem record with an empty root cause is a valid, useful record: it is a question someone has taken ownership of.

---

5. Why the workaround column earns its place

While a problem is open, every incident it causes still lands in the queue. The workaround is what an agent says to the customer today.

Two habits make it work:

• Write it for a customer, not an engineer. It gets pasted into replies verbatim.
• Keep it current. A stale workaround is worse than none — agents send it, it fails, the customer replies again.

---

6. Linking incidents

From a ticket's ITIL & RMA tab, bind the incident to its problem. That is what turns "five unrelated tickets" into evidence of one fault, and it is the only thing that makes the Incidents Linked to Problems telemetry mean anything.

---

7. The lifecycle

A published workaround does not close a problem

The workaround relieves symptoms. The problem closes when the permanent fix has shipped — which means a change approved and a release deployed. Closing at the workaround stage is how the same fault returns next quarter with no record of the analysis.

---

8. Don't confuse this with…

Screen	What it is
Problems (this page)	The cause. One record, many incidents
Resolution Queue	The effects. Note there is also a PROBLEM ticket type — a ticket, not a problem record
Changes	The fix, awaiting approval
Releases	When the fix ships

A PROBLEM-type ticket is not a problem record

The queue's issue types include PROBLEM. That is still a ticket — it lives in the queue, has SLA clocks and an assignee. A problem record lives here, has no SLA, and is not counted in ticket volume. They are different objects with confusingly similar names.

---

9. Troubleshooting

Symptom	Cause
Board is empty	Wrong project — problems are project-scoped
Incidents Linked to Problems reads zero	Incidents were never bound from their ITIL & RMA tab
Agents send an outdated workaround	The workaround field was not updated when the fix changed
Cannot create a problem	You hold problems.view but not problems.manage

---

Related

• Changes · Releases
• Ticket detail — linking an incident
• Core concepts