Customizations tracked by update sets 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 specifically excluded a field from updates. 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, the order requests, items, and catalog tasks are not tracked by update sets. Update sets have a limited capacity to transfer data as application files. This is intended to provide demo data for applications. For larger data transfers export data and import it with an import set or web service. The update_synch attribute To see the list of tables where customizations are tracked, navigate to System Definition > Dictionary 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. Adding this attribute is not supported. 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. Special handlersSome 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 Choice listsUpdate 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, suppose you create a new Activity [u_activity] table that extends the Task table and 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. In addition, you have the option to publish the changes as an application update set so that the u_activity table and its associated choice do not affect the default ServiceNow task application.Dictionary changesUpdate sets prevent you from applying dictionary changes that result in data loss. Blocked dictionary changes include: Removing tables Changing a column's data type 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. Homepages and content pages Homepages and content pages are not added to update sets by default. You must manually add pages to the current update set by unloading them. 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.