---
sourceDocument: Australia Build or modify applications
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/pt-BR/application-development

 Release :

    - australia

ft:locale :

    - pt-BR

ft:publication_title :

    - Australia Build or modify applications

ft:clusterId :

    - cadev

bundleId :

    - cadev

workflow :

    - Development, Data, and Analytics


---

# Update set collision resolution

# Update set collision resolution {#ariaid-title1}

* Versão de lançamento: Australia
* 
* Atualizado 12 de mar. de 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 min. de leitura

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's a
collision.

When a customer update is moved from one instance to another, it may be rewritten to match the target instance. The rewrite can involve changing the update name of the customer update and one or more sys_id within the update.
The rewrites are done when the record or the reference field is for a table that uses a coalesce strategy. This verifies that the customer update will be applied to the correct record. For example, if the sys_dictionary record
for tablename.fieldname has sys_id `123` on instance A and sys_id `456` 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 `123` are updated to read `456`.

## Coalesce strategies

Coalescing refers to the process of identifying a record based on one or more fields that are used as unique identifiers during the update process. 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 the uniqueness of tables, the tables must be
unique when the coalescing columns are combined. Records that aren't listed here won't collide if the same record is created separately on different instances.
{#update-set-collisions__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 |
[ ]

## How customer update record names affect collisions

To understand coalescing, it helps to understand how records that don't coalesce work. For most record types, when a customer update is moved to a new instance, the system doesn't 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 doesn't 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 rewritten to match the target instance. The rewrite can involve changing the update name of the customer update and one or more sys_ids within the update.
The rewrites are done when the record or the reference field is for a table that uses a coalesce strategy. This confirms 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 verify the records have the same sys_id.
* Export and import records as XML files to verify the records have the same sys_id. See [Export and import XML files](https://www.servicenow.com/docs/access?context=c_ExportAndImportXMLFiles&version=australia&pubname=australia-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=australia&pubname=australia-platform-administration&ft:locale=en-US).

{#update-set-collisions__ul_elx_v4n_vp}  
Nota:  
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.