5 ServiceNow® Update Set Errors And How to Get Around Them

featured

We’ve all been there. You’ve done all the work, you’ve debugged and perfected your code, you’ve collected your precious updates into an update set and moved it to the next instance up and then… BOOM! Your ServiceNow update has problems. Fear not! The truth is, most update set problems look scarier than they are. In this blog, we’ll examine a few of the most common problems that occur, and show you how to fix them.

⚠️ Error type: Missing object
Example: “Could not find a record in sys_ui_policy referenced in this update”

What’s going on:

Have you ever created a bunch of records for a build, made some changes, and then deleted one that you didn’t need? Unfortunately, that seemingly harmless change is what’s causing your error. ServiceNow is expecting a record in this instance that didn’t make it into the update set, usually because it was deleted in Dev. This also might happen if the table the record is in isn’t captured in the update set.

How to fix it:

Click “Find missing record” and see what happens. If it’s a record you deleted, you’ll get a message that says, “Record not found”. At this point, your best bet is to just skip that update. You don’t need it.

If it’s a record that just didn’t make it into the update set, “Find missing record” will pull it up. At this point you have choices. You could export the record from Dev and import it into your current instance, or you could go back and set the record’s table to be captured in an update set before creating a new update set to capture it in. Both options require you to remember which action you’ve taken so that you can upload the record or apply the new set when you get to the production instance.

⚠️ Error type: Collision
Example: ”Found a local update that is newer than this one”

What’s going on:

This can happen when there are multiple people working in an instance and using their own update sets. One makes a change to a record or workflow that the other has modified and then pushes their update set first. The other is left wondering why anyone is making changes to the thing they are working on.

How to fix it:

Click “Compare with Local” and you’ll get a list comparing the two versions of the item. If you see something in the list that is in your older version but not the new one, you may want to select “Accept Remote Update” to go with your version. If there are things in the new version that are not yours, choose the new version by selecting “Skip Remote Update”

⚠️ Error type: Uncommitted update
Example: “Could not find a table field (u_case.u_reference) referenced in this update, but did find it in another uncommitted update set”

What’s going on:

This one happens most often when you have several uncommitted update sets for the same component or multiple copies of the same uncommitted update set on an instance, perhaps after a clone down.

How to fix it:

If you’ve got multiple sets for the same component, the best way might be to go back to your development instance and merge those sets before pushing to your next instance. If the problem is a duplicate set after a clone, you can either remove the duplicates and run the preview again or accept all the changes and then verify with thorough testing that everything committed correctly.

⚠️ Error type: Table to be deleted has data
Example: “Found a row in the table that is going to be deleted”

What’s going on:

If your build included deleting a table, ServiceNow will check before deleting to make sure there isn’t data on that table that will be lost. If there is data, you’ll get this error.

How to fix it:

Verify that you don’t need the data in the table. If you do, skip this update and leave the table as is. If you don’t need that data, accept the update and ServiceNow will delete that data as well as the table that it’s in.

⚠️ Error type: Application scope validation issue
Example: “Could not find a record in sys_scope for column sys_scope referenced in this update”

What’s going on:

If you’re working in a scoped app and that scope doesn’t exist on the instance you’re pushing to, you’ll get this error.

How to fix it:

Only apply sets on instances that contain the scope you’re working in.


So that’s it! Not so scary after all. But what common errors did we miss? Feel free to contact us to let us know what ServiceNow error messages keep you up at night, and we may address that in a future post.

If you have other questions about Cerna Solutions and what services we offer for ServiceNow, enter your information below, and we’ll be happy to speak with you about how your team can take ServiceNow to the next level.

Have questions?  Feel free to contact us to talk about how you can get the most from your ServiceNow practice.