---
sourceDocument: Yokohama Build or modify applications
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/yokohama/application-development

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama Build or modify applications

ft:clusterId :

    - cadev

bundleId :

    - cadev

workflow :

    - Development, Data, and Analytics


---

# Customizations tracked by update sets

# Customizations tracked by update sets {#ariaid-title1}

* Release version: Yokohama
* 
* Updated January 30, 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read

Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Customizations tracked by update sets

Update sets in ServiceNow track customizations to application tables, fields, and records under specific conditions, primarily focusing on configuration information rather than transactional data.
They help transfer configuration changes between instances but are not intended for large data migrations or task/process data.
Show full answer Show less  

## Key Features

* **Tracking Conditions:** Update sets track changes where the table has the `updatesynch` dictionary attribute, where special handlers exist for multi-table changes, and where fields are not excluded by administrators.
* **Special Handlers:** Certain customizations like workflows, form sections, lists, related lists, choice lists, system dictionary entries, and field labels require special handlers to package changes properly into a single update set entry.
* **Choice Lists:** Update sets manage new and updated choice options distinctly, tracking only changes relevant to extended tables without affecting base tables.
* **Dictionary Changes:** Update sets block dictionary changes that cause data loss, such as removing tables or altering column data types in incompatible ways. Manual intervention is needed for table removal and some data type changes.
* **Homepages and Content Pages:** These are not included by default in update sets and must be manually added by unloading them into the update set. Homepages are being replaced by responsive dashboards and Analytics Center dashboards in newer instances.
* **Application-Specific Update Sets:** Separate update sets are created per application to ensure proper application of access settings during commits.

## Important Considerations

* **Do not add the `updatesynch` attribute manually:** It is restricted and misusing it can cause serious performance and availability issues.
* **Avoid mixing update sets with Application Repository:** Use only one method exclusively for scoped app development to prevent commit errors and skipped changes.
* **Large choice lists and data migrations:** Avoid large choice lists in update sets due to commit performance issues. For data migration, use import sets or instance-to-instance imports instead of update sets.
* **Data loss warnings:** Deleting columns via update sets can cause data loss if data exists in the target instance, and a warning will be shown before committing such changes.

## Practical Outcomes for ServiceNow Customers

Using update sets allows customers to efficiently capture and migrate configuration customizations between instances while preserving application integrity and access controls. Customers should use update sets primarily for configuration updates and rely on import sets or web services for larger data migrations. Following best practices, such as avoiding manual addition of restricted attributes and not mixing update sets with Application Repository development, helps maintain system stability and prevents common issues during deployment.  
Update sets can track customizations to application tables, fields, and
records.
Update sets track customizations under these conditions:

* Where the table has an update_synch dictionary attribute.
* Where there is a special handler to track changes to multiple tables.
* Where the administrator has not excluded a field from updates.
{#customizations-tracked-update-sets__ul_lck_hbh_fr}

In general, update sets capture configuration information but not task or process data. For
example, update sets track service catalog item definitions and related configuration data
like variables and variable choices. However, if you test the service catalog by placing
orders, update sets do not track order requests, items, and catalog tasks.

Update sets have a limited capacity to transfer data as application files. For larger data
transfers, export data and import it with an import set or web service.

Do not combine the usage of both Update Sets and the Application Repository for scoped app development. This will result in numerous issues, including skipped changes, commit errors, and more. Once you have installed an
application from the Application Repository, you must continue to develop and publish to the Application Repository for all future development. If you decide to develop an application using update sets, you must continue to use
that method exclusively.

## update_synch attribute

To see the list of tables where customizations are tracked, navigate to System DefinitionDictionary and filter on attributes CONTAINS update_synch.  
Warning:  
Do not add the `update_synch` attribute to a dictionary record. When improperly used, this attribute can cause major performance issues or cause the instance to become unavailable. Because of this, the `update_synch` attribute is not accessible to customers.  
A default rule blocks the use of the `update_synch` attribute on a table for which it is not predefined to avoid the following issues:

* Some core tables require special update handling because they represent information on multiple tables. When the `update_synch` attribute is added to these tables, duplicate update records are created, causing major conflicts that are difficult to troubleshoot and repair.
* Using the update_synch attribute to migrate data records between instances can cause performance issues, because it is not intended for this purpose. To migrate data, use an instance-to-instance import. See [Import sets](https://www.servicenow.com/docs/access?context=c_ImportSetsKeyConcepts&version=yokohama&pubname=yokohama-integrate-applications&ft:locale=en-US).

{#customizations-tracked-update-sets__ul_img_3dh_fr}

## Special handlers

Some changes require special handlers because they represent information on multiple tables. These changes are packaged into one update set entry so that all records are properly updated when the customization is committed. The following changes are tracked with special handlers:

* Workflows
* Form sections
* Lists
* Related lists
* Choice lists
* System dictionary entries
* Field labels

{#customizations-tracked-update-sets__ul_qzq_32h_fr}  
Warning:  
The form sections, lists, related lists, choice lists, and field labels special handlers delete and reinsert records. This might cause unexpected results and data loss if there are fields referencing the tables.

## Choice lists

Update sets store both new and updated choice options as separate records in the Update
Version `[sys_update_version]` and Customer Update
`[sys_update_xml]` tables. For example, you create a new Activity
`[u_activity]` table that extends the Task table. You then add a new choice
option to the Task state field that is only visible for your extended table (for example,
My State).

When you publish these changes as an update set, the update only contains update and
version records for the choice you added to the u_activity table. The choice options in the
task table are unaffected.  
Warning:  
Do not use large choice lists in update sets. Doing so leads to excessively long update set commits.

## Dictionary changes

Usually, using update sets prevent you from applying dictionary changes that result in data loss. Blocked dictionary changes include:

* Removing tables
* Changing a column data type
{#customizations-tracked-update-sets__ul_w1n_r51_mv}

Update sets do not track the removal of tables from the system dictionary. Instead,
customers must manually remove tables from the target instance. While update sets track data
type changes, the target instance skips any change that results in data loss and instead
adds a log message about the action. Customers can use the log to manually make data type
changes on the target instance.  
Note:  
Update set previews do not check for type mismatch problems since the target instance skips changes resulting in data loss. Also, using update sets to delete a column from a table can cause data loss in certain circumstances. If there is data in the column on the target instance, that data is deleted, as well as the column itself, when the update set is committed. A warning message appears if you attempt to commit an update set that deletes a column. The message states that there are one or more delete updates that cause the data to be deleted, and it specifies what delete updates there are.

## Homepages and content pages

Homepages and content pages are not added to update sets by default. Add pages to the
current update set by unloading them.  
Important:  
The functionality found in homepages, arranging information from your instance to tell a story about your data, is found in dashboards on new instances. On upgraded instances with Next Experience enabled, users can view existing homepages if they have a direct URL, but they can't create or edit them. Responsive dashboards and Analytics Center dashboards take over homepage functionality.{#customizations-tracked-update-sets__deprecation}

Use the [Homepage
deprecation help tool](https://www.servicenow.com/docs/access?context=homepage-deprecation-help-tool&version=yokohama&pubname=yokohama-now-intelligence&ft:locale=en-US) to convert the homepages on your instance to responsive dashboards.{#customizations-tracked-update-sets__deprecation-tool}  
For more information, see:

* [Dashboards in the Analytics Center](https://www.servicenow.com/docs/access?context=analytics-center-dashboards&version=yokohama&pubname=yokohama-now-intelligence&ft:locale=en-US).
* [Working with responsive dashboards](https://www.servicenow.com/docs/access?context=c_ResponsiveDashboards&version=yokohama&pubname=yokohama-now-intelligence&ft:locale=en-US).
{#customizations-tracked-update-sets__ul_plq_hjz_jrb}

## Application changes

The system creates a separate update set for each application that only contains changes
associated with the application. This ensures that access settings for each application are
properly evaluated and applied when committing update set changes.

*[\>]: and then