ServiceNow Problem Management: Root Cause, Known Errors & Roles

Introduction: Fixing the Cause, Not Just the Symptom

If Incident Management is about speed, ServiceNow Problem Management is about permanence. Its job is to find the underlying cause behind incidents and remove it for good — or, until a permanent fix ships, to document a reliable workaround so the same issue stops hurting the business.

A crucial mindset (and a common exam point): problem management is not measured on how fast records close. The goal is a lasting fix, however long that takes — so tracking resolution time here drives the wrong behaviour.

What Is a Problem in ServiceNow?

A problem is the underlying cause of one or more incidents. Here is the distinction that trips people up:

	Incident	Problem
Goal	Restore service fast	Remove the root cause
Success measure	Speed of resolution	Permanence of the fix
Typical output	Service restored	Workaround + known error + fix

A slow laptop is an incident; the faulty driver behind fifty slow laptops is a problem.

Key Tables and Roles

Problems live in the problem table (extends Task); problem_task (also extending Task) holds the individual investigation tasks.

Role	Responsibility
problem_coordinator	Owns problems and problem tasks; communicates fixes/workarounds; creates known-error articles
problem_task_analyst	Works assigned problem tasks only (support groups aiding an investigation)
problem_manager	Oversees the process

Note: the Assigned to field on a problem is restricted to users with a problem role, but the Assignment group field is not — so a group with no problem users can be selected while Assigned to stays empty.

Proactive vs Reactive Detection

• Reactive: one or more incidents have already occurred and you investigate the cause.
• Proactive: you spot trends — a shaky CI, a noisy service — and open a problem before more incidents happen.

The Lifecycle, Workarounds, and Known Errors

Problems move through detection and logging, investigation and diagnosis, and resolution and closure. Along the way you record two important artifacts:

• Workaround — a temporary way to keep working while the fix is pending.
• Known error — recorded once the cause is understood but not yet permanently fixed.

As with incidents, use the State field and refer to states by constants rather than raw values.

Creating a Problem from an Incident

The Create Problem UI action on an incident spins up a problem, copies key fields across, links the two records, and sets the incident to On Hold with the reason Awaiting Problem. Which fields copy over is controlled by a system property, so it is configurable per customer.

Communicating Back to Incidents

Two UI actions push information from the problem back to related incidents:

• Communicate Workaround copies the workaround to the work notes of active incidents (and to comments on resolved, known-error incidents).
• Communicate Fix copies fix notes to associated incidents.

Driving a Permanent Fix

If the fix requires touching a configuration item, you raise a change straight from the problem (Create Normal/Emergency Change), which copies fields across and links the records. You can also generate a Known Error article for the knowledge base.

Frequently Asked Questions

What is the difference between a problem and a known error? A problem is an investigation into a root cause. A known error is a problem where the cause (and usually a workaround) is documented but a permanent fix has not yet been deployed.

What is a workaround? A temporary way to restore or maintain service while the underlying problem is still being fixed — for example, a manual step or a config toggle.

Why shouldn't problem management track resolution time? Because the goal is a permanent fix, not a fast close. Time-based KPIs push teams to close problems prematurely instead of eliminating the root cause.

What happens to an incident when you create a problem from it? The incident is linked to the new problem and set to On Hold with the reason Awaiting Problem.

Which table stores problems? The problem table, which extends the base task table; problem_task holds investigation sub-tasks.

Key Takeaways

• Problem management is about permanence, not speed.
• Know the artifacts: workaround (temporary) vs known error (cause known, fix pending).
• The problem table extends task; investigation work goes in problem_task.
• Problems are created reactively (from incidents) or proactively (from trends), and often spawn a change.
• Do not measure problem management on resolution time.

Where to go next

• Turn a fix into a controlled deployment: Change Management
• Where problems come from: Incident Management
• Practise: free practice test