problem Table — ServiceNow Reference

Table Reference/problem

The problem table stores Problem Management records for root cause analysis of recurring incidents. Part of the ITSM module, it extends the task table with problem-specific states, categories, and relationships to incidents and known errors.

What This Table Is

The problem table stores Problem Management records — formal investigations into the root causes of incidents, particularly recurring ones. Problems represent the unknown underlying causes of one or more incidents, and drive the creation of Known Errors and workarounds once root cause is identified.

Owned by the ITSM module, the problem table supports the full Problem Management process: problem identification, investigation, root cause analysis, Known Error creation, and permanent solution implementation. It extends the task table, inheriting core workflow fields while adding problem-specific states, categories, and relationship capabilities.

The problem table sits at the center of ITIL Problem Management relationships. It connects to incidents through problem_task many-to-many records, spawns Known Errors in the kb_knowledge table, and can generate Change Requests for permanent fixes. No tables extend the problem table directly.

Enterprise volumes are typically low compared to incidents — large organizations might see 50-200 problems monthly versus thousands of incidents. This lower volume means performance is rarely a concern, but the complex relationships and lengthy lifecycles (problems can remain open for months) create different scripting challenges around state management and data integrity.

When You'll Script Against This Table

You'll script against the problem table primarily in Business Rules for workflow automation, Script Includes for Problem Management integrations, and Scheduled Jobs for SLA monitoring and reporting. Problem state changes trigger complex workflows — Known Error creation, incident linking, Change Request generation — making before/after Business Rules common.

Access requires problem_manager or problem_coordinator roles for full CRUD operations. Standard itil role provides read access. Assignment group-based ACLs restrict update access to assigned teams, similar to incidents but with stricter controls due to the formal nature of Problem Management.

Common scripting patterns:

Auto-linking related incidents based on CI, category, or symptom matching
Generating Known Error records when problems reach Root Cause Analysis state
Creating Change Requests for permanent fixes when solutions are identified
Calculating business impact across all related incidents
Monitoring SLAs and escalating overdue investigations
Updating related incident workarounds when temporary solutions are found
Sending notifications to stakeholders when root cause is identified

Table Gotchas

⚠️

The problem_state field uses different values than incident state. Don't assume task state patterns apply — problems have states like 'Root Cause Analysis' and 'Known Error' that don't exist on other task types.

The related_incidents field is display-only. Actual incident relationships are stored in the problem_task table, requiring separate queries or GlideRecord joins to access.

⚠️

Problems can remain in 'Work in Progress' state for months. Don't build automation that assumes quick state transitions like incidents — use date-based conditions instead of state change counts.

The known_error checkbox doesn't automatically create Knowledge articles. It's a flag that must trigger separate Knowledge Management workflows if you want automatic Known Error creation.
Problem assignment groups often span multiple teams (network, server, application). Assignment changes might require complex routing logic that considers technical domains rather than simple workload balancing.

⚠️

Before queries on problem table can be expensive when filtering by related incident fields. The problem_task relationship isn't indexed for reverse lookups — query incidents first, then problems.

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

The problem table extends task, inheriting standard workflow fields, assignment logic, and approval processes. This means all task-based Business Rules and Client Scripts affect problems unless specifically filtered out. The inheritance also provides access to task SLA, approval, and activity stream functionality.

Most problem queries involve the problem_task relationship table to find related incidents, and the incident table for impact analysis. The kb_knowledge table connects for Known Error creation, while change_request links to permanent fix implementation.

Configuration Management Database integration is critical — problems typically reference cmdb_ci records to identify affected infrastructure. User and group tables (sys_user, sys_user_group) are commonly joined for assignment and notification logic, especially when problems require escalation to senior technical staff or management.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Key Fields

Column	Type	Label	Notes
number	string	Number	Auto-generated problem identifier (PRB0001234). Uses the same numbering scheme as other task types but with PRB prefix.
problem_state	choice	State	Problem-specific workflow states: Draft, Assessment, Root Cause Analysis, Fix in Progress, Resolved, Closed. Different from incident states.
short_description	string	Short description	Brief problem summary, often derived from related incident patterns. Should describe the symptom, not the suspected cause.
description	string	Description	Detailed problem statement including symptom patterns, business impact, and investigation scope. Can be lengthy for complex problems.
category	choice	Category	Technical classification (Software, Hardware, Network, etc.). Often determines assignment routing and investigation approach.
subcategory	choice	Subcategory	More specific categorization dependent on category value. Uses reference qualifiers to show relevant options only.
priority	choice	Priority	Business priority (1-Critical to 5-Planning). Usually derived from highest priority of related incidents, not calculated automatically.
impact	choice	Impact	Business impact level (1-High to 3-Low). Represents cumulative impact across all related incidents and affected services.
urgency	choice	Urgency	Time sensitivity (1-High to 3-Low). Often stays constant throughout problem lifecycle, unlike incidents which may lose urgency.
assignment_group	reference	Assignment group	Current owning group for investigation. May change as root cause analysis progresses through technical domains.
assigned_to	reference	Assigned to	Individual investigator. Problems often require senior technical staff rather than standard assignment pool rotation.
cmdb_ci	reference	Configuration Item	Primary affected CI. Critical for impact analysis and change coordination. Often the common element across related incidents.
business_service	reference	Business Service	Affected business service for impact assessment. Used to identify stakeholders and calculate business cost of the problem.
cause_notes	string	Root cause notes	Detailed root cause analysis findings. Key field for Knowledge Management and preventing future occurrences.
workaround	string	Workaround	Temporary mitigation steps. Often copied to related incidents and Known Error records for consistent application.
fix_notes	string	Fix notes	Permanent solution details including implementation steps and verification procedures. Links to change requests for fixes.
known_error	boolean	Known error	Flag indicating root cause is understood. Doesn't automatically create Knowledge articles — requires workflow trigger.
problem_type	choice	Type	Investigation type: Reactive (incident-driven), Proactive (trend analysis), or Post Implementation Review. Affects SLAs and workflows.
related_incidents	string	Related Incidents	Display-only field showing linked incident count. Actual relationships stored in problem_task table, not queryable directly.
major_problem	boolean	Major problem	High-visibility flag for problems affecting critical services or multiple business units. Triggers additional approval and communication.

Common Queries

Get all active problems currently being investigated

// Basic active problems query - most common starting point
var gr = new GlideRecord('problem');
gr.addQuery('problem_state', 'IN', '1,2,3,4'); // Draft through Fix in Progress
gr.addQuery('active', true);
gr.orderByDesc('priority');
gr.orderByDesc('sys_created_on');
gr.query();

while (gr.next()) {
    gs.info('Problem: ' + gr.getDisplayValue('number') + ' - ' + gr.getDisplayValue('short_description'));
}

Find problems in Root Cause Analysis state assigned to specific group

// Problems requiring root cause analysis by assignment group
var gr = new GlideRecord('problem');
gr.addQuery('problem_state', '3'); // Root Cause Analysis state
gr.addQuery('assignment_group.name', 'Network Engineering');
gr.addQuery('active', true);
gr.orderBy('sys_created_on'); // Oldest first for priority
gr.query();

while (gr.next()) {
    var daysOpen = gs.dateDiff(gr.getValue('sys_created_on'), gs.nowDateTime(), true);
    gs.info('RCA needed: ' + gr.getDisplayValue('number') + ' (open ' + daysOpen + ' days)');
}

Problems affecting critical business services with multiple related incidents

// High-impact problems for executive reporting
var gr = new GlideRecord('problem');
gr.addQuery('impact', '1'); // High impact
gr.addQuery('business_service.business_criticality', 'critical');
gr.addQuery('problem_state', 'IN', '1,2,3,4'); // Active states
gr.query();

while (gr.next()) {
    // Count related incidents via problem_task table
    var relGr = new GlideRecord('problem_task');
    relGr.addQuery('problem', gr.getValue('sys_id'));
    relGr.query();
    var incidentCount = relGr.getRowCount();
    
    gs.info('Critical problem: ' + gr.getDisplayValue('number') + ' affects ' + 
            gr.getDisplayValue('business_service') + ' (' + incidentCount + ' incidents)');
}

Count problems by state for management dashboard

// Problem state distribution using GlideAggregate
var ga = new GlideAggregate('problem');
ga.addQuery('active', true);
ga.addAggregate('COUNT');
ga.groupBy('problem_state');
ga.query();

var stateMap = {};
while (ga.next()) {
    var state = ga.getValue('problem_state');
    var count = ga.getAggregate('COUNT');
    var stateLabel = ga.getDisplayValue('problem_state');
    gs.info('Problems in ' + stateLabel + ': ' + count);
    stateMap[state] = count;
}

return stateMap;

Wrong way vs right way to find problems with recent incidents

// WRONG: Querying problems then checking incident dates (expensive)
// var gr = new GlideRecord('problem');
// gr.addQuery('active', true);
// This requires N+1 queries through problem_task relationships

// RIGHT: Query incidents first, then find their problems
var recentIncidents = new GlideRecord('incident');
recentIncidents.addQuery('sys_created_on', '>=', gs.daysAgoStart(7));
recentIncidents.query();

var problemIds = [];
while (recentIncidents.next()) {
    var ptGr = new GlideRecord('problem_task');
    ptGr.addQuery('task', recentIncidents.getValue('sys_id'));
    ptGr.query();
    while (ptGr.next()) {
        if (problemIds.indexOf(ptGr.getValue('problem')) == -1) {
            problemIds.push(ptGr.getValue('problem'));
        }
    }
}

// Now get the problems - much more efficient
var problemGr = new GlideRecord('problem');
problemGr.addQuery('sys_id', 'IN', problemIds.join(','));
problemGr.query();

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue

problem