change_request Table — ServiceNow Reference

Table Reference/change_request

The change_request table stores controlled changes to IT infrastructure and services within the ITSM module. Extends the task table with three distinct change types (Normal, Emergency, Standard) that follow different approval workflows. Key gotcha: the state field uses different values than incident, and change types determine which fields are required.

What This Table Is

The change_request table stores controlled changes to IT infrastructure and services, supporting the full ITSM change management process from request through implementation. Each record represents a single change with detailed planning, approval workflows, risk assessment, and implementation tracking. The table manages three distinct change types: Normal (full approval process), Emergency (expedited for urgent issues), and Standard (pre-approved templates).

Owned by the ITSM module, this table drives the change advisory board (CAB) process, coordinates with configuration management, and integrates with release management. The change management process typically handles scheduling maintenance windows, coordinating team approvals, managing implementation plans, and tracking success metrics. Each change type follows different business rules for required fields, approval chains, and implementation timelines.

Extends the task table, inheriting core workflow fields like state, assignment_group, and assigned_to. No child tables extend change_request in the base platform, but the table connects to change_task for implementation activities and sysapproval_approver for approval workflows.

Large enterprises typically see 5,000-50,000 change records annually, with Normal changes comprising 60-70%, Emergency changes 5-10%, and Standard changes 20-35%. The table performs well at scale but requires careful indexing on planned_start_date and type fields for dashboard queries. Calendar views and approval reports generate the heaviest query load.

When You'll Script Against This Table

Most scripting happens in Business Rules during state transitions (submitted to approved, approved to implement, implement to review), where you'll validate required fields per change type, trigger approval workflows, or create implementation tasks. Script Includes handle complex approval logic and integration with external change management tools. Scheduled Jobs commonly query this table for SLA monitoring, automated notifications, and metrics reporting.

Access requires itil role minimum for read access, with change_manager role for full CRUD operations. Record-level ACLs restrict visibility based on assignment groups and change type. Emergency changes often have different permission models for after-hours access.

Validate change-specific required fields based on type (Normal vs Emergency vs Standard)
Trigger approval workflows when state changes to 'Assess' or 'Authorize'
Auto-create implementation tasks in change_task table when approved
Calculate risk scores based on affected CIs and implementation window
Send notifications to stakeholders for upcoming maintenance windows
Query for conflict detection against overlapping planned_start_date and affected CIs
Generate metrics reports for change success rates and SLA compliance

Table Gotchas

⚠️

The state field uses different values than incident table: -5 (New), -4 (Assess), -3 (Authorize), -2 (Scheduled), -1 (Implement), 0 (Review), 3 (Closed). Don't assume task state values work here.

⚠️

Change type field drives business rule behavior - changing from Normal to Emergency mid-process can bypass required approvals unexpectedly. Always validate type changes in Business Rules.

Standard changes require a std_change_producer_version reference - without it, they behave like Normal changes
The cab_required field is calculated based on risk and type, not directly settable in most configurations

⚠️

Querying by planned_start_date without an end date range will perform poorly. Always use date ranges: gs.dateGenerate() for start and end boundaries.

Emergency changes can skip approval states entirely - don't assume all changes follow the same state progression
The conflict_status field is auto-calculated by scheduled jobs, manually setting it gets overwritten

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.

Inherits from task table, which provides foundational workflow fields, assignment capabilities, and activity logging. Most task-related Script Includes and utilities work against change requests, but always test state-dependent logic since change states differ from incident/problem states.

The change_task table stores implementation activities linked via change_request field. Query both together for complete change implementation status. The sysapproval_approver table tracks approval chains via source_table and sysapproval references - essential for approval workflow reporting.

User tables (sys_user, sys_user_group) connect through inherited task fields and change-specific roles like requested_by and change_manager. Configuration item tables (cmdb_ci) link through affected CI relationships for impact analysis and conflict detection queries.

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
type	choice	Type	Defines change type: normal, emergency, standard, model. Controls approval workflows, required fields, and business rule behavior - changing this mid-process can bypass approvals.
state	integer	State	Current change state using different values than other task tables: -5 (New), -4 (Assess), -3 (Authorize), -2 (Scheduled), -1 (Implement), 0 (Review), 3 (Closed).
approval	choice	Approval	Overall approval status: not requested, requested, approved, rejected, cancelled. Calculated from sysapproval_approver records, not directly settable in most cases.
risk	integer	Risk	Risk assessment: 1 (High), 2 (Moderate), 3 (Low), 4 (Planning). Often auto-calculated based on affected CIs and implementation window, drives CAB requirements.
priority	integer	Priority	Change priority: 1 (Critical), 2 (High), 3 (Moderate), 4 (Low), 5 (Planning). Unlike incident priority, not auto-calculated from impact/urgency matrix.
category	choice	Category	Change category like Software, Hardware, Network, Documentation. Used for approval routing and metrics reporting - required for most change types.
requested_by	reference	Requested by	User who requested the change (references sys_user). Different from caller_id in task table - represents business requestor, not technical implementer.
change_manager	reference	Change manager	User responsible for managing the change process (references sys_user). Has special ACL permissions and approval authority for the change.
implementation_plan	string	Implementation plan	Detailed steps for implementing the change. Required for Normal changes before approval, often enforced by business rules based on change type.
backout_plan	string	Backout plan	Steps to reverse the change if it fails. Required for most change types and commonly validated by approval workflows before implementation.
test_plan	string	Test plan	Testing procedures to verify change success. Required for Normal changes in most configurations, validated during Review state.
planned_start_date	glide_date_time	Planned start date	When implementation begins. Heavily indexed and queried for conflict detection and calendar views - always use date ranges in queries for performance.
planned_end_date	glide_date_time	Planned end date	When implementation should complete. Used with start date for maintenance window calculations and resource scheduling.
cab_required	boolean	CAB required	Whether change advisory board approval is needed. Usually calculated based on risk and type, not directly settable - driven by business rules.
cab_date	glide_date_time	CAB date	When CAB will review the change. Set automatically when cab_required is true, used for meeting scheduling and approval workflows.
conflict_status	choice	Conflict status	Indicates scheduling conflicts with other changes: Not Run, Conflict, No Conflict. Auto-calculated by scheduled jobs, manual updates get overwritten.
std_change_producer_version	reference	Standard change template version	Links to standard change template (references std_change_producer_version). Required for Standard changes to work properly - without it behaves like Normal change.
review_status	integer	Review status	Post-implementation review outcome: 4 (Successful), 3 (Successful with issues), 2 (Unsuccessful), 1 (Yet to be reviewed). Used for change success metrics.
reason	choice	Reason	Business justification: Availability, Compliance, Expansion, Improvement, Maintenance, Other. Required field that drives approval routing in many implementations.
justification	string	Justification	Detailed business justification for the change. Often required for approval workflows and used in CAB review processes for Normal changes.

Common Queries

Get all active change requests

// Query all changes not in closed or cancelled states
var gr = new GlideRecord('change_request');
gr.addQuery('active', true);
gr.orderByDesc('sys_created_on');
gr.query();

while (gr.next()) {
    gs.info('Change: ' + gr.getDisplayValue('number') + 
           ' - State: ' + gr.getDisplayValue('state'));
}

Find Emergency changes assigned to specific group in Implement state

// Emergency changes actively being implemented by team
var gr = new GlideRecord('change_request');
gr.addQuery('type', 'emergency');
gr.addQuery('state', -1); // Implement state
gr.addQuery('assignment_group.name', 'Network Support');
gr.orderBy('planned_start_date');
gr.query();

while (gr.next()) {
    gs.info('Emergency change: ' + gr.getDisplayValue('number'));
}

Find conflicting changes scheduled for next 30 days

// Business scenario: detect potential scheduling conflicts
var startDate = new GlideDateTime();
var endDate = new GlideDateTime();
endDate.addDaysLocalTime(30);

var gr = new GlideRecord('change_request');
gr.addQuery('state', '!=', 3); // Not closed
gr.addQuery('planned_start_date', '>=', startDate.getDisplayValue());
gr.addQuery('planned_start_date', '<=', endDate.getDisplayValue());
gr.addQuery('conflict_status', 'Conflict');
gr.orderBy('planned_start_date');
gr.query();

gs.info('Found ' + gr.getRowCount() + ' conflicting changes');

Count changes by type and approval status

// Aggregate metrics for dashboard reporting
var ga = new GlideAggregate('change_request');
ga.addQuery('sys_created_on', '>=', gs.dateGenerate('2024-01-01', '00:00:00'));
ga.addAggregate('COUNT');
ga.groupBy('type');
ga.groupBy('approval');
ga.query();

while (ga.next()) {
    gs.info(ga.getDisplayValue('type') + ' - ' + 
           ga.getDisplayValue('approval') + ': ' + ga.getAggregate('COUNT'));
}

Query gotcha - wrong way vs right way to find Standard changes

// WRONG: This finds records with type=standard but missing template
// var gr = new GlideRecord('change_request');
// gr.addQuery('type', 'standard');

// RIGHT: Standard changes need template reference to work properly
var gr = new GlideRecord('change_request');
gr.addQuery('type', 'standard');
gr.addNotNullQuery('std_change_producer_version'); // Template required
gr.query();

gs.info('True standard changes: ' + gr.getRowCount());

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

change_request