Bite #2: Fixing Update Set Blunders

It’s the end of the day and I go to close my update set… and just my luck, I’ve been working in the wrong update set for the past 30 minutes. How do I fix it?

The Problem

How do you get configuration/code from the wrong update set to the correct one?

The Wrong Way

As I’m sure many of you have figured out… it’s *technically* possible to move the update record from one update set to another. However, if I were to take this approach to fix my dilemma, I would have almost assuredly ran into problems. It’s all to easy to do one of the following:

  1. Miss a critical update record, such as one of the three records that are a part of defining a new table or field.
  2. End up with multiple update records for the same business rule or client script in your destination update set.
  3. Move an update record that doesn’t belong in the new update set.

The Right Way

How should I fix it then? Well, unfortunately, the right answer carries some bad news.
The only *right* way to fix having used the wrong update set is to…

  1. Manually undo all of your work in the wrong update set (delete dictionary fields, revert business rules, etc).
  2. Redo all of the work in the correct update set.

Definitely not the answer you wanted, but it’s the safest way, and the only method espoused by ServiceNow.

The Bottom Line

Stay away from sys_update_xml records. Bite the bullet and take the long way ’round… And this time try to avoid the two bottles of whiskey “for the way”.

Categories: Developers, Scripting Tips

Tags: , , , ,

1 reply

  1. Hi,

    I have a doubt, what happen if we move the customer updates alone to the newly created update set?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: