Week 2 of 8
Review skipped changes
When ServiceNow upgrades an instance, it does not apply its changes to objects you have customized. Those records land in Skipped Changes to Review under Upgrade Center, Upgrade History. Each one is a decision: keep your version, revert to ServiceNow’s, or merge the two by hand.
Every record you retain means you keep your behavior and give up ServiceNow’s fix or feature for that object. That is a risk decision, and it needs a test behind it.
This week: turn the skipped list into owned, tested decisions
- After the dev upgrade, export Skipped Changes to Review and Claim Outcomes to Review from the upgrade record.
- Start with Priority 1 and 2 (UI pages and macros first). Give every record an owner and a due date.
- For each record decide Retained, Reverted or merged, and write one sentence on why. "We always keep ours" is not a reason.
- Link every Retained or merged record to a test. Capture the fixes in an update set so the same decisions travel to test and production.
- Look at Customization Unchanged too: if ServiceNow has not changed the object, ask whether your customization is still needed at all.
Number of the week
Priority 1
is how ServiceNow ranks skipped UI pages and UI macros, the most visible place a retained customization hides a change.
Source: ServiceNow docs, Review skipped records (Yokohama)Use this week
- ServiceNow Skipped Changes Review Log →
Priority, disposition, decision, reason and linked test for every skipped record, with red flags for untested retains.
- Change Impact Analysis Log →
Trace each customized object to the processes and tests it affects.
Next week: none of this works on a stale instance. We make the clone part of the test plan.
Get the playbook in your inbox, one week at a time
Subscribe free and every template in the library is yours.