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:
- Miss a critical update record, such as one of the three records that are a part of defining a new table or field.
- End up with multiple update records for the same business rule or client script in your destination update set.
- 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…
- Manually undo all of your work in the wrong update set (delete dictionary fields, revert business rules, etc).
- 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”.
