In the ServiceNow environment, an update set is defined as a group of customizations that users can move from one instance to another. Thanks to update sets, users can develop customizations in a development instance, move them to a test instance, and apply them to a production instance.
Update Sets are among the most important development tools ever released by ServiceNow because they record all your development efforts, so you can move them from development to production.
Customizations include Tables, Fields, Forms, Views, Client Scripts, etc. Users can use update sets to make changes they intend to apply to other instances and to make sure that instances are in sync.
Breakdown of Basic Process
The basic process for getting an update set from the stage of development to production is the following:
- Proceed to create an update set on the development instance
- Make changes and customizations. Use meaningful names and descriptions in your update sets.
- Mark it as Complete.
- First, log in to the test instance and retrieve the update set from the development instance.
- Next, commit to retrieved update set on the test instance and proceed to test the customizations. Always run a preview just prior to committing an update set.
- In case of any issues in the test instance, return to the development instance and create another update set.
- Locate the production instance, log in, and retrieve the update set from the development instance. In case the update set needs to be fixed, be sure to complete the fixes in another update set, and retrieve both update sets.
- Next, commit the update set on production, or if it requires a fix, commit both in the order they were made.
Don’t delete any update sets, unless you have merged update sets. Prior to committing, consider merging update sets that you’re going to promote together. Once they are merged, delete the original sets to avoid later confusion.
Always use one update per workflow. Never use multiple update sets to transfer a workflow change. Before you close an update set, always publish the workflow.
When You Don’t Need to Use an Update Set
There are situations in which there is no need for you to use an update set. For example, you don’t need to use it when you’re using data export/import sets to move data from one source to another. When not within a custom update set, all changes will be tracked in the Default update set. That allows you to see what you’ve changed and used the information for resolving any problems. Be sure not to touch the ‘Default’ update set or its properties or values, and don’t delete anything from it.
When to Backup Update Sets
Be sure to backup update sets when:
- Cloning over development
- Working in customer instances as a consultant
- Working with several other developers
- You don’t trust yourself completely