---

Many publishing methods are available today for deploying applications on the ServiceNow platform. The current methods are as follows:

• ServiceNow store repository
• Application repository
• GIT repository
• Team development repository
• Update set

Did you know that Update sets are ServiceNows least preferred method of publishing applications?

Despite this, they still have a place on the platform and won’t go anywhere soon. Based on my LinkedIn poll, most ServiceNow developers still use update set to move configuration changes across their ServiceNow instance.

I believe they are still the best method for operational teams to deliver enhancements across the platform.

In this post, I will share my top tips and tricks for using Update sets that I have learnt throughout my development career.

Define a consistent, valuable naming convention

OOB, the Short description field on the update set table is only 80 characters. Use it wisely!

Avoid redundant information. I often see developers add dates or initials to short descriptions. This type of metadata isn’t necessary since it is captured in other fields on the Update Set record. I typically start with a reference to the specific requirement that triggered the need for ServiceNow development in the first place (e.g. STRY1001 or INC1001) and a short descript, usually no more than five words. Since I am naming my sets based on a requirement, I only capture work related to that requirement named in that update set. This will allow you to trace configuration changes to the origin requirement, serving as in-platform documentation.

Following that, I include the application scope acronym (which is useful for update set batching) and end with a number that I increment each time an update is deployed to the next environment. If you end on a number, ServiceNow will automatically increment it if you create a new update set immediately.

Check your customer updates are in the right scope before completing

When working across multiple scopes, tracking which application you are in and which update set is currently open can be hard. It is confusing, right? You are not the only one who gets confused; sometimes ServiceNow does too. Update sets have an application, and it should not be possible for an update from another scope to find its way in. Unfortunately, this does happen from time to time. And when it does happen, you are prevented from committing the entire Update set, with an error message that looks something like this:

Cannot commit Update Set ‘<update set name>’ because: Update scope id ‘1167622b01473231007f47563dbb9a71’ is different than update set scope id ‘global’. Resolve the problem before committing.

Like most things, prevention is better than a cure. You could manually check for any customer updates with an application scope that differs from the Update set… Or you could download my tool that automatically sorts customer updates in the wrong scope into new update sets and prevents closure when mixed updates are detected from ServiceNow Share.

Leverage instance scan

ServiceNow’s Instance Scan is a powerful capability that allows users to perform comprehensive scans on their ServiceNow instances. It identifies issues, risks, and best practices violations, providing actionable recommendations for optimization and security. Instance Scan helps organizations maintain a healthy, secure, high-performing ServiceNow environment with customizable scans, automation features, and integration capabilities.

Instance scans can also be run against your update sets. Leverage this to check that your organisations and ServiceNow’s leading practices are being adhered to before polluting your upstream ServiceNow instances with dodgy code. It is easy to miss. However, you can scan your update set via the related links.

Instance scan can also be configured to run automatically on your update sets if you forget to scan them. This helps embed this into your development process.

Fellow Developer MVP Mark Roethof has blogged extensively on this topic, authoring 37 articles and prebuilt scan packages on ServiceNow Share, with a comprehensive list on the ServiceNow Community.

Leverage update set batches

Remember when you had to merge update sets before deployment to prevent needing to move tens or hundreds of update sets? This irreversible technique always had me crossing my toes and fingers, hoping my changes would go the same way they came out. Thanks to Update Set batching, we no longer have to worry. Update set batches do have other uses that can make dealing with releases and application scopes much easier.

Back it up!

Need to backup Update Sets before a clone? Simply whack all your in-progress update sets into a batch, complete, and export. This will give you peace of mind and works across multiple scopes (unlike the preserve update set functionality in clone profiles).

Always batch for scopes

I always batch my Update sets when dealing with application scopes, even if I know I am only working with a single scope and with a single requirement. I will always have a parent update set for global scope changes or a container without changes. My scoped application change then sits in a child, with the appropriate naming convention. Each application scope with changes will sit underneath as a child. When preparing releases, I only need to add the global parent for each requirement increment to my master, rather than switching scopes for each application. The naming convention also comes in handy for seeing this from the slush bucket, where there is no way to determine which scope the update sets belong to without filtering.

All scoped children are added. If I had tried to add one of the scoped update sets while I was in global, nothing would have happened…

Batch per release, requirement increment.

Batch update sets as soon as they hit another instance

Sometimes you don’t know what will be in your release when it hits your test environment. Some things get tested in time; some things don’t. Some things fail to test and don’t make the release window. Sometimes another developer has already pulled your batch into production, and despite it being added to another release batch, it isn’t included upstream if it was already pulled.

For example, let’s say my update set ‘STRY1234.Incident uplift 2’ was only included in the release batch at the last moment. Another change went through the previous day, pulling the existing batch into prod. If I include it as part of my release, then only commit the release update set batch… part of STRY1234 will never be committed. It will already be sitting separately in production.

So… always create a container “In progress” update set batch after you commit update sets into an upstream environment to hold them until they are ready. Call it what you want – “Pipeline” or “Awaiting release allocation” – just be consistent and make it a habit. When you do your release, take the Update sets you to need out of that holding batch and into the desired release.

Add data to update sets

Not everything is captured in update sets (only tables that extend sys_metadata or have the update_sync attribute). For example, Employee Center topics are not captured, and various other organisational data tables are. To reduce or eliminate the manual steps required in your deployments, you may consider adding some of this data to your update sets, which will also help preserve sys_ids across your instances. With over 13,000 downloads, Add to Update Set Utility is the most robust and complete utility. Install in your instance and manually force any record into an Update set. It will even make sure everything is in the correct scope.

Check child update sets counts to match the source environment

As a precaution, in case the previous measure hasn’t worked, check that your release update batch child update set count matches that of the downstream environment. This will ensure that any other batch hierarchies have not been pulled or forgotten about. If the count is wrong, you might want to delete all retrieved but not committed update sets and pull again. But do this with extreme caution – you do not want to delete committed update sets accidentally!

Check preview errors and actions

When faced with a sea of update set preview errors, it can be difficult to remember what actions you took on them previously – especially in the heat of the moment of a stressful change.

Never fear if you forget to list your remediation actions in your implementation plan! Update set preview errors and actions are stored in a table in ServiceNow! Return to the completed update set from the source instance and select Show All Preview Records.

Consider including this check in your standard implementation plan template (You have one of those, right? :p)

Set parent to ignore after committing to production

After committing an update set to production, ServiceNow recommends setting it to ignore. Fellow Developer MVP Nia McCash has written about Why you should set your completed update sets to ‘Ignore’ on production on the ServiceNow Community. I would only add that you I only do this to the batch base update set of the hierarchy, otherwise you will lose your update set relationships. When setting a child update set to ignore, the parent field gets cleared and you will lose the traceability of your requirements to your release.

Fix forwards – avoid backout

Backout should be your last resort if you ever need to revert a change. Backing out update sets rarely works, often failing halfway through, leaving you even more of a mess to clean up. In over ten years of developing the ServiceNow platform, I can only think of one or two times backout has worked. It is best not to rely on the ‘backout’ button when forming your backout plan. When an updated set creates a new field, this almost always fails.

When planning your change, try to write a fix-forward backout plan. This might detail steps to deactivate any new configuration in the test environment and move into production via another update set to nullify the change effectively. It is also a good idea to feature toggle new features with system properties, so you can easily disable them if something goes wrong with testing. This may even involve reverting versions in tests and forcing them into new update sets.

---

That will be it for update sets for today!

Did I miss any tips and tricks?

Comment below and share!