Update Set sys_ids: What Actually Happens When You Move Them Between Instances

[Daniel Draes]

Two Transport Mechanisms, Same Behaviour

There are two common ways an update set ends up on a target instance:

Retrieve Update Set is the platform-native mechanism for pulling an update set from a remote instance. It's what ReleaseOps uses under the hood when deploying across pipeline stages.

XML export/import is the manual path — export an update set to XML, then upload it on the target via Load Update Sets from XML.

Both produce the same result: the update set lands in the sys_remote_update_set table (Retrieved Update Sets) with a brand new sys_id. The original sys_id from the source instance is gone from sys_update_set on the target — but it isn't lost.

Where the Original sys_id Goes

ServiceNow preserves the source sys_id in the remote_sys_id field on the sys_remote_update_set record.

<remote_parent_id/>
<remote_sys_id>662e2bb487cc8fd07c54db183cbb3568</remote_sys_id>

This field is the stable identity of an update set across instance boundaries. No matter how the update set was transported, remote_sys_id always points back to its origin.

This also explains what happens when you upload the same XML a second time: rather than creating a duplicate, ServiceNow matches on remote_sys_id and overwrites the existing retrieved update set record. The origin sys_id is the key, not the local one.

Committing Creates Yet Another sys_id

Once you commit a retrieved update set, ServiceNow creates a new record in sys_update_set — the local update set table. This committed record gets its own sys_id, distinct from both the source sys_id and the retrieved update set sys_id on the target.

That's three different sys_ids for what is conceptually the same update set:

1. The original sys_id on the source instance (sys_update_set on DEV)
2. The retrieved update set sys_id on the target (sys_remote_update_set on TEST)
3. The committed local update set sys_id on the target (sys_update_set on TEST)

The link between #3 and #2 is the remote_sys_id column on sys_update_set — a reference field pointing back to the sys_remote_update_set record. Follow that reference and you can always trace a committed update set back to where it came from.

The Two-Step Lookup

If you need the local committed sys_id on the target instance — for example, to pass it to a Run Instance Scan activity in a ReleaseOps pipeline — you can't use the source sys_id directly. You need to resolve it:

Step 1 — Find the retrieved update set record on the target:

Table: sys_remote_update_set
Query: remote_sys_idSTARTSWITH662e2bb487cc8fd07c54db183cbb3568

Step 2 — Find the committed local update set:

Table: sys_update_set
Query: remote_sys_id=<sys_id from step 1>

The sys_id you get from Step 2 is the one the target instance knows about — and the one you need for anything that runs locally against it.

Practical Takeaway for ReleaseOps

The OOTB Run Instance Scan activity will fail if you feed it the DEV sys_id and point it at TEST — that record simply doesn't exist there. Instead, wire in the two-step lookup above after the commit activity and pass the resolved TEST sys_id to the scan.

One caveat worth remembering: don't capture the TEST sys_id at commit time and store it for later. If your flow fails and is resumed after the commit has already happened, that first-commit path won't fire again. Always resolve the sys_id fresh via the lookup — it's reliable at any point after the update set has been committed.

The Mental Model

Stage	Table	sys_id	Tracks back via
Source instance	sys_update_set	Original sys_id	—
Retrieved on target	sys_remote_update_set	New sys_id	remote_sys_id → source
Committed on target	sys_update_set	New sys_id	remote_sys_id → retrieved record

The remote_sys_id field is the through-line at every stage. Wherever your update set travels, that field is how ServiceNow — and your automations — can always find it.