Update Sets are how you track and promote changes to your ServiceNow environment from one instance to another (for example, from Dev to Test, and then from Test to Prod). They’re a great tool for keeping things orderly, but they don’t always tie up into a neat little bow when you need them to - especially ever since the implementation of Application Scope, on which you can see my angry ramblings here.
If you work with scoped apps (such as the HR or Vulnerability apps, or a myriad of others), you’ve almost certainly run into custom development being done in a scoped Update Set, but somehow containing Global (or non-scoped, which are basically the same as Global) records, and you’ve undoubtedly seen the dreaded error message, telling you that you can’t deploy an Update Set because it has updates from multiple scopes.
Or maybe you’ve built a Workflow in dev, checked it out, made some changes, published it, checked it out again, made some more changes, and then promoted it… but then - D’OH! - you realize you forgot to check the workflow back in before promoting your Update Set!
Or maybe you’re in an environment that has a few super green ServiceNow developers, or at a company that’s extremely liberal with granting the admin role, and you’ve had to clean up the mess after someone else renames or deletes the “Default” Update Set in Global or some other scope.
In my years as a ServiceNow admin, developer, and architect, I’ve seen all of those issues, and in each case, I’ve written a little script to save a little sanity, and make my life just a little bit easier by preventing these issues; and in this article, I’m going to share them with you.
Click below to read on! Read More