ServiceNow Update Set Collision Checker

Live

Drop all the update sets of a release. See which records collide, what depends on what, deletes still in use, and a safe commit order.

Cheat sheet Report an issue

Drop the update sets of your release

Export each update set with Export to XML and drop all the files here at once: two, ten or fifty. You get collisions, what depends on what, and a safe commit order. The files are read in your browser and never uploaded.

How to use it

  1. Export every update set of the release with Export to XML.
  2. Drop all the files on the page at once. Add more later by dropping them again.
  3. Fix what is red, use the recommended order, and copy the release plan into the change ticket.

One set to review? The Update Set XML Viewer shows every change in a single set, with the risky ones flagged.

What it checks

Collisions
The same record in more than one update set, which version ends up on the instance in your order, and a line diff of what changed.
Older version on top
A set whose version of a record is older than another set’s, committed after it, so it quietly undoes newer work.
Order problems
A set committed before the set that creates the table, field or record it needs.
Deleted but still used
A set deletes a script include, property, field or record that another set still uses.
Check on the target
Groups, users and other data referenced by sys_id, and sys_ids written into scripts. Update sets do not carry them.
Set notes
Default update sets, and sets whose changes span several application scopes.

How the commit order is chosen

The checker reads what every set creates, deletes and points to, then applies three rules in this order:

  1. Commit-time needs first. A table must exist before its fields, and a record must exist before another record points to it by sys_id. These are the dependencies that break a preview or a commit, so they decide the order.
  2. Newest version last. When a record is in several sets, the set with its most recently updated version goes after the others, so newer work is not overwritten by older work.
  3. Then in the order the sets were finished. Everything else follows the time of each set’s last change, which is how most teams already commit.

When two sets need each other, no order works for both. The checker says so; commit them together in a batch, or move the shared records into one set.

Commit time and run time

Some references must resolve as the update set is committed: a field on a table that does not exist yet, or a reference field that points to a record by sys_id. Others are only read when the record runs: a script include called from a business rule, a property read with gs.getProperty(), an event in a notification, a field in an email template. The first kind decides the order. The second kind only needs every set to be committed before the feature is used, and the checker lists it under “Used across sets”.

What the checker cannot see

  • The target instance. It cannot tell whether a group, table or newer local change already exists there. Preview every set on the target as usual.
  • Platform records. Out-of-box tables and fields exist everywhere, so only custom ones (u_ and x_) count as created by a set.
  • Every kind of reference. Dependencies are read from field values and scripts. A name built at run time, such as a table name in a variable, is not found.

Frequently asked questions

What is an update set collision in ServiceNow?

Two or more update sets contain the same record, for example the same script include or business rule. On the target instance, the version from the set committed last is the one that stays. If that version is older than one committed before it, newer work is silently undone.

Does preview not catch this?

Preview compares each incoming update set with what is on the target at that moment. If you preview every set first and then commit them, the sets are never compared with each other, so an older version committed last can slip through. The checker compares all the sets of a release with each other before anything is loaded.

How do I export several update sets?

Open each update set and choose Export to XML under Related Links, then drop all the files here at once. A file that contains several update sets works too. You can add more files at any time by dropping them on the page.

In what order should I commit update sets?

Sets that create tables, fields or records others point to go first. Where a record is in several sets, commit the set with its newest version last. Everything else in the order the sets were finished. The checker applies these rules and lets you rearrange the order to see what changes.

Why does the order not matter for script includes and properties?

A business rule that calls a script include, or a script that reads a property, only needs it when the code runs, not when the update set is committed. As long as every set of the release is committed before anyone uses the feature, their order does not matter. These links are still listed under “Used across sets”, and they matter when a set deletes something another set uses.

What should I do about a collision?

Usually, commit the set with the newest version last. If both versions contain changes you need, combine them in the newest one, or merge the update sets before you move them (System Update Sets › Merge Update Sets). Compare the versions here first to see exactly which lines differ.

Why should I check groups and users on the target?

Update sets capture configuration, not data. An assignment rule that points to the HR Onboarding group points to that group’s sys_id. If the group does not exist on the target with the same sys_id, the reference is empty after the commit. The checker lists every such reference so you can check them before you start.

Are my update sets uploaded anywhere?

No. The files are read with JavaScript in this browser tab. Nothing is sent to a server and nothing is stored, so you can use it with client and production update sets.

ServiceNow Encoded Query TranslatorTurn ^-separated encoded queries into plain English, edit them visually, and generate GlideRecord code and URLs. ServiceNow Update Set XML ViewerDrop in an exported update set and review every change: deletes, schema and ACL changes, risky scripts, and a checklist for the ticket. ServiceNow Script Best-Practice CheckerPaste a business rule, client script or script include and get line-by-line warnings for common ServiceNow mistakes, with the fix. ServiceNow REST / Table API BuilderBuild REST calls for any table, catalog orders, changes, the CMDB and attachments, and copy cURL, PowerShell, Python, Node, Postman or RESTMessageV2 code. ServiceNow Glide API Cheat SheetA searchable reference for GlideRecord, gs, GlideDateTime, GlideAjax and g_form, with copy-ready examples checked by the Script Checker.