What Activities Are Recorded in a ServiceNow Update Set?

ServiceNow update sets are a core mechanism for packaging and migrating customizations between instances (for example, moving changes from a development instance to test and production). An update set is essentially a collection of configuration changes (forms, scripts, etc.) that have been made on an instance. Instead of manually replicating each change in another environment, administrators can capture their work in an update set and then move that update set to the target instance. This ensures that all intended customizations are transferred together as a unit. Update sets play a crucial role in managing changes between ServiceNow instances – they allow you to develop and test in a safe sandbox, then deploy those changes to production in a controlled way. In short, update sets provide a form of version control and migration for ServiceNow configurations, helping maintain consistency and reducing the risk of missing a change when promoting updates.

What Gets Recorded in an Update Set

When viewing an update set record in ServiceNow, you'll see a list of captured changes (called Customer Updates) that have been added to it. Each entry corresponds to a configuration change – for example, a modified form layout, a new script, or an updated field – that the system has tracked in the update set. The platform automatically logs these changes as XML snapshots behind the scenes, which become part of the update set's payload. Essentially, any customization to the system’s design or logic is recorded here, allowing you to migrate those changes as a batch. A wide range of configuration elements are tracked by update sets, including but not limited to:

• Table and Field schema changes – creating or altering tables and their fields (dictionary entries) are captured. If you add a new table or add/modify fields on an existing table, those changes are recorded in the update set as part of the configuration metadata.

  
  

• Form and List Layouts – changes to how forms are arranged (form designer edits) or how lists are displayed (list column configurations) are tracked. For example, if you rearrange fields on a form or create a new view, those layout modifications are included in the update set.

  
  

• Business Rules and Scripts – any server-side or client-side script changes are captured. This includes Business Rules, Client Scripts, Script Includes, UI Policies, UI Actions, and other script-driven configurations you create or modify. These are key parts of ServiceNow customization, and update sets will record the script definitions and changes.

  
  

• Workflows and Flow Designer flows – process logic changes like workflow modifications (in the legacy workflow engine) or Flow Designer flows/actions are recorded. If you build or edit a workflow for a process or create new flow logic, those definitions are added to the update set so they can be moved to another instance.

  
  

• System Properties and Configuration Records – adjustments to system properties (stored in the sys_properties table) or other system-level configurations are tracked by update sets. For instance, if you change a system property value (such as an email configuration setting or a UI preference property), that change is included.

  
  

In general, any change to a configurable item (applications, modules, menus, form views, etc.) is recorded in the current update set as long as the platform recognizes it as a customization. These captured items are what make up the content of the update set that you can then preview, retrieve, and commit on another instance.

What Does Not Get Recorded in Update Sets

While update sets cover most configuration activities, it’s important to know that they do not capture everything. Specifically, update sets exclude transactional or data records – the actual data in the system – and certain other non-configuration elements. In other words, anything that is considered runtime data or content (as opposed to system definition) will not be automatically included in an update set.

Notable examples of what does not get recorded include:

• Business data records – records such as Incidents, Problems, Change Requests, Catalog Requests, or any task records are transactional data and are not tracked in update sets. For instance, if you create or modify an Incident record, that record will not be in any update set since it’s live data, not a customization of the system’s structure.

  
  

• Users, Groups, and Roles – foundation data like user accounts, group definitions, and role assignments are not captured by update sets. These are treated as data records; creating a new user or group on one instance will not automatically be packaged for transfer. (Security roles themselves, which are essentially records in the Roles table, are also not tracked in update sets by default.)

  
  

• Email and notification records – outbound email messages, inbound emails, and their logs or any dynamic notification content are not recorded. These are transactional events. (Note that the configuration of email notifications or templates is captured, but the emails that were sent or received are not.)

  
  

• Reports and Homepages/Dashboards – UI pages that represent saved reports or classic homepages are not automatically included in update sets. For example, if you build a new report on Dev, that report definition might not be picked up unless you manually export it. Similarly, older-style homepages and some performance analytics dashboards need special handling to migrate.

  
  

• Scheduled Jobs and Schedules – Scheduled Job records (e.g. scheduled script executions or scheduled data imports) are not considered customizations by default and thus do not get captured. The system treats them as data, meaning if you create a scheduled job (like a nightly cleanup script), you won’t see it in your update set by default. Likewise, maintenance schedules or blackouts are not captured automatically.

  
  

Because update sets skip these types of data, they will not be moved to another instance unless you take extra steps. This design is intentional – update sets are meant for migrating configuration and code, not the day-to-day operational data of the platform. (Imagine if committing an update set also brought over all your incident records by accident – that would be undesirable in most cases!)

How to handle items that aren’t captured: If you need to migrate something that update sets don’t capture, you must do it manually or through a different mechanism.

ServiceNow provides a couple of approaches to handle this:

• You can use the “Add to Update Set” related link (when available on certain record types) to force-include a record in the current update set. For example, on some objects like a form view or a homepage record, there may be an Add to Update Set action that you can click to explicitly add that record into your update set.

  
  

• Alternatively, you can export the record to an XML file and then import that XML into the target instance. By exporting the data (for example, a user or a group record) as XML from the source instance and importing it on the destination, you effectively transfer the record outside of the update set system. If you perform the import while an update set is selected, the platform will even capture that import as a customer update (this is a trick to get it into an update set).

  
  

Using XML export/import is a common way to migrate things like users or scheduled jobs. In the case of scheduled jobs, for instance, one best practice is: export the scheduled job to XML, then import it into the target while your update set is active, so it gets picked up by the update set for tracking. For data like large numbers of user records or incident data, a better approach might be to use Import Sets or data load scripts rather than update sets. Always remember that update sets are not meant for moving bulky data – they are for moving customizations. If you have a few individual records that need to accompany your configuration changes (for example, a new group needed for your app), document those and migrate them through data import or script. In summary, update sets handle the “what the system is” (configuration) and not the “what the system contains” (operational data), so plan to migrate those separately.

Common Issues & Troubleshooting with Update Sets

Working with update sets is straightforward once you understand them, but a few common issues can trip up admins and developers. Below are some typical challenges and how to address them:

• Forgetting to select the correct update set: One of the most frequent mistakes is making changes while the update set is set to Default (the base system update set) or the wrong update set. The Default update set is always active when no specific set is selected, and it captures all changes not otherwise assigned. However, you cannot easily move the Default set between instances (it exists in every instance and contains out-of-box stuff). If you accidentally did work under the Default update set or a wrong set, those changes won’t be in the update set you plan to migrate. Solution: Avoid this by always selecting or creating a named update set before you begin configuring. If you do realize your changes went to the wrong place, you have a couple of options: you could manually redo the changes in the correct update set, or use an admin trick to move entries to another update set. The key is to double-check the Update Set picker (usually found in the banner or settings) whenever you start work on a batch of changes. This prevents the “whoops, I was on Default!” scenario.

  
  

• Missing records in the target instance after committing: A common issue is “something is missing” after you move an update set. For example, perhaps a form doesn’t show a field that you added, or a script is erroring because a referenced record isn’t there. This can happen for two reasons: (1) The item was never captured in the update set to begin with, or (2) it was captured, but the target instance lacks a related record that wasn’t included. For the first case (not captured at all), refer back to the section on items not recorded – you might have, for instance, added a data record like a new Choice value or a user that wasn’t picked up. You would need to manually transfer that (export XML or recreate it on the target). If it’s the second case (a missing dependency), the update set commit will usually flag it during preview. You might see an error like “Could not find a record in [Table X] for [sys_id ABC] referenced in this update” during the preview or commit. Solution: Always Preview your update sets before committing them on a target instance . The preview process will identify if there are missing dependencies or conflicts. If a missing record dependency is reported, you have a few options: bring over the needed record (perhaps via a separate update set or XML import), or use the preview’s option to “Accept remote update” if you intentionally want to ignore that missing reference. In general, it’s best to ensure all required pieces are in place. For example, if you created a new Category that a business rule refers to, make sure that Category (which is a data record) is also created in the target (via import or as part of a setup script). The preview will help catch these gaps so you can resolve them before clicking Commit.

  
  

• Update set conflicts and collisions: If two update sets (or an update set and existing configuration on the target) modify the same item, you can encounter a conflict. For instance, two different update sets might both modify the same business rule in different ways – when you try to commit, ServiceNow will detect that and mark it as a collision. Similarly, if an admin manually changed something in Production that you are also delivering via update set from Dev, that’s a conflict. Solution: Use the Update Set Conflict Detection/Resolution features. When previewing an update set, ServiceNow will list any conflicts and allow you to compare versions. You may choose to merge changes or decide which version to keep. In practice, avoiding conflicts is about coordination: if multiple developers work in parallel, consider using separate update sets and then merging them intentionally, or using Team Development tools to reconcile changes. If a conflict is detected on commit, you might need to manually adjust the final configuration on the target. The platform’s guidance is to review conflict details and either accept one version or skip the update from the set if it’s not needed. Always communicate with your team to ensure you’re not overwriting each other’s work with update sets.

  
  

• Not marking update sets as “Complete” before retrieval: After finishing your changes in a development update set, you must mark the update set Complete to make it available for retrieval in another instance. Only update sets in the Complete state can be retrieved and imported to another instance. Forgetting this step is an issue that will block your progress (the target instance won’t see the update set if it’s still "In Progress"). Solution: Once you have verified and finished all intended changes in an update set, change its State to Complete (in the Update Set form). It’s good practice to do this only when you’re truly ready to move it (because continuing to modify a set after marking it complete is not advised). After marking complete, go to the target instance and use Retrieved Update Sets to pull it over. If you realize you need to add something after completion, do not re-open the same update set – instead, create a new follow-up update set for the additional change. ServiceNow explicitly warns not to change a completed update set back to "In Progress," as this can cause retrieval problems. So, finalize your update set content, complete it, and leave it closed; any further tweaks can go in a new update set as needed.

  
  

• General best practices not followed: A few best practices can save you from headaches with update sets. For example, don’t bundle unrelated changes in one update set – if you’re working on multiple features or projects, use separate update sets for each. This way, if one set needs to be backed out or delayed, it doesn’t hold up others. It also makes testing easier, since each update set should ideally represent a coherent set of changes. Also, use descriptive names and descriptions for your update sets. Instead of naming an update set “Update Set 1”, name it something like “IncidentManagementEnhancements_April2025” – this will make it clear what the set is for when you or others see it in the future. Another tip: keep track of any manual steps or data loads that need to accompany the update set (for instance, if a Scheduled Job needs to be run or some reference data needs importing, note that in the update set description or a deployment plan). And finally, always test your update sets in a non-prod instance (like a test or QA environment) before deploying to production. This will catch issues with missing pieces or conflicts so you can fix them in a lower environment first.

  
  

By being mindful of these common issues and following best practices, you can significantly streamline the update set migration process and avoid unexpected surprises during deployment.

Conclusion

In summary, a ServiceNow update set is a package of configuration changes – it records things like table definitions, fields, scripts, workflows, UI changes, and system properties that you modify. Update sets are essential for moving customizations between instances (e.g. from Dev to Test to Prod) in a consistent and tracked manner, ensuring that what you tested in a sub-production environment is exactly what you deploy to production. Remember that update sets do not capture transactional data or records such as incidents, user records, groups, or other live data. For those, you must use other migration methods or recreate the data on the target instance as needed.

When working with update sets, always adhere to best practices: plan your changes and group them logically (for example, one update set per feature or task), and give each update set a clear name and description for easy identification. Always test and preview update sets in a testing environment to catch missing dependencies or conflicts before final deployment. It’s wise to maintain a checklist of any items that need manual moving (like reference data) so nothing is overlooked during the release. And as a rule, only mark an update set Complete when you're ready to transfer it, and avoid reusing or reopening completed sets.

Update sets are a powerful feature of the platform for ServiceNow customization migration and change management. By understanding what they track (and what they don't), you can use them effectively to deploy enhancements with confidence. For deeper learning, consider exploring ServiceNow’s official documentation on System Update Sets and the ServiceNow Developer Site guides, which cover advanced topics like update set best practices, team development, and collision resolution. The ServiceNow Community forums and knowledge base are also rich resources – you’ll find many Q&A threads discussing real-world update set scenarios and solutions. By leveraging these resources and following the guidelines above, you’ll be well-equipped to manage update sets efficiently and keep your instance deployments smooth and error-free.