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.
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
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.
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.
- March 2019
- Feb 27, 2019 Making Update Sets Smarter - Free Tool
- November 2018
- October 2018
- September 2018
- Jul 23, 2018 Admin Duty Separation with a Single Account
- Jun 19, 2018 Improving Performance on Older Instances with Table Rotation
- Jun 4, 2018 New Free Tool: Login Link Generator
- May 29, 2018 Learning ServiceNow: Second Edition!
- April 2018
- March 2018
- Feb 11, 2018 We have a new book!
- November 2017
- Sep 12, 2017 Handling TimeZones in ServiceNow (TimeZoneUtil)
- July 2017
- June 2017
- May 2017
- April 2017
- Mar 12, 2017 reCAPTCHA in ServiceNow CMS/Service Portal
- Dec 20, 2016 Pro Tip: Use updateMultiple() for Maximum Efficiency!
- Dec 2, 2016 We're Writing a Book!
- Nov 10, 2016 Chrome Extension: Load in ServiceNow Frame
- September 2016
- July 2016
- May 17, 2016 What's New in Helsinki?
- Apr 27, 2016 Customizing UI16 Through CSS and System Properties
- Apr 5, 2016 ServiceNow Versions: Express Vs. Enterprise
- March 2016
- Feb 25, 2016 Understanding Attachments in ServiceNow
- Feb 22, 2016 Reference Field Auto-Complete Attributes
- Feb 6, 2016 GlideRecord & GlideAjax: Client-Side Vs. Server-Side
- Feb 1, 2016 Make Your Log Entries Easier to Find
- Jan 29, 2016 A Better, One-Click Approval
- Jan 25, 2016 Quickly Move Changes Between Update Sets
- Jan 20, 2016 Customize the Reference Icon Pop-up
- Jan 7, 2016 ServiceNow: Geneva & UI16 - What's new
- Jan 4, 2016 Detect/Prevent Update Set Conflicts Before They Happen
- Dec 28, 2015 SN101: Boolean logic and ServiceNow's Condition Builder
- Dec 17, 2015 Locate any record in any table, by sys_id in ServiceNow
- Dec 16, 2015 Detecting Duplicate Records with GlideAggregate
- Dec 11, 2015 Array.indexOf() not working in ServiceNow - Solution!
- Dec 2, 2015 Understanding Dynamic Filters & Checking a Record Against a Filter Using GlideFilter
- October 2015
- Aug 27, 2015 Easily Clone One User's Access to Another User