Update Sets

Update Sets in ServiceNow: A Complete Guide for CAD Exam Preparation

Understanding Update Sets in ServiceNow

Update Sets are one of the most fundamental and critical concepts in ServiceNow development. Whether you are building applications, customizing existing modules, or preparing for the ServiceNow Certified Application Developer (CAD) exam, a thorough understanding of Update Sets is essential.

Why Are Update Sets Important?

Update Sets serve as the primary mechanism for moving customizations and configurations between ServiceNow instances. In a real-world ServiceNow environment, organizations typically maintain multiple instances — such as Development, Test/QA, and Production. Update Sets allow developers to:

• Track changes made in a development environment systematically
• Bundle related changes together into a logical grouping
• Migrate customizations from one instance to another in a controlled manner
• Maintain an audit trail of what was changed, when, and by whom
• Support rollback capabilities by providing a record of modifications
• Enforce governance over the development and deployment lifecycle

Without Update Sets, moving changes between instances would be chaotic, error-prone, and nearly impossible to manage at scale.

What Is an Update Set?

An Update Set is a group of configuration changes that can be moved from one ServiceNow instance to another. When a developer makes changes to an instance — such as creating a new Business Rule, modifying a UI Policy, adding a field to a table, or creating a Script Include — those changes are automatically captured in the currently selected Update Set.

Key characteristics of Update Sets include:

• They are stored in the sys_update_set table
• Individual tracked changes (customer updates) are stored in the sys_update_xml table
• Each instance has a Default update set that captures changes when no other update set is selected
• Only one update set can be the current update set for a user at any given time
• Update Sets capture changes to customizations and configurations, not data records (with some exceptions)
• They track changes made through the application interface, not changes made via background scripts or direct database manipulation by default

What Update Sets Track vs. What They Don't

Update Sets DO track:
• Business Rules, Client Scripts, UI Policies, UI Actions
• Script Includes, Scheduled Jobs, Workflow activities
• Form layouts, list layouts, and related lists configurations
• Dictionary changes (new fields, field attribute changes)
• ACLs (Access Control Lists)
• System Properties changes
• Notifications and Email templates
• Service Catalog items and variables
• Application menus, modules

Update Sets DO NOT track:
• Data records (e.g., individual incident records, user records)
• Scheduled job execution history
• Homepage and dashboard configurations (these are personal or can be tricky)
• Some system settings that are instance-specific
• Attachments (by default, though this can be configured)

Note: The setting glide.update_set.track.attachments can be set to true to include attachments in Update Sets.

How Update Sets Work: The Full Lifecycle

1. Creating an Update Set
Navigate to System Update Sets > Local Update Sets and click New. Provide a meaningful name and description. The update set is created in the In Progress state.

2. Setting the Current Update Set
A developer must select their working Update Set as the current update set. This is done via the update set picker in the top-right area of the banner frame or via the System Update Sets module. All configuration changes made by that user will be captured in the selected update set.

3. Making Changes
As the developer creates or modifies configurations (e.g., a new Business Rule or a modified form layout), each change generates a customer update record (sys_update_xml) linked to the current update set.

4. Completing the Update Set
Once all desired changes are captured, the developer changes the update set state to Complete. A completed update set cannot have additional changes added to it. If further changes are needed, the update set can be moved back to In Progress.

5. Exporting/Retrieving the Update Set
The completed update set must be moved to the target instance. This can be done in two ways:
• Export as XML: The update set is exported as an XML file from the source instance and then imported into the target instance via System Update Sets > Retrieved Update Sets > Import Update Set from XML.
• Retrieve from Remote Instance: If the target instance is configured with a remote instance connection, it can directly retrieve completed update sets from the source instance via System Update Sets > Retrieved Update Sets. You must first set up a remote instance connection under System Update Sets > Update Sources.

6. Previewing the Update Set
Before committing, the update set must be previewed on the target instance. The preview process compares the incoming changes against the target instance to identify potential conflicts. This is a critical step that should never be skipped.

7. Resolving Conflicts
During preview, conflicts may arise. Common conflict types include:
• Collision detected on a record that was updated locally: The same record was modified in both the source and target instances.
• Record not found in target instance: A change references a record that doesn't exist in the target.
• Skipped - Newer version exists: The target instance has a more recent version of the record.

Conflicts must be resolved before committing. Resolution options typically include:
• Accept remote update: Use the incoming change from the source instance
• Skip remote update: Keep the current version on the target instance

8. Committing the Update Set
After preview and conflict resolution, the update set is committed. This applies all the changes to the target instance. Once committed, the changes become part of the target instance's configuration.

Update Set States

Understanding the states is crucial for the exam:

• In Progress: The update set is active and can capture changes
• Complete: The update set is closed; no more changes can be captured. It is ready for migration.
• Ignore: The update set is marked to be disregarded (not commonly used but available)

For Retrieved Update Sets on the target instance:
• Loaded: Retrieved but not yet previewed
• Previewed: Preview has been run; conflicts may need resolution
• Committed: Successfully applied to the target instance

Important Concepts Related to Update Sets

Batch Update Sets (Update Set Batches)
Multiple related update sets can be grouped into a batch. Batches allow you to preview and commit multiple update sets together in a specific order, ensuring dependencies between update sets are respected. This is particularly useful when multiple developers have been working on related features. Navigate to System Update Sets > Update Set Batches to create and manage batches.

Default Update Set
Every instance has a Default update set. If a developer does not select a specific update set, changes will be captured in the Default update set. Best practice is to never use the Default update set for intentional development work. It makes tracking and migrating changes much more difficult.

Backing Out an Update Set
ServiceNow provides the ability to back out a committed update set. This reverts the changes that were applied. However, backing out has limitations — it restores the previous version of each record from the local update history, but it may not perfectly undo every change, especially if subsequent changes have been made on top of the committed changes. Use this feature carefully.

Merge Update Sets
Multiple local update sets in the In Progress state can be merged into a single update set. This is useful when a developer realizes that changes spread across multiple update sets should logically be combined.

Parent and Child Update Sets
When using Scoped Applications, update sets work within the scope of the application. The application's update set is linked to the application scope. Understanding the relationship between application scope and update sets is important for the CAD exam.

Best Practices for Update Sets

• Always create a dedicated update set for each feature, story, or change request — never use the Default update set for development
• Use descriptive names that include a reference number (e.g., story number, change request number)
• Preview before committing — always review and resolve conflicts
• Keep update sets focused and small — avoid putting too many unrelated changes in a single update set
• Test in a sub-production instance before moving to production
• Use Update Set Batches when multiple update sets have dependencies
• Document what is included in each update set
• Be aware that changing your current update set mid-task can split related changes across update sets

Common Pitfalls

• Forgetting to switch from the Default update set before making changes
• Making changes in the wrong update set and not realizing until later
• Skipping the preview step and committing directly (can cause issues)
• Not resolving all conflicts before committing
• Including unintended changes in an update set (e.g., accidental form layout changes)
• Failing to complete an update set before attempting to retrieve it on another instance

Update Sets vs. Application Repository

For the CAD exam, it is important to understand the distinction:
• Update Sets are the traditional method of moving changes and are ideal for global scope customizations and configurations
• Scoped Applications can be published to an Application Repository and installed on other instances — this is a more modern, application-centric approach
• Scoped application development still uses update sets internally to track changes, but the deployment mechanism differs


Exam Tips: Answering Questions on Update Sets

The CAD exam frequently tests knowledge of Update Sets. Here are targeted tips to help you answer these questions correctly:

1. Know the Lifecycle Cold
Many questions test whether you know the correct sequence: Create → Set as Current → Make Changes → Complete → Retrieve/Export → Preview → Resolve Conflicts → Commit. If a question asks what the next step is after retrieving an update set, the answer is Preview, not Commit.

2. Remember: Preview Before Commit
This is one of the most commonly tested points. You must preview an update set before committing it. Any answer that suggests committing without previewing is incorrect.

3. Default Update Set Behavior
If a question describes a scenario where a developer forgot to select an update set, the changes went into the Default update set. The fix is to move those customer updates to the correct update set — this can be done by opening the individual customer update records and changing their update set reference.

4. Only One Current Update Set
A developer can have only one current update set at a time. If a question implies a developer is working with two simultaneously, that is not possible.

5. Completed Update Sets Cannot Capture Changes
If a question describes a scenario where additional changes need to be made, the update set must be moved back to In Progress or a new update set must be created.

6. What Gets Tracked
Be very clear on what update sets track and what they don't. A common trick question involves data records — update sets do NOT track regular data. If a question asks how to move data between instances, the answer is typically an import set, a data export, or a CMDB data transfer — not an update set.

7. Conflict Resolution
Understand the types of conflicts that can occur during preview. Questions may present a scenario describing a conflict and ask how to resolve it. Remember the options: accept the remote update or skip it.

8. Update Set Batches
Know that batches exist and their purpose. If a question mentions needing to move multiple related update sets in order, the answer likely involves Update Set Batches.

9. Merging Update Sets
Remember that only local update sets in the In Progress state can be merged. You cannot merge completed or retrieved update sets.

10. Backing Out
Know that backing out a committed update set is possible but has limitations. It is not a guaranteed perfect undo mechanism.

11. Remote Instance Configuration
To retrieve update sets directly from another instance, you must configure an Update Source (remote instance connection) with proper credentials. This is configured under System Update Sets > Update Sources.

12. Process of Elimination
For multiple-choice questions, eliminate answers that suggest skipping the preview step, using the Default update set as a best practice, or tracking data records with update sets. These are common distractors.

13. Scenario-Based Questions
The CAD exam often uses scenario-based questions. Read the scenario carefully and identify what went wrong or what step is needed next. Common scenarios include:
• A developer's changes are not appearing in the target instance (likely forgot to complete the update set, or the update set was not retrieved/committed)
• Changes ended up in the wrong update set (solution: move customer updates to the correct update set)
• Conflicts during preview (solution: resolve conflicts before committing)
• Need to move both configuration and data (solution: use update sets for configuration and a separate method for data)

14. Understand Scope Context
When developing within a scoped application, changes are tracked in the application's update set automatically. Global changes go into the global scope's update set. Questions may test whether you understand which scope captures which changes.

15. Team Development (Advanced)
While not as heavily tested, be aware that ServiceNow offers Team Development capabilities for managing code from multiple developers. This provides features like code comparison and collision detection across instances. Know that it exists and its basic purpose.


Summary

Update Sets are the backbone of ServiceNow's change management and deployment process. They provide a structured, traceable, and reliable way to move configurations between instances. For the CAD exam, focus on understanding the complete lifecycle, what is and isn't tracked, the importance of previewing before committing, conflict resolution, and best practices around naming and organizing update sets. Mastering these concepts will not only help you pass the exam but will also make you a more effective ServiceNow developer in practice.