Records unexpectedly overwritten during upgrade


The purpose of this article is to educate users there are updates to an artifact, which can occur during an upgrade, regardless of the customizations which are made against it. The most important concept for customers to realize is that not all updates to records in an instance are captured as a customization. The engine which controls whether or not an update on a table is captured is on the dictionary entry of a table contained in an attribute called update_synch


What is update_synch?

update_synch controls what can and cannot be captured as a customization on a table. Generally speaking, the update_synch attribute is found on tables with configuration data. update_synch does not exist on a table with raw data, like Task, from client users that are being input into the system. If update_synch is true, this indicates that we will capture customizations to update in the respective table and there will be an associated sys_update_xml record. In the absence of this attribute, this is an indication that we do not capture changes to the table and therefore there would not be a sys_update_xml record available for changes against the table. However, if the table is within a hierarchy where it is a child table, the child table along with its descendant table by default, inherit the attribute.

It is important to note that this property should not be changed on any dictionary collection record whether it is present or not. Customers who have a use case for wanting update_synch should request an enhancement request via an incident to be reviewed by our product team. An additional note, ServiceNOW does not support the Force to update set option and customers should refrain from using this UI action. Although forcing to update set creates the proper sys_update_xml record, this does not mean that customizations are exempt from being overwritten.



How to validate if an update occurred due to the absence of update_synch

To identify if the update which occurred during upgrade was because of the absence of the update_synch attribute, perform the following:

  1. Validate the name of the table where the update occurred.
    • For this example, use kb_knowledge_base. To identify the table, look at the record from the upgrade details related list in the upgrade history record that was updated. The filename is prefixed with the table name and has the sys_id of the record that was updated.
      This looks like something along the lines of kb_knowledge_base_dfc19531bf2021003f07e2c1ac0739ab
  2. Validate if the table is update synch > System Definition > Dictionary > Create query for name='tablename' AND type=collection
  3. Open the record and view the attributes related list. You can also click on the Advanced view related link to see if the update_synch=true attribute is present

  4. If update_synch is not present, check to see if it is a child table.
    • To do this, navigate to System Definition> Tables> Create a query for name="tablename."
    • If the Extends column is not available, add this to the list.
    • If there is a value in this field, check that table's dictionary collection record for the attribute and check to see if the extended table also has a parent.
    • In the case of our example, notice that the kb_knowledge_base has no parent or children so this is as far as is checked.

Based off of the information found, the update to kb_knowledge_base_dfc19531bf2021003f07e2c1ac0739ab is expected behavior as the record is on a table where update_synch=true is not present and therefore will always be overwritten during an upgrade or plugin activation if there are any OOB changes to the knowledge base record itself.

An additional note, if there was an update during upgrade this essentially means that the OOB version of this kb_knowledge_base record was modified. The proper way to go about this would have been to create a new record in kb_knowledge_base as opposed to modifying an existing OOB record which is subject to being updated.




The simplest work around is to export the records that would be updated pre-upgrade and then re-import them as needed post upgrade. The other option is to not utilize the existing OOB record and then just create a new record with the desired content.

Article Information

Last Updated:2020-01-27 16:58:12