ServiceNow Problem Management

Incident Management restores service fast. Problem Management goes deeper — it finds and eliminates the root cause so the same incident never happens again. In ServiceNow, the Problem Management module connects directly to Incident Management, creating a clear path from symptom to permanent fix.

Incident vs. Problem: The Core Difference

INCIDENT: "The email server is down right now. Fix it fast."
            → Goal: Restore service immediately

PROBLEM:  "Why does the email server keep going down every month?"
            → Goal: Find the root cause and eliminate it permanently

An incident focuses on the speed of recovery. A problem focuses on analysis and prevention. Both are essential — but they serve different purposes and follow different processes.

The Problem Lifecycle

Multiple incidents reported with a common pattern
       │
       ▼
Problem Created (PRB number assigned)
       │
       ▼
Root Cause Analysis begins
       │
       ▼
Known Error identified (root cause confirmed, workaround available)
       │
       ▼
Fix implemented → Change Request raised
       │
       ▼
Problem Resolved (root cause eliminated)
       │
       ▼
Problem Closed

When to Create a Problem

A problem should be created in these situations:

• Multiple users report the same type of incident repeatedly.
• A major incident (P1) occurs and the root cause is unknown.
• An agent suspects a deeper underlying issue causes repeated incidents.
• The business asks: "Why does this keep happening?"

Root Cause Analysis (RCA)

Root Cause Analysis is the investigation phase of problem management. The team assigned to the problem researches why the issue occurs. ServiceNow provides fields on the problem form to document the investigation:

• Problem Statement: A clear description of what the problem is.
• Root Cause: The confirmed technical reason the problem exists.
• Workaround: A temporary fix that reduces impact while the permanent fix is developed.

Example RCA Diagram

Symptom: Email server crashes every month

Why? → Disk fills up completely

Why? → Log files accumulate without being cleared

Why? → Log rotation script is misconfigured

Why? → Script was not updated after a server migration

Root Cause: Log rotation script misconfiguration after migration
Permanent Fix: Fix the script, add monitoring for disk usage

Known Error

When the root cause is identified but a permanent fix is not yet implemented, the problem becomes a Known Error. ServiceNow changes the problem's state to "Known Error" and records a workaround. The Known Error Database (KEDB) stores all known errors so that agents can quickly apply the workaround when the same incident occurs again — without re-investigating each time.

Known Error Example:
─────────────────────────────────────────────────────
Problem: PRB0001234 - Email server crashes monthly
State:   Known Error
Root Cause: Log rotation misconfiguration
Workaround: Manually clear log files from /var/log/mail
            on the last Friday of each month
Fix Status: Change request CHG000567 scheduled for next week
─────────────────────────────────────────────────────

Linking Incidents to Problems

Agents link related incidents to a problem record in ServiceNow. The problem form displays a related list of all linked incidents. This relationship shows the scope of the issue — how many users and how many incidents are connected to a single root cause.

Problem PRB0001234
  └─ Related Incidents:
       INC0001230 - Email server down (Jan)
       INC0001678 - Email not sending (Feb)
       INC0002109 - Email server unresponsive (Mar)

When the problem is resolved, all linked incidents update automatically. Agents no longer need to manually close each incident individually.

Problem to Change: Completing the Fix

Applying the permanent fix often requires making a change to the IT environment — updating a script, patching software, or reconfiguring a server. The problem manager creates a Change Request from the problem record. ServiceNow links the problem and the change, creating a complete audit trail: the symptoms (incidents) caused the investigation (problem), which led to the fix (change).

Key Fields on a Problem Record

• Short Description: A brief summary of what the problem is.
• State: Open, Root Cause Analysis, Known Error, Resolved, Closed.
• Problem Statement: Detailed explanation of the issue.
• Root Cause: The confirmed technical reason for the problem.
• Workaround: A temporary method to restore service without the permanent fix.
• Known Error: A checkbox that marks the problem as a Known Error when root cause is confirmed.
• Fix Notes: Details of the permanent solution applied.

Problem Review After Resolution

After closing a problem, teams conduct a Post-Implementation Review (PIR). This review confirms the fix worked, documents lessons learned, and updates any runbooks or knowledge articles. ServiceNow knowledge articles connected to the problem provide future agents with instant guidance if similar symptoms appear.