ServiceNow Problem Record Explained

What a Problem Record Is

A problem record in ServiceNow is a documented investigation into the root cause of recurring or significant incidents. While an incident is about responding to a failure that has occurred, a problem is about understanding why it occurred so it can be prevented.

In plain terms: an incident is a customer or user calling to say “my service is down.” A problem is the investigation that follows: why did it go down, what configuration or process failed, and how do we prevent it from happening again?

Problem records live in the Problem Management module of ITSM. They track: the root cause of incidents, the remediation action taken to prevent recurrence, the risk if the underlying issue is not addressed, and the business impact of addressing it.

Where Problems Live and How They Connect to Incidents

Problems exist primarily in the ITSM Problem Management table. But they are not isolated: each problem typically links to one or more incidents that triggered the problem investigation.

The relationship is many-to-one: multiple incidents can be linked to the same problem if they share the same underlying cause. For example, if a database connection configuration error causes five incidents over a week, all five incidents should link to a single problem record documenting the root cause and the fix.

Problems also link to change records: the fix for a problem is often a configuration change or a code deployment. The change record links back to the problem, creating a complete audit trail: incident -> problem (root cause investigation) -> change (remediation) -> verification (did the change fix the problem?).

The Problem Management Workflow

Problems move through a fixed set of states, from New through root cause analysis and fix to Resolved and Closed, and the exact labels depend on the release. Understanding each stage helps in using Problem Management effectively.

When an incident is suspected to be caused by a recurring or systemic issue, a problem record is created. The initial state is open: a problem statement is documented, and the impact is estimated (how many users or services are affected).

The investigate stage is where the core work happens: the problem management team gathers data about all related incidents, analyzes logs, reviews recent changes, and formulates a hypothesis about the root cause.

The diagnostics stage involves testing the hypothesis: reproducing the issue in a test environment, confirming the suspected cause, and identifying the fix. Once diagnostics confirm the root cause, a workaround might be documented (to reduce impact while the permanent fix is being developed) and a change is planned for the permanent fix.

Pending indicates that a permanent fix has been deployed but is not yet fully verified. Once verification confirms the fix resolves the issue, the problem moves to resolved. After a grace period set by your team, with no recurrence, the problem is closed.

Common Misconceptions About Problems

A frequent misunderstanding is that problems are only for critical outages. In reality, problems can address any recurring issue: password reset failures affecting multiple users, printing issues affecting a department, or configuration drift causing performance degradation. The key is that the issue recurs or affects multiple users or systems.

Another misconception is that problems are only for technical root causes. Problems can also address process issues: if multiple incidents stem from inadequate runbook documentation, the problem is the documentation gap and the fix is an updated runbook. If incidents recur because a team lacks training on a critical process, the problem is the training gap.

Some teams create too many problem records, one for each incident. This defeats the purpose of problem management: grouping related incidents to identify patterns. Other teams create too few, investigating and fixing issues without formally tracking root causes, losing the opportunity to learn and prevent recurrence.

A Worked Example

Suppose five incidents occur over two weeks: users unable to access a critical web portal. Each incident is independently investigated and worked around (users directed to use an alternative method temporarily). But the root cause is never identified.

With proper problem management: the second or third incident triggers creation of a problem record. The problem investigation reviews all incidents to date, compares symptoms and timing, and discovers that access failures correlate with capacity thresholds in a load balancer.

The problem record documents this root cause. A change is planned to increase load balancer capacity. Once the change deploys, the problem transitions to pending. Monitoring confirms no more access failures occur for two weeks, so the problem is resolved and closed.

The organization has now prevented future incidents of this type, not just repeatedly fixed symptoms.

Related Concepts and Connections

Problem management connects to multiple areas. Known errors are problems that have been diagnosed and have documented workarounds but not yet been permanently fixed. The Known Error Database (KEDB) makes this information accessible to support teams so they can resolve incidents quickly even while permanent fix is in progress.

Problems also relate to change management: if a change caused a problem, that relationship is documented. Changes should include testing to verify they do not introduce new problems. Post-implementation reviews of changes often identify new problems that need investigation.

Deciding which incident clusters earn a problem record

The hard part of problem management is not writing the record. It is deciding, from a stream of incidents, which cluster deserves an investigation and which is noise that will fade. A problem manager who opens a record for every repeat wastes investigation effort, and one who waits for a major outage misses the slow pattern that causes much of the cost. A workable test asks three things: has the same symptom appeared more than once, can someone name a plausible shared cause, and would a permanent fix change a future outcome. When all three are answered yes, the record is justified. When only the first is answered yes, the right step is a watch list entry on the incidents, not a problem.

Signal in the incident stream	Likely response	What to avoid
Repeats on one configuration item with a known recent change	Open a problem and link the change for review	Treating the change as the cause before the evidence supports it
Repeats across many items with the same error text	Open a problem scoped to the shared component	Splitting it into one problem per affected item
Repeats that are all resolved by the same workaround	Document the workaround and open a problem only if the workaround is costly	Closing the incidents and forgetting that the workaround exists
A single severe event with no repeat	Route to major incident review, and open a problem only if the review finds a systemic gap	Opening a problem to satisfy a reporting request

Scoping the investigation so it can finish

A problem scoped too broadly, such as one called network instability, never closes because nobody can say when it is done. A scope that names the component, the symptom and the window of time gives the investigation an end point. Write the scope into the first paragraph of the record, and revise it once, deliberately, if the evidence points elsewhere. The revision should be recorded, so the trail shows why the work changed direction.

1. Name the affected component or service and the observable symptom in one sentence.
2. Set the window of incidents to examine, starting from the first occurrence you can verify rather than the first one someone remembers.
3. List the changes, releases and configuration updates inside that window, including those made by other teams.
4. Separate the hypotheses from the evidence in the working notes, and mark each hypothesis with the test that would disprove it.
5. Agree the decision rule up front: what evidence would justify a permanent fix, and what would justify accepting the workaround.

Where problem work goes wrong in practice

The worst failure is a problem that turns into a blame exercise. When the record names a team as the cause, people stop sharing logs and the investigation slows to a crawl. The working rule is that a problem describes a condition in the system or the process, never a person. A second failure is the closure that happens before the fix has been checked against evidence that it worked, which turns the record into a note that the issue went away. A third is the permanent fix that is planned but never linked to the record, so the next investigator starts from zero and reaches the same conclusion again.

How to judge whether the problem process is healthy

Look at the records themselves rather than at the count. Healthy problem management tends to produce a small number of records that each explain a cluster of incidents, with the changes linked and the decision recorded. Unhealthy management produces either a long list of records with one incident each, or a short list of records that have been open for a long time with no recent notes. Review the age of open problems each month and ask the owner of each old record for a decision, even if the decision is to close it as not worth fixing.

When not to open a problem record

Do not open a problem when the cause is already known, the fix is already scheduled and nothing is gained by tracking it separately. In that case the change record carries the investigation. Do not open a problem to hold a complaint that the service desk handled poorly; that is a process review. And do not open a problem for an incident that recurs only because a user keeps reporting an expected behavior, since the right fix may be a clearer message to the user rather than a technical investigation.

Who has the authority to decide that a problem is not worth fixing?

The service owner for the affected service should make that call, with the problem manager presenting the evidence. A decision to accept a known error should be recorded with its reason, and it should be reviewed when the workaround stops working or when the volume rises.

Should a problem be reopened if the same symptom returns after closure?

Reopen it when the returning symptom has the same cause. If the cause is different, open a new problem and link it to the old one, so the history of the component stays visible without merging two investigations.

How do we handle a problem that spans two vendors?

Keep one problem record as the single point of coordination, and link the vendor tickets to it rather than letting each vendor own a parallel investigation. Agree in writing who owns the evidence each vendor must supply.

What role does the knowledge base play once a workaround exists?

The workaround should be written as a knowledge article the service desk can apply without the investigation notes. Review it whenever the problem record changes state, because an article that describes a superseded workaround can keep the same incidents coming in.