Previous post in the series: GlideRecords 101

---

A preface: Application Scopes

Application scopes are essential to understand before learning about update sets. Application scopes are basically containers that keep everything related to a specific application together, but also separate from other applications. This allows applications to be secure and ensures that changes to one product do not impact every other product.

For example, Employee Center is an application built by ServiceNow in its own scope. All of the building blocks that power Employee Center live within its application scope. Similarly, there is an application scope called Human Resources: Core (if you have HRSD). A lot of the HR-related configurations live in this scope. The HR Case [sn_hr_core_case] table is an example of this. If you want to make an edit to the HR Case [sn_hr_core_case] table, you need to be in the Human Resources: Core scope. You cannot be in the Employee Center scope, since that's not the rightful container. This does not mean the two scopes cannot interact, but instead just serves as a boundary. ServiceNow will prompt you when you are in the wrong application scope and try to make edits to something outside of your jurisdiction:

What is an Update Set?

(Almost) any time you make a change to ServiceNow, your changes are tracked. For example, if you create a business rule, a record of that change will be tracked. Similarly, if you update a business rule, or you update a table, or you create a new field on catalog item, a record of that change will be tracked. These changes are tracked in what can essentially be thought of as a folder -- an update set.

Why use update sets?

Update sets are important because they allow you to isolate your specific changes and migrate just those changes to different environments/instances.

Imagine you are a developer are you are tasked with updating a form layout in your development environment/instance. You need to shift the Assignment group field so it sits directly under the Number field. Easy enough. But what if that change needs to happen in your test environment? Or production? To avoid having to make the same change in multiple different environments, you instead make that change once, in the development environment, in an update set, and then upload your update set to each subsequent environment (more on that later).

How can I create an update set?

Head on over to System Update Sets > Local Update Sets. If you click to create a New update set, you'll see a screen that looks like this:

What these fields mean

Here's what you need to know:

• Name: this is pretty self explanatory, but it's important to be descriptive about what your particular update set is doing. Generally, you would include the Story Number for what you're working on. Make sure to ask your platform admin for the standard naming convention to ensure that you and other developers aren't just all winging it.
• State: leave this as In progress; that's how you signal that you're actively working on it. We'll touch on this more in a later section of this post.
• Parent: this optional field is super useful if you want to batch updates together. So if your team has 10 stories this sprint, you can group them under a Parent update set, and then you'll be able to move all of them together.
• Release date: I've personally never used this, but consult your platform admin if your team uses it.
• Description: here, you can provide additional information about what the update set is intending to do.
• Application: this gets auto-filled by the system, depending on which application scope you're currently in.

Switching between update sets

Depending on what level of access you have or what version of ServiceNow you're on, this may look a little bit different. But generally, you can change update sets via the top-right side of your navigation bar in ServiceNow. You may have to click the Globe icon to open the picker:

Update sets live within an application scope. So if you aren't finding your update set, make sure you've picked the proper application scope. In the example above, I'm in Global.

How do I actually use an update set?

Good news is: update sets are automatic. For the most part. Most changes you make, configuration-wise, will be captured an update set. So if you create a business rule, or update a form layout, that will be automatically captured and tracked as part of an update set.

If you were to update a record (e.g. update the assignment group of an Incident [incident]), that generally would not be tracked as an update set. This is because that data element probably doesn't need to be moved "up the stack." For instance, you probably don't need to move your assignment group update for INC000123 into your production environment, since INC000123 in your development environment is probably a test record.

How do I know if my changes are going to be captured? How can I ensure they are captured?

There are about 300 OOTB tables that get captured in update sets. According to KB0535262, any table that has an attribute of update_synch=true will be captured in an update set. (You can find out if a table has this attribute by going to the Dictionary [sys_dictionary] table and filtering on the Attributes column. More info is provided in the KB article; but note it is best practice to avoid adding this attribute to custom tables.)

But the best way to see if your update got captured is to look at your update set. Open your update set (from System Update Sets > Local Update Sets) and look at the Customer Updates related list.

If you want to force an update that isn't captured per the attribute mentioned above, you can always Force it to the update set. Huh? Don't worry, I've already posted an article about that functionality.

Pro-tip: How to move updates between different update sets

If you were accidentally in the wrong update set when you made a change, have no fear! This is super easy to fix. Simply open the update set that you created the change in and scroll down to the Customer Updates related list.

Right-click on the breadcrumbs and open in new window:

And then make sure you have the Update set field; double-click to adjust:

How do I move update sets "up the stack?"

If this is your first time doing this, I recommend reaching out to your platform admin or senior developer for assistance. Different teams have difference procedures for moving update sets, but I'll cover the basics below below.

Completing your update set

When you're done, and your changes have been tested, and you have the thumbs up to move "up the stack" (e.g. from DEV to TEST), navigate back to your update set. If you have batched update sets together (meaning, you have assigned a Parent update set), and they are all ready to go, open the Parent update set. The first-next step is to change the State field to Complete. Once you save the record, you'll see a new related link appear, allowing you to Export to XML:

This will initiate a XML file download to your computer. Save this some place safe. I like to re-name the file so I know what it is.

Retrieving your update set

Now that you have exported your update set to XML, the next step is to retrieve it. To do so, head over to System Update Sets > Retrieved Update Sets. Scroll to the bottom of the page and choose the related link Import Update Set from XML.

Upload your file and you'll be taken back to the Retrieved Update Sets page. Find your update set (hint: it'll have a State of Loaded). From that page, you will Preview how the changes are read by the newer ServiceNow instance. You may get a few errors at this stage; it is important to review each error to determine what action to take. Unfortunately, I cannot guide you on what steps to take, but note that it is common to Accept remote updates to ensure that your most-recent updates from DEV overwrite whatever is necessary in TEST.

Parting notes

I hope this post was helpful! I didn't think this post would be as long as it ended up being. If you're still stuck, I'd encourage you to ask for help from your platform or development team. The basic crux of update sets, though, is that they help contain your changes and keep you more organized.

---

Next post in series: Groups and Roles.