sys_update_xml Table — ServiceNow Reference

Table Reference/sys_update_xml

The sys_update_xml table stores individual configuration change records within update sets, with each record containing the XML representation of a modified configuration item. Owned by the Development module, this table is the foundation of ServiceNow's change tracking system. The critical thing to know: never modify the payload field directly unless you fully understand the XML schema consequences.

What This Table Is

The sys_update_xml table captures individual configuration changes as XML payloads within update sets. Each record represents a single modification to a configuration item—whether it's a Business Rule, UI Policy, or custom table field. When you modify any configuration through Studio or direct table manipulation, ServiceNow automatically creates these records to track what changed.

Owned by the Development module, this table supports ServiceNow's entire change management and deployment pipeline. Update sets depend on these records to know what to migrate between instances. The table stores the complete before-and-after state of configuration items as XML, making it possible to replay changes on target instances or roll back modifications.

This table doesn't extend any parent table—it's a standalone configuration tracking mechanism. No tables extend sys_update_xml either. It has a direct many-to-one relationship with sys_update_set records, where each update set can contain thousands of individual XML entries.

In large enterprises, this table grows exponentially—a typical production instance might contain 500K+ records spanning years of configuration changes. The payload field can store massive XML documents, making queries expensive without proper filtering. Most instances implement retention policies to archive or delete old update set entries to maintain performance.

When You'll Script Against This Table

You'll primarily script against sys_update_xml in Background Scripts for deployment automation, Script Includes for custom update set utilities, and Scheduled Jobs for cleanup operations. Developers also query this table in Business Rules when they need to track what specific configurations changed during update set commits. The most common context is building custom deployment pipelines that need to analyze or manipulate update set contents before migration.

Access requires the admin role or specific rights to the sys_update_xml table. Most scoped applications can read these records but cannot modify them. Global scope provides full access, but modifying update set entries outside of ServiceNow's native processes can corrupt deployments.

Common scripting patterns:

Querying all changes within a specific update set for deployment validation
Filtering by target_name to find changes to specific configuration items
Parsing XML payloads to extract field values or detect conflicts before merging
Counting changes by table name to generate deployment reports
Creating custom update set merge tools that resolve conflicts programmatically
Building deployment audit trails that track what changed and when
Archiving or deleting old update set entries for performance maintenance

Table Gotchas

⚠️

The payload field contains raw XML that can exceed 4MB for complex configurations. Querying without proper limits can cause memory issues and slow performance.

The state field uses string values ('current', 'previous') not choice values—filtering requires exact string matches

⚠️

Records with action='DELETE' have empty payload fields—the XML represents the deleted state, not the current configuration.

The target_name field stores the configuration item name, but for custom table fields it includes the full table.field_name format
Only sys_created_on and update_set fields are indexed—queries on other fields perform full table scans

⚠️

Deleting sys_update_xml records breaks update set integrity—ServiceNow expects these records to exist for proper deployment and rollback functionality.

XML parsing requires the XMLDocument API—standard JavaScript XML methods don't work in ServiceNow's server-side environment

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 primary relationship is with sys_update_set through the update_set reference field. This parent-child relationship defines which changes belong to which update set. Developers constantly join these tables to filter changes by update set state, name, or creation date. The sys_update_set table provides metadata like who created the update set and when it was last modified.

Common cross-references include sys_user for tracking who made changes, and sys_scope for identifying which application scope contains the modified configurations. When building deployment reports, developers often join with sys_metadata to get additional context about the configuration items being changed.

For conflict detection and merge operations, developers query sys_update_xml alongside the actual configuration tables (like sys_script for Business Rules or sys_ui_policy for UI Policies) to compare the XML representation against the current live configuration. This pattern helps identify what changed between environments and prevent deployment conflicts.

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
update_set	reference	Update set	References the parent sys_update_set record. This is the primary way to group and filter changes for deployment.
name	string	Name	Unique identifier for this specific change entry. Format typically includes table name and sys_id of the modified record.
action	string	Action	Indicates the type of change: INSERT, UPDATE, or DELETE. DELETE actions have empty payload fields since the record no longer exists.
state	string	State	Current processing state as string values: 'current' or 'previous'. Not a choice field, so queries must use exact string matches.
payload	string	Payload	Complete XML representation of the configuration change. Can exceed 4MB for complex items and causes performance issues in large result sets.
target_name	string	Target name	Name of the configuration item being changed. For table fields, includes full table.field_name format rather than just the field name.
type	string	Type	Category of configuration being changed (e.g., 'Business Rule', 'Table', 'Field'). Useful for grouping changes by configuration type.
target_table	string	Target table	Name of the table containing the configuration item. Critical for filtering changes by specific tables or modules.
category	string	Category	Broader classification of the change type. Often empty but can provide additional context for certain configuration types.
remote_update_set	reference	Remote update set	References sys_remote_update_set when this change came from another instance. Null for locally created changes.
update_guid	string	Update GUID	Global unique identifier for tracking this change across instances. Essential for preventing duplicate applications during deployment.
replaced_by	reference	Replaced by	References another sys_update_xml record when this change has been superseded. Used in conflict resolution workflows.
collision_detected	boolean	Collision detected	Indicates whether ServiceNow detected a conflict with existing configuration during update set processing.
is_merge_update	boolean	Is merge update	Marks records created during update set merge operations. These changes represent conflict resolutions rather than original modifications.

Common Queries

Get all changes in a specific update set

// Most basic query - filter by update set reference
var gr = new GlideRecord('sys_update_xml');
gr.addQuery('update_set', 'your_update_set_sys_id');
gr.addQuery('state', 'current'); // Only active changes
gr.orderBy('sys_created_on');
gr.query();

while (gr.next()) {
    gs.info('Change: ' + gr.getValue('target_name') + ' (' + gr.getValue('action') + ')');
}

Find Business Rule changes in completed update sets

// Filter by type and update set state using joins
var gr = new GlideRecord('sys_update_xml');
gr.addQuery('type', 'Business Rule');
gr.addQuery('state', 'current');
// Join to update set table to check completion status
gr.addQuery('update_set.state', 'complete');
gr.query();

while (gr.next()) {
    gs.info('Business Rule: ' + gr.getValue('target_name') + ' in update set: ' + gr.update_set.getDisplayValue());
}

Analyze changes for deployment validation

// Real-world scenario: check for risky changes before deployment
var gr = new GlideRecord('sys_update_xml');
gr.addQuery('update_set', update_set_id);
gr.addQuery('target_table', 'IN', 'sys_user,sys_user_group,sys_security_acl');
gr.addQuery('action', '!=', 'INSERT'); // Updates and deletes are riskier
gr.query();

var risks = [];
while (gr.next()) {
    risks.push(gr.getValue('target_name') + ' (' + gr.getValue('action') + ')');
}
gs.info('Security-related changes found: ' + risks.length);

Count changes by configuration type using GlideAggregate

// Generate deployment summary report
var ga = new GlideAggregate('sys_update_xml');
ga.addQuery('update_set', update_set_sys_id);
ga.addQuery('state', 'current');
ga.groupBy('type');
ga.addAggregate('COUNT');
ga.query();

while (ga.next()) {
    var type = ga.getValue('type') || 'Unknown';
    var count = ga.getAggregate('COUNT');
    gs.info(type + ': ' + count + ' changes');
}

Wrong way vs right way to query payload content

// WRONG: This loads massive XML into memory and performs poorly
// var gr = new GlideRecord('sys_update_xml');
// gr.addQuery('payload', 'CONTAINS', 'some_value');

// RIGHT: Filter by indexed fields first, then parse XML selectively
var gr = new GlideRecord('sys_update_xml');
gr.addQuery('target_table', 'sys_script'); // Use indexed field first
gr.addQuery('target_name', 'CONTAINS', 'specific_rule_name');
gr.setLimit(10); // Always limit payload queries
gr.query();
// Then parse payload only for matched records

Related Tables

sys_update_set sys_user sys_script

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