Q: What causes Update Set Not Containing Expected Changes in ServiceNow?

Wrong update set was active when changes were made — Navigate to System Update Sets > Local Update Sets and check the 'State' column - your changes are in whichever update set shows 'In progress'. Also check sys_update_xml table filtered by your user and recent timestamps to see which update set captured your changes. Changes made in wrong application scope — Check the sys_update_xml table for your recent changes and look at the 'application' field. If it shows 'Global' instead of your target application, or a different application entirely, the scope was wrong when changes were made. Record types not captured by update sets — Data records (like incidents, users), scheduled jobs, email accounts, and certain system properties don't get captured in update sets. Check the sys_update_xml table - if your changes aren't there at all, they're likely non-capturable records. Update set not properly retrieved and committed on target — On the target instance, check System Update Sets > Retrieved Update Sets to verify the update set shows 'Loaded' state. Then check if it was previewed and committed - look for any preview errors in the Preview Problems related list. Changes overwritten by later modifications — Check sys_update_xml table for multiple entries of the same record with different update sets. The most recent change wins, so if someone modified the same record in a different update set after yours, your changes get masked.

Question 1

What causes Update Set Not Containing Expected Changes in ServiceNow?

Accepted Answer

Wrong update set was active when changes were madehigh likelihood

Navigate to System Update Sets > Local Update Sets and check the 'State' column - your changes are in whichever update set shows 'In progress'. Also check sys_update_xml table filtered by your user and recent timestamps to see which update set captured your changes.

Changes made in wrong application scopehigh likelihood

Check the sys_update_xml table for your recent changes and look at the 'application' field. If it shows 'Global' instead of your target application, or a different application entirely, the scope was wrong when changes were made.

Record types not captured by update setsmedium likelihood

Data records (like incidents, users), scheduled jobs, email accounts, and certain system properties don't get captured in update sets. Check the sys_update_xml table - if your changes aren't there at all, they're likely non-capturable records.

Update set not properly retrieved and committed on targetmedium likelihood

On the target instance, check System Update Sets > Retrieved Update Sets to verify the update set shows 'Loaded' state. Then check if it was previewed and committed - look for any preview errors in the Preview Problems related list.

Changes overwritten by later modificationslow likelihood

Check sys_update_xml table for multiple entries of the same record with different update sets. The most recent change wins, so if someone modified the same record in a different update set after yours, your changes get masked.

Question 2

How do you fix Update Set Not Containing Expected Changes in ServiceNow?

Accepted Answer

How to fix it First, identify where your changes actually went. Navigate to System Update Sets > Local Update Sets and look for any update sets with 'In progress' state that aren't the one you expected. Check the sys_update_xml table. Filter by your user name and today's date. Look at the update_set field to see which update set actually captured your changes. If changes went to the wrong update set, you have two options: either move the customer update records to the correct update set, or merge the update sets. To move records, open each sys_update_xml record and change the update_set field to point to your target update set. For application scope issues, check the application field in the sys_update_xml records. If they show 'Global' but should be in your custom application, you'll need to recreate the changes while in the correct scope. For non-capturable records (data, email accounts, etc.), document them in a separate deployment guide. Navigate to System Definition > Tables and check if the table has Allow configuration checked - if not, changes won't be captured. Before making any new changes, always verify your current update set by checking the application picker in the top banner shows your target application, and the update set picker shows your target update set. Once you've consolidated all changes into the correct update set, complete it by going to System Update Sets > Local Update Sets, opening your update set, and clicking Complete Update Set. Export the update set as XML and import it on your target instance via System Update Sets > Update Sources or Retrieved Update Sets > Import Update Set from XML.

Question 3

How do you prevent Update Set Not Containing Expected Changes in ServiceNow?

Accepted Answer

Always verify the correct update set is selected in the application navigator banner before starting any development work. Set your Default Update Set in System Properties > My Preferences to your current working update set to avoid accidentally using 'Default'. Create a habit of checking the sys_update_xml table after making significant changes to confirm they were captured in the expected update set. For data records and other non-capturable changes, maintain a separate deployment checklist document alongside your update sets. Use update set naming conventions that include your name and date to make it easier to identify where changes went when troubleshooting.

Update Set Not Containing Expected Changes in ServiceNow

Symptom

Possible Causes

Debugging this in a real instance?

Solution

How to fix it

Prevention Tips

Test Your Knowledge