Introduction to Update Sets
While creating custom applications in ServiceNow, the changes need to be moved safely from where they are built to where they will be used. Changes made by a developer are not automatically visible but have to be captured, packaged, and transported.
ServiceNow Update Sets are the perfect tool to solve it all. It is the fundamental concept that ensures administration and development in the ServiceNow environment. In this chapter, we focus on the basics of update sets, including what they are, their importance, tables, and how default update sets work.
What is Update Set in ServiceNow?
ServiceNow Update Set is a container that stores all configuration changes you make in the ServiceNow application. The container groups a set of configuration changes so they can be moved, tracked, and deployed together. It is a portable, trackable record of changes in an instance so that it can be reviewed, exported, and applied elsewhere.
Every ServiceNow instance has one update set marked as current where new configuration is recorded by default.
Importance of Update Sets
Update sets in ServiceNow are used to solve the problem of migrating configurations between environments by overwriting someone else’s changes or redoing it manually. The major things that make it important are:
- Controlled Deployment: Rather than creating a table, field, or business rule manually in every environment, you just create it once and move the update set. It avoids human error and saves a lot of time.
- Environment promotion: Update sets create a pathway to promote configurations from Dev → QA testing → Production pipeline. It keeps each environment configuration in sync and in a reviewable way.
- Team Collaboration: When multiple teams and developers work together, they can work in their own Update set. This allows developers to work on their configuration without affecting others’ tasks.
- Safe rollback: If any deployment turns out to be wrong, the update set can easily be backed out. It reverts all the changes unless any configuration depends on them from the target instance.
- Backup and Recovery: Update sets are self-contained packages, which, when exported in XML, create a portable backup of configuration work unaffected by the live instance.
Update Set Tables
Each Update set is stored in the Update Set table, and any customizations in the update set are added to the Customer update table. There are four different update set tables, including:
| Table | Label | What it stores |
|---|---|---|
| sys_update_set | Update Set | The Update Set records itself, including name, description, status, application scope, and parent/child relationships. You see this under Local Update Sets. |
| sys_update_xml | Customer Updates | One record per individual configuration change captured within an Update Set. This is the table that actually tracks what changed. |
| sys_update_version | Versions | It stores version history, one record per change made to a tracked/customized object over time. It is the way in which ServiceNow preserves history across repeated deployments instead of overwriting it. |
| sys_remote_update_set | Retrieved Update Sets | This is where you can preview the Update Set before committing it. By previewing the Update Set on this list, you can see which conflicts it will cause and can decide to either commit the Update Set or delete it. |
As a ServiceNow professional, remember never to directly edit the sys_update_xml records. They should always be managed using the standard Update Set UI and process.
Default Update Sets
Default update sets in ServiceNow are created automatically when a new scoped application is created. The global scope of every instance has a Default Update Set by default, and when a new application is created, a new Update Set for that Application gets created. These default sets exist to provide configuration changes a place to go when an admin or developer has not activated their own update set. It is like a fallback container.
Some important things about a default update set are:
- They exist in every instance’s global scope.
- If there is no current update set, all new changes are added to the Default update set.
- The system redirects changes when an Update set is marked complete. Complete update sets do not accept changes. It helps keep track of any new changes.
What does Update Set capture?
It is important to understand the major aspects of update sets, including what they capture and what they don’t. Regarding the configuration that an update set captures, the following things are included:
- Tables and their dictionary entries
- Fields (and field labels)
- Application menus and modules
- Business rules
- UI policies
- Assignment rules
- ACLs (Access Control Rules)
- Roles created as part of building out a table/application
- Configured (not personalized) list layouts and form layouts
Apart from what is captured, the two things that update sets do not capture are:
- Records: Update sets do not capture the rows of the table created. They are used to track the structure you create but not the data that is entered into it. So, while deploying any application via update sets, you will only get tables and fields; the data has to be imported separately.
- Personalizations: Anything that is personalized, like lists or dashboards, is only for individual users. These get stored in ServiceNow but are not tracked or saved in update sets. Admins also cannot manage or export them using Update sets.
What’s Next?
As we discussed, what Update sets are and what they capture and what they don’t. In the next topic, we will be covering how to create and manage update sets in ServiceNow.
Next Topic
