What is an update set?

An update set is a group of customizations that can be moved from one instance to another. 

Update sets are one of the most important development tools that ServiceNow has ever released.  I have used other development platforms without this feature, and it was a real nightmare at times. Update sets were one of the key reasons I decided to switch to ServiceNow.

I have never written about update sets before, as they are often self explanatory. However after years of using update sets, I have learned  a variety of details that can help.

Prerequisite Reading

The ServiceNow wiki has a number of great articles on Update sets.  Update sets an important part of the platform, and ServiceNow has made an significant effort in terms of documenting their use.

• System Update Sets
• Update Set Best Practices

I am going to attempt to add upon these articles and add a new perspective to update set usage.

What is an Update Set?

From the ServiceNow Wiki

An update set is a group of customizations that can be moved from one instance to another. This feature allows administrators to group a series of changes into a named set and then move them as a unit to other instances. Update sets allow customizations to be developed in a development instance, moved to a test instance, and then applied to a production instance.

In short, update sets "record" your development efforts in ServiceNow so that you can move them from Development to Production.

Why use Update Sets?

Why use update sets?  Can I just repeat my efforts I did in development in Production?

Yes, you can.  However the sys_id, the unique identifier that marks every ServiceNow record would be different.  This can cause issues in certain scripting and configuration situations.

Also it starts to be a game of telephone.  You may think you created that customization exactly the same as in development, but may have missed a few steps in Production. You tested your customizations in development and they worked.  Now in production they work differently. Trying to diagnose what is different can be pain-staking. If you would have used update sets to begin with, this issue would not have occurred.

Can I just export the customization to xml and move it up instead?  Why should I use update sets if I can just do that instead?

Yes, you can do that. However again, you will have to remember all the changes you made to the system. This isn't easily sustainable when you are making a large number of customizations.

Can I just use update sets when I need them? I can test code in development in the Default update set right?

No. Treat the development environment with the intention that all code will be going to Production. Do any special tests in a sandbox or personal developer instance.  You may make an update in development without intending that to go to production, but another developer come along and update that.  Boom, that update is going to production!

You should always be in an update set while in a development instance.

Scoped applications

Before we really even get started with this "super guide", I want to mention I will not be talking about scoped applications much.

I personally think you should make a scoped application only if you are intending on selling it later. Using scoped applications adds another layer of complexity to update sets.  If you are just doing development for your company, you don't need to use scoped applications.

ServiceNow might have some other reasons why scoped applications are valuable.  However in my opinion, I have not seen the value for day-to-day development, it is only valuable for selling an application. Seeing how I give some of my work away for free on site or build applications for clients, I don't use scoped applications much.

What is tracked?

Update sets "record" your development efforts in ServiceNow.  However they don't record everything.

When do update sets track your customization?

• Where the table has an update_synch dictionary attribute.
• Where there is a special handler to track changes to multiple tables.
• Where the administrator has not specifically excluded a field from updates.

In short, often your code is captured in an update set, but data is not.

Why isn't just everything captured?  If you create an incident in development for testing, you would not want that incident moved up to production right?  See what I mean?

You can use the Add to Update Set button to move untracked customizations to your update set.  However you will find that doesn't work that well for larger amounts of data.  Export and import to production for large amounts of data.

More about the update_synch Attribute

It might be tempting to add the update_synch attribute to other tables.  Don't do it, it will cause issues later on.  Just use the system as it was intended for update sets.

Homepages and Content Pages

Homepages, content pages, and Performance Analytics dashboards are not added to update sets by default. You must manually add pages to the current update set by unloading them. See:

• Adding Homepages to Update Sets
• Adding Content Pages to Update Sets
• Adding Performance Analytics Dashboards to Update Sets

Default Update Set

The Default update set contains all the updates that are not in an named update set.

Try to keep the default update set as small as possible.

Sometimes on initial ServiceNow implementations, update sets are not used, and the default update set contains the updates.  This is ok, but after the initial implementation, I think update sets should be used.

Basic Process

Here is the basic process for getting update sets from Development to Production.  I will describe in more detail as well in the sections below.

Development Instance

1. Create an update set on the development instance.
2. Make customizations and changes on the development instance.
3. Mark the update set as Complete.

Test Instance

1. Log in to the test instance and retrieve the completed update set from the development instance.
2. Commit the update set on the test instance, and test customizations thoroughly.
3. If the update set has problems in the test instance, repeat the steps with development instance with another update set.

Production Instance

1. Log in to the production instance and retrieve the completed update set from the development instance. If the update set required a fix, retrieve both update sets.
2. Commit the update set on production. If the update set required a fix, commit both update sets in the order they were made.

Creating an Update Set

Update Set Example

Creation Standards

When you name an update set, don't call it "Mike's code" or similar.  Later on when you have hundreds or even thousands of update sets that might be different to find.

Name Field

I suggest using this name format, initials-application-date-short description.  For update sets where multiple people are using the same update set, use the company instead of your initials in the update set name.

If your update set is part of a series, put a number at the end of the update set name, like mlk-inc-implementation-1 and mlk-inc-implementation-2.  That way you know what load order to do the update sets in production.

Description Field

Use the description field to describe what the update set contains.  That helps you further down the road.  If the update set is the result of a story, demand, incident, problem, etc, put that in the description!

If there are any manual steps such as activating a plugin, loading data, etc, put them in the description as well.

How to create an update set

This wiki article shows you how to create an update set.  

Using Update Sets

Select Update Set

This wiki shows you how to select an update set.

Merge Update Sets

Don't merge update sets very often.  It can result in issues, and I don't really trust it myself.

There are situations when it may be necessary. Like when you are previewing an update set commit and it says, "record not found, but exists in another uncommitted update set" or something to that effect. However use that feature sparingly.

Deleting an update set entry

Accidentally modify some base system code and you don't want it in your update set? You can remove the update set entry and it will not affect upgrades then.

Just go into the update set and select the line you want to delete.  Go to the List Options at the bottom of the list and click delete.

You will receive this prompt.

Delete prompt on an update set

This prompt is very important. Be careful to only delete what you meant to delete.  

Wrong Update Set

Say you are using multiple update sets and forget to change your update set.  Your code is in the wrong update set!

This Update Set Copy/Move UI Action allows you copy/move update set entries easily.  You can also manually move each entry, but this is a nice feature to use.

Moving an Update Set to Destination Instance

1. Mark to Complete

Ready to move your update set from Development to Test or Production?

Only mark an update set as Complete only when it is ready to migrate. Once an update set is complete, do not change it back to In progress. This can cause issues in the retrieval process.  If you need to adjust an existing Completed update set, make a new update set. Don’t reopen update sets.  Very important!

This is how to Mark the update set as complete.

2. Retrieve Update Sets

You pull update sets from development using update source.  This wiki article describes Transferring an update set.

I suggest only pulling update sets from the development instance.  Don't pull update sets from dev, test, qa, as that results in duplicate retrieved update sets.

Also try to keep the uncommitted retrieved update sets to a low number.  That helps keep your pipeline of update sets manageable.

3. Preview Update Set

Once all your update sets are retrieved, you can begin previewing them to find potential problems.

This wiki article, Resolving Preview Problems, shows some ways to resolve issues if found.

You can choose one of the following options to resolve an issue: 

• Accept remote update: commit the remote update set without fixing the problem.
• Skip remote update: skip the update when you commit the update set.

In general I would say I "Skip" preview problems for the most part.  I do "Accept" preview problems if the error is something is missing.

Preview problems do happen and it is often not your fault. Don't panic if you see preview problems.  

4. Commit Update Set

After all your preview is completed, you can click commit to commit the update set.

5. Backout update sets

Don't backout update sets. If you had an issue with your update set, create a new update set and fix it. Backing out an update set can result in confusing issues.

This wiki article shows how to backout update sets.  Still don't do it.

Same goes with deleting update sets.  Don't do it.

Backups and Exports from SN Share

Reasons to backup your update sets

1. Working with multiple other developers? 
2. Are you a consultant and work in customer instances?  
3. Cloning over development?
4. Don't trust yourself completely?

If the answer is yes to any of these situations...better be backing up your update sets!  Here are how to backup your update sets.

• Export to XML

If you want to load an update set from SN Share or your update set.

• Loading an XML Update Set

Post your question or feedback

Did I miss something in this article or have a question? Post your comment below!