Making Update Sets Smarter - Free Tool

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.

AD6DxAk.png

Jump to the Download

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.

Note that all of the features and functionality listed below, can be configured, or switched on or off, from the System Update Sets > Smarter Update Sets Properties module in the Application Navigator.

Mixed-Scope Update Sets

Like I mentioned above, working with scoped apps can often result in complicated mixed-scope Update Sets. The worst part about this problem, is that there is no indication that this problem exists, until you’ve already closed the Update Set, imported it into another environment, and are attempting to deploy it!

Once you identify the issue, you have to go back to your dev environment, create two (or more) new Update Sets (one for each scope), and manually move the updates from the old set to the two new sets, depending on their scope.

Pro-tip: Splitting Update Sets or moving updates from one Update Set to another, can be accomplished relatively painlessly with our Update Relocator tool!

This Update Set will deploy a Script Include and Business Rule that will make it so that when you attempt to mark an Update Set as “Complete”, it’ll check if it contains mixed-scope updates. If so, it will prevent that Update Set from closing, and show a message indicating why.
If you made any other changes in addition to marking the State as “Complete”, it will accept those changes; it just reverts the state change.

This functionality is controlled by the “sng.update_sets.prevent_mixed_scope_sets” system property, which you can switch on or off from the System Update Sets > Smarter Update Sets Properties module in the application navigator.

Duplicate Update Set Names

dupe name.png

Duplicate Update Set names in the same scope can be really confusing, especially when you go to deploy them. You wouldn’t want to risk deploying the wrong Update Set in production!
This sort of confusion is part of why it’s important not to re-open an Update Set once you’ve closed it, but that’s neither here nor there.

This tool will notify you if you’ve entered an Update Set name that’s already been used, and can optionally prevent Update Sets from being saved if they have a duplicate name.

Update Sets with Checked-out Workflows

It can’t be just me that’s painstakingly built a complex project or catalog item with a custom workflow, then deployed it… only to find that I forgot to check in the workflow before closing the Update Set. It just can’t be. Right?

Okay mister/missus perfect, maybe you haven’t done that - yet! And thank your lucky stars, because this tool makes it so you never have to experience that level of shame and despair. This will prevent Update Sets which contain Workflows that are checked out, from being closed.
If you make more than one change (such as updating the description and the state), it’ll just reject the state change rather than aborting the whole update.

Default Update Set

This last one is kind of a no-brainer. Off the top of my head, I can’t think of a situation where I’ve ever needed to modify the “Default” Update Set, except to try to fix something that someone else accidentally broke.

It’s easy for newer admins or developers (and even the legendary greybeards on occasion) to accidentally make a change to the Default Update Set, when they meant to either create a new set, or to update an existing one. They might accidentally, or without thinking, close the Default set, or they might change its name, or accidentally uncheck the “Default set” checkbox (if it’s on the form in your environment).

Because the Default Update Set is so important, it’s usually worth protecting.
While this tool only protects the set client-side (since we don’t want to interfere with certain server-side logic), it should effectively prevent users from accidentally making changes that they shouldn’t, to the default set.

Like all of these features, this one can be switched on or off from the Smarter Update Sets Properties module in the application navigator, but there is also a property which allows you to specify which fields should be protected on the Default Update Set, if the feature is turned on. By default, only the name, state, parent, release_date, and completed_by fields are protected, but you can add any other OOB or custom fields you’d like to protect, to this system property. Just remember that this only applies client-side.

Also - New in v1.2, the Smarter Update Sets tool can now alert you if you accidentally make certain changes in the Default Update Set.

All of the functionality described above, is enabled by this Update Set. Click the Download button above, to download the Update Set XML file, which you can deploy into your instance. Once deployed, refresh your browser window to see the “Smarter Update Sets Properties” module in the application navigator.

Changelog

v1.3

  • Updated default value for the “Prevent duplicate Update Set name” setting to false.

    • Tool will still alert you about duplicate Update Set names by default, but will not strictly prevent them unless you enable this setting.

    • This change was made in order to prevent an issue where Update Sets with duplicate names would be prevented from being properly imported or retrieved, which can be quite annoying.

v1.2

  • Added “Alert on changes in default Update Set” functionality, which will put up a notification if it detects that an admin is making changes in the default update set.

    • Certain tables are excluded, such as sys_data_source. Additional tables can be excluded from the “Smarter Update Sets” settings page.

    • Configuration options also exist for disabling the notification altogether, disabling the notification for scoped apps, and how it should be determined whether the default update set is actually the default.

v1.1

  • Bug-fix, more configurability in settings, and more robust handling of scope issues.

v1.0

  • Initial release