When reviewing skipped changes, the Resolve Conflicts screen sometimes shows unexpected values for base system versions - Support and Troubleshooting

When reviewing skipped changes, the Resolve Conflicts screen sometimes shows unexpected values for base system versions Issue  After an upgrade, you will need to review the Skipped Changes related lists on the Upgrade History module. However, sometimes you may see unexpected values on the base system versions of some records when using the Resolve Conflicts feature. One common example of this is the base system version of a sys_dictionary record may show the active field with a value of false . This may lead you to believe that reverting to the base system version will de-activate the sys_dictionary record.

Release All supported versions

Cause The Resolve Conflicts feature is a useful tool for inspecting skipped records after an upgrade. When comparing a record to the base system version, it reads the values of the current record from the database. However, it reads the values of the base system version directly from disk. That means these values only reflect what's in the XML file from the upgrade package.

Over time, many changes have been made to the out-of-box schema of various tables. Using the same example from before, the sys_dictionary table did not have an active column in older versions of ServiceNow. Thus, sys_dictionary records that have not been changed in a while will also not have an active column in their XML file. When the Resolve Conflicts comparison tool tries to read the value of a field that does not exist in the XML file, some default value will be displayed. In the case of a boolean field like active , this default value will be false . The comparison will then report this as a difference when in reality, there was just no value to compare to. If you use the Revert to Base System action, in this case, you may think it will de-activate the record. However, since there is actually no value at all in the base system XML file, it will change nothing about this field when reverting.

In order to determine if the base system value you are seeing is accurate or just the result of a missing field in the XML file, you can inspect the payload of the s ys_update_version record for the base system version. Simply copy the File Name from the Upgrade Details form, and then search for that name on the sys_update_version table. There will be one record with a state of History . You can then open this version record and examine the payload. If the column you are investigating (such as the active column) is not in the payload, then you can assume the comparison for that field as seen in the Resolve Conflicts screen is not valid and can be ignored.

Resolution This is the expected behavior of the platform. The diff/merge tool is not designed to display missing fields in the XML file any differently than existing fields. However, our development team is aware of the less-than-ideal experience here, and will likely implement a much more user-friendly solution in a future version of ServiceNow.