Update Set Toolkit: Fix scope mismatches and stale records before they break your deployment

[GassanHirra]

Hi everyone,

I originally wanted to publish this as an article, but the portal kept redirecting me to the question form, so here it is as a discussion instead.

I built a small toolkit to take some of the pain out of update set management and deployments. It adds four buttons to the Update Set form, aimed at the two problems that most often break a deployment without warning: records captured in the wrong scope, and records that have changed on the instance since they were captured.

1. Reconcile Scopes: fixing scope mismatches

This resolves the familiar commit error:

Cannot commit Update Set 'X' because: Update scope id 'A' is different than update set scope id 'B'. Resolve the problem before committing.

Reconcile Scopes finds every sys_update_xml record whose application doesn't match the update set it belongs to. For each mismatched scope, it creates a correctly scoped update set, moves the affected records into it, and adds the new sets to a batch under the original. A single commit still deploys everything.

Before making any changes, it shows a preview of the full batch hierarchy: each set, its scope, the record count, sample record names, and the name each new set will get. Nothing is written until you click Apply.

2. Refresh Stale Updates: preventing silent reverts

Here's the scenario. You create a business rule in update set A and edit it in update set B. Later, a colleague edits the same rule in update set C, and you're never told. When you deploy A and B, you silently overwrite their changes on the target instance.

Refresh Stale Updates compares every captured payload in the batch against the record's current version on the instance and lists anything that's out of date. For each record, it shows who changed it, when, and which update set holds the newer version, and flags whether that set is inside or outside your batch. Refreshing pulls the current version into the update set that already holds the record.

For individual records, there's also a Refresh from current version option under Actions on selected rows… on the Customer Updates related list.

3. Check Readiness: a pre-commit health check

This shows everything that could block or complicate a commit on one screen:

• Stale records
• Scope mismatches
• Update sets still marked as Default
• Empty Application fields
• Scopes that aren't installed on the target instance
• Child update sets in the wrong state
• Duplicate update names across the batch (only the newest one survives a commit)
• Delete-type updates
• Dictionary changes
  
  

4. Undo Scope Reconcile: safe rollback

The toolkit keeps a run history, and Undo can roll back either type of run:

• Scope reconciles: moved records return to their original update sets, and any auto-created sets left empty are deleted.
• Refreshes: the original payloads are restored from a journal.

Any record that has changed since the run is skipped, so later work is never overwritten.

I'd love to hear your feedback, edge cases I haven't covered, or ideas for what to add next.

https://developer.servicenow.com/connect.do#!/share/contents/6955965_update_set_scope_reconciler_fix...