Backing out of update sets
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-07-2014 02:19 AM
Hi All
I have another question regarding backing out of update sets. I am new to SNOW Administration and had little 'hand over' before I took over. The procedure I was taught to follow regarding developments was to build an update set in the development environment. (I have learnt since to have many small update sets for a development rather than one huge one). Transfer to test once that particular stage of the development is complete and finally once it is tested and approved, transfer and apply the update set (sets) to Production. It was explained to me that if there was a problem after the update set was applied to production that it could be backed out.
I have two questions regarding this:
1 If you are applying multiple update sets to production as part of a development and you need to back out, it is only in the last update set that the back out button is available. If I were to back out of the last update set, would the back out button become available in the second to last update set I applied. If so, and I backed out of this second to last update set would the back out button become available on the third to last update set etc. so that eventually I would be able to back out of all the update sets I had just applied?
2 Is it generally considered good practice to rely on the back out functionality if something goes wrong when you move to production or not?
thanks
Sue

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-07-2014 02:37 AM
Hi Sue,
Answer to Question 1:
You can back out changes to existing records for the most recently committed update set only.
Answer to Question 2:
It is good to go with the back out option in case you want to revert back the changes.
In case you want to backout many update sets at a time.I think you can deactivate the changes manually on production
Please let me know if you have any questions.
Thanks,
Pradeep Sharma
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-08-2014 01:13 AM
Thank you for your reply and for answering question one for me.
I am not sure what you mean by 'deactivate the changes manually on production', can you give me any more clues as to what this is?
Thanks
Sue

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-08-2014 01:30 AM
Hi,
Thanks for the update.
I mean if there were any minor changes you want to do(Not recommended).
As a best practice it is always good to capture the changes again in update set and move to production.
Thanks,
Pradeep Sharma
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-07-2014 02:54 AM
HI,
We follow all guide lines provided by serviceNow
System Update Sets - ServiceNow Wiki
Update Sets Best Practices - ServiceNow Wiki
I am not sure about your point # 1.
But If we move our updateset first from DEV to TEST and then PROD it's good and saf.
Due to some Update set some problem is comeup on PROD in that case it's good to backout your update set So that our user does not face any problem.
But if it's a smal problem and our developer is able to give some fix ASAP. In that case we not need to backout our updateset we just need to move our new update set.
I think If we First move our updateset from Dev to TEST and we did not get any Error.
It will must work currect on PROD also.
whenever we move any updaye set to PROD we must tack care about manula things (Like System Property,
MID server value, Inbound E-mail conf etc..)