Troubleshooting ServiceNow Problem Management: A Practical Guide

Diagnosing Problem Workflow Stalls

When problem records sit open for weeks without progress, the cause is usually one of three: insufficient information to begin root cause analysis (RCA), missing specialist involvement, or unclear ownership of the permanent fix. Start by reviewing recent problem records that have stalled. Note the date the problem record was created, the date RCA began (if at all), and whether a fix was attempted.

In the Problem Management module, check the assignment group and current owner. If the assignment group is empty or assigned to the wrong team, the record has no clear owner and slips. If the problem is assigned to a single technician who is now on leave, progress stops. The tool where to look: the Assignment group field, the Assigned to field, and the Related incidents table (which tells you how many incidents are linked to this problem).

Root Cause Analysis Bottlenecks

Many organisations establish an RCA deadline (for example, RCA complete within five days of problem creation) but do not enforce it. When RCA stalls, it is often because the responsible team lacks access to the evidence they need. They may need logs from a database server, configuration data from a network device, or transaction records from a third-party service. If those teams do not participate in the RCA kick-off, you end up waiting for information throughout the week.

To unblock RCA, establish a structured kick-off process. Soon after problem creation, the problem owner schedules a brief RCA planning call. Participants include the team that owns the service, the service owner (who understands business impact), a representative from each system involved in the incident, and whoever will lead the RCA. During the call, identify what evidence is needed, who owns it, and set a date by which it must be available. Document this in the problem record. This front-loaded planning prevents information delays later.

Permanent Fix Barriers

Once root cause is identified, organisations often fail to convert the finding into a permanent fix. This happens when the fix requires cross-team coordination, affects multiple systems, or carries risk if done incorrectly. For example: “The root cause is that the integration between Loan Origination and Core Banking overwrites customer records when they arrive out of sequence. The permanent fix is to add message sequencing logic, which requires changes to two integrations and a database schema update. This needs coordination across platform teams and impacts four downstream systems.”

A permanent fix of this scope becomes a change request or an infrastructure project, not a routine problem action. In ServiceNow, you have two patterns: create a Change Request record linked to the problem (so the problem tracks the fix status), or create an Incident with a longer lifecycle (if the fix is emergency-only and will be removed post-incident). If your organisational policy is that permanent fixes become projects, you may create an Enhancement or Project record instead and link it from the problem.

Who Owns Problem Management?

Organisations that struggle with Problem Management usually lack clear ownership. Is the Problem Manager a central role (sitting in IT Operations) responsible for driving RCA? Or is problem ownership distributed to each service team? If the Problem Manager exists, do they have the authority to compel participation in RCA? If problem ownership is distributed, do service teams have SLAs for RCA completion?

Check your Problem Management configuration in the module. Look for escalation rules: if a problem is not updated within an agreed number of days, does it escalate to management? If RCA is not started by day 3, does it trigger a reminder? These automation rules surface accountability. If they do not exist, problem records drift without urgency.

Common Misconfigurations in the Platform

Review the Problem table schema. Confirm that all required fields are marked as mandatory: root cause, permanent fix plan, affected services. If these fields are optional, problems can be closed without them. Check that the workflow transition from “In Progress” to “Resolved” requires a root cause and fix plan to be completed; if the transition allows blanks, problems get closed without evidence of analysis.

Examine the Related Incidents section. This table shows which Incidents are associated with the problem (for example, five separate service desk calls all stemmed from the same underlying problem). The count of related incidents is a signal of business impact—a problem with thirty related incidents had wider impact than one with three. Some organisations use this metric to rank problems by severity and resource the high-impact problems first.

When to Escalate Problem Records

If a problem record has been open for more than the RCA SLA and root cause is not identified, escalate. Escalation means involving senior technical staff, the service owner, or vendor support. If the underlying issue is in third-party software or an external service, vendor support may be the only path to root cause. Document the escalation in the problem record and set a follow-up date with the vendor. If vendor support does not respond within your escalation SLA, escalate further to contract management or the vendor relationship owner.

Start from the symptom, then check the platform

When problem management is not working, the complaint often arrives as a symptom: the report is wrong, the investigation never ends, an incident shows the wrong problem. Starting from what users report beats walking through the configuration in order. The table groups the complaints seen most frequently by what the user noticed, with the probable cause and the first check for each. Each first check is a read-only look, so it can be done without changing anything the investigators are using.

A diagnostic path for a problem that is stuck

Stuck problems have a standard set of causes, and it is quicker to test them in order than to guess. Use this sequence before escalating the record to the service owner.

1. Confirm the record has an assignment group and a named investigator. An empty owner is a common cause and quick to fix.
2. Check whether the investigator has access to the evidence they need, such as logs or configuration records held by another team. A lack of access looks like inaction from the outside.
3. Read the record history to find its last state change. A record that has not moved since a single note was added usually needs a decision, not more analysis.
4. Check whether a dependent change, workaround or vendor response is pending. If so, record the expected date and the owner of that dependency in the problem record.
5. If none of the above applies, ask the investigator directly whether the problem is still the right problem. Many stalled records are real issues that have been overtaken by a different fix.

Reading the platform records for clues

Three places in the platform hold most of the evidence needed to diagnose a problem. The problem record’s history shows who changed what and when, which is the fastest way to explain a sudden change in counts. The linked incidents list shows the population the problem actually covers, and it often reveals an incident linked by mistake. The change list, filtered by the problem reference, shows whether a fix has been raised, approved and closed, and whether the closure was recorded against the problem.

Use the history before the configuration. A configuration fault and a process fault look identical from the outside, but the history shows which one happened: a configuration fault appears as a change at the same time for many records, while a process fault appears as a single record behaving differently from the rest.

When the fault is in the configuration

If the same symptom appears across many records, look at the configuration. Check that the mandatory fields on the problem form match the closure rules, because a closure rule that expects a field the form does not require will fail for some records and pass for others. Check that the state transitions you expect are the ones the form allows. Check the automation that runs on incident update, because a rule that fires on every update will link incidents repeatedly. Make one change at a time and test each change against a known record, so that a fix does not create a second symptom.

Questions people ask when troubleshooting

Should we fix the data or the rule when counts look wrong?

Check the rule first. If the rule is correct, the data is wrong and needs correction. If the rule is wrong, correcting data will only be undone by the next run. Rules that count the wrong thing are the more expensive error because they keep producing wrong numbers.

Can an investigator close a stuck problem without the owner’s approval?

Not if the closure rules require approval. The investigator can recommend closure and record the reason, and the owner decides. Closing a stuck record quietly makes the problem look resolved when the cause is still unknown.

When is the right time to bring in the vendor?

When the evidence points to the vendor’s product and the internal investigation has no further step it can take. Record the vendor case reference in the problem, and set a date to check the response.

How do we stop the same problem stalling again?

Add a review date to every new record, make the assignment group mandatory at creation, and review the age of open problems in the regular meeting. These three habits can remove many of the causes described above before they start.

For the wider lifecycle these symptoms belong to, the plain-language problem management guide is the place to start.