ServiceNow Update Set XML Viewer

How to review a ServiceNow update set before you commit it

A short routine catches most bad deployments. The viewer flags deletes, schema and security changes, risky scripts, hard-coded sys_ids and the Default update set for you; previewing and dependency checks happen on the target instance.

1. Preview it and clear every problem. Missing references and collisions show up as preview problems on the target instance. Resolve or explain each one before you commit.
2. Look for deletes. A DELETE action removes the record on the target when the update set is committed, and deletes are easy to miss in a long list.
3. Treat schema and security changes with care. New tables and fields, ACLs and roles change behaviour for everyone. Check that each one belongs to the story you are moving.
4. Read every script. Business rules, client scripts, script includes and UI actions are where most production surprises come from: recursion from current.update(), gs.log() in scoped apps, leftover debug code.
5. Search for hard-coded sys_ids and URLs. They point at records that may not exist on the next instance. System properties are the safer home for them.
6. Check scope and the Default update set. Changes should sit in the right application scope, and nothing should be captured in Default.
7. Check what is not in the set. Groups, users and other data are not captured by update sets. If a change depends on them, they must exist on the target or travel another way.

What is inside an update set XML file?

An export is an <unload> document. It holds one sys_remote_update_set record per update set and one sys_update_xml record per captured change. Each change has an action (INSERT_OR_UPDATE or DELETE), a type, a target_name, and a payload: the full record, escaped inside a <record_update table="…"> element. That escaping is why the raw file is so hard to read.

<?xml version="1.0" encoding="UTF-8"?>
<unload unload_date="2026-10-14 09:30:00">
  <sys_remote_update_set action="INSERT_OR_UPDATE">
    <name>STRY0012345 - Auto-assign P1 incidents</name>
    <application display_value="Global">global</application>
    <state>loaded</state>
  </sys_remote_update_set>
  <sys_update_xml action="INSERT_OR_UPDATE">
    <action>INSERT_OR_UPDATE</action>
    <name>sys_script_3f2a9c1e1b2f3010a1b2c3d4e5f60718</name>
    <type>Business Rule</type>
    <target_name>Auto-assign P1 incidents</target_name>
    <payload>&lt;record_update table="sys_script"&gt; … &lt;/record_update&gt;</payload>
  </sys_update_xml>
</unload>

Common record types in an update set

The table name at the start of each sys_update_xml name tells you what kind of change it is.