---
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


---

# Compare local update sets

# Compare local update sets {#ariaid-title1}

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

Administrators can preview local and remote (retrieved) update sets and compare the
sets with one another to resolve conflicting changes.

## About this task

Compare local update sets to identify collisions and ensure that the proper changes
are being committed. Resolve all conflicts before moving an update set between
instances.

## Procedure

1. Navigate to AllSystem Update SetsLocal Update Sets.
2. Select the check boxes beside the update sets to compare.
3. In the Action choice list, select Compare Update Sets.  
   The progress screen appears as ServiceNow generates the collision report.Figure 1. Collision report
4. Click Go to the Collision Report when the report is complete.  
   The Update Set Collisions list appears, showing all the changes in the
   selected sets.
5. Inspect the list for collisions by locating duplicate Collision Numbers that show the same change in separate update sets.  
   Figure 2. Update set collisions
6. Resolve the collision by deleting the unwanted update record from one of the update sets.  
   1. Click the link in the Sys update column for the unwanted update (`sys_ui_list_incident_null` in the example).
   2. Click Delete.  
      Note:  
      You must open the update record to delete the record. You cannot delete the update by selecting the check box for the entry in the Update Set Collisions list and using the Delete action. When you delete the update record, the customization is not backed out of the instance. Only the record of the customization is deleted.  
      Figure 3. Customer updates
   {#t_CompareLocalUpdateSets__ol_rs2_rnn_vp}
7. Run the comparison again to make sure all collisions have been resolved.

## Update set collision resolution {#ariaid-title2}

A collision is an update that has a newer local update.
The platform detects collisions by comparing the values in the Name and
Updated fields of the customer update record from each update set. If the
name matches but there are different update date values, then there is a collision.

When a customer update is moved from one instance to another, it may be re-written to match
the target instance. The re-write can involve changing the update name of the customer
update and one or more `sys_id`s within the update. The re-writes are done
when the record or the reference field is for a table that uses a coalesce strategy. This
ensures that the customer update will be applied to the correct record. For example, if the
`sys_dictionary` record for `tablename.fieldname` has
`sys_id`
`123456789` on instance A and `sys_id`
`987654321` on instance B, when a customer update that refers to that record
is retrieved from instance A and recorded in the sys_update_xml table on instance B,
references to `123456789` are updated to read `987654321`.

### Coalesce strategies

Update sets can detect collisions between identical records that you independently create
on separate instances. To detect such collisions, the record must have a coalesce strategy
based on coalescing columns. Because collision detection depends on uniqueness of tables,
the tables must be unique when the coalescing columns are combined. Records that are not
listed here will not collide if the same record is created separately on different
instances.  
{#update-set-collisions__table_nqw_nwb_j3c__entry__2}

| Type | Coalescing Columns |
|-|-|
| atf_input_variable | name, element |
| atf_output_variable | name, element |
| dp_data_pattern | source_sys_id |
| dynamic_attribute | namespaced_name |
| dynamic_category | namespaced_name |
| dynamic_category_member | category, attribute |
| dynamic_choice_override | choice, category, attribute |
| dynamic_namespace | name |
| sys_analytics_bucket | sys_scope, bucket_document_id, bucket_table_name |
| sys_attachment | (uses custom matching logic) |
| sys_choice_set | name, element |
| sys_collection | collection, name, join_field |
| sys_db_object | name |
| sys_df_data_dictionary | name, element |
| sys_dictionary | name, element |
| sys_documentation | name, element, language |
| sys_index | logical_table_name, col_name_string |
| sys_module | path |
| sys_notification_category | name |
| sys_package | source |
| sys_package_dependency_m2m | dependency, sys_package |
| sys_properties | name |
| sys_report_chart_color | name, element, value |
| sys_scope_script_access | source_scope, target_scope, script_name |
| sys_scope_table_access | source_scope, target_scope, table_name |
| sys_script_validator | internal_type, ui_type |
| sys_translated | name, element, value, language |
| sys_translated_text | tablename, fieldname, documentkey, language |
| sys_ui_form | name, view, sys_domain |
| sys_ui_list | name, view, sys_domain, element, relationship, parent |
| sys_ui_message | key, language, code |
| sys_ui_related_list | name, view, related_list, sys_domain |
| sys_ui_section | name, view, caption, sys_domain |
| sys_ui_view | name |
| sys_user_group | name |
| sys_user_role | name |
| sys_wizard | name |
| ua_table_licensing_config | name |
[ ]

{#update-set-collisions__table_nqw_nwb_j3c}

### How customer update record names affect collisions

To understand coalescing, it helps to understand how records that do not coalesce work. For most record types, when a customer update is moved to a new instance, the system does not detect collisions for the following reason:

* When you create a record, it receives a unique sys_id. For most record types, the sys_id becomes part of the customer update record name. For example: `sysevent_email_template_9e1998c078b71100a92ecacd80df1d39`.
* Creating an identical record in the same table on another instance produces a customer update record name with a different sys_id. For example: `sysevent_email_template_10b958c8653311005840134572f8e020`
{#update-set-collisions__ul_cld_zpz_py}

As a result, even though the records might be otherwise identical, the records have
different names so the system does not detect the collision.  
Coalescing records, in contrast, use the following approach to naming records and determining collisions: The following customer update record types use some or all of their coalescing columns instead of the sys_id in their names.

* sys_dictionary
* sys_documentation
* sys_choice_set
* sys_ui_list
* sys_ui_related_list
{#update-set-collisions__ul_bzm_mqz_py}

The resulting identical record name in each instance helps the system to identify
collisions even if the records have different sys_ids.

When a customer update is moved from one instance to another, it may be re-written to match
the target instance. The re-write can involve changing the update name of the customer
update and one or more sys_ids within the update. The re-writes are done when the record or
the reference field is for a table that uses a coalesce strategy. This ensures that the
customer update will be applied to the correct record. For example, if the sys_dictionary
record for tablename.fieldname has sys_id "123456789" on instance A and sys_id "987654321"
on instance B, when a customer update that refers to that record is retrieved from instance
A and recorded in the sys_update_xml table on instance B, references to "123456789" are
updated to read "987654321".

### Preventing duplicate records

* Transfer data with update sets rather than recreating it on separate instances to ensure the records have the same sys_id.
* Export and import records as XML files to ensure the records have the same sys_id. See [Export and import XML
  files](https://www.servicenow.com/docs/access?context=c_ExportAndImportXMLFiles&version=yokohama&pubname=yokohama-platform-administration&ft:locale=en-US).
* Enable a unique index for the table from the system dictionary. See [Table administration](https://www.servicenow.com/docs/access?context=c_TableAdministration&version=yokohama&pubname=yokohama-platform-administration&ft:locale=en-US).

{#update-set-collisions__ul_elx_v4n_vp}  
Note:  
The default records included in the baseline system will always have the same Sys ID because the instance imports the records as XML files during instance provisioning.

*[\>]: and then