Changing the sys_class_name of a record can result in the record being deleted if Mandatory field Data Policy prevents the insert in the target tableDescription When the Class of a record in an Extended Table is changed, the platform will delete from the source table and then insert in the target table. If there is a Data Policy restriction on the target table preventing the insert, then the record has been deleted already, and cause data loss. On a List view, the error "Data Policy Exception: The following fields are mandatory: <field list>" is displayed.On opening or refreshing the record form after this has happened, you will get "Record not found" instead of a form, and reference fields on other records to this record will show "No preview available". Steps to Reproduce This example uses the Product Model table, however this also applies to any of the 100+ extended tables in the instance, including the big tables Task, CMDB, Asset etc.... Set up a Data policy on the Hardware Model table [cmdb_hardware_product_model]Add a Data Policy Rule that the 'Comments' field is Mandatory.Navigate to the 'Model' table list, and personalize the list to add columns for 'Class' and 'Comments. /cmdb_model_list.do3. Pick a record where 'Comments' is empty and class is Product Model, and open that in a new tab.Back in the list, update the Class field to 'Hardware Model'A warning about "Data Policy Exception: The following fields are mandatory: Comments" appears.In the other tab, refresh the page. You'll see "Record not found". Then record is gone. An update from a Script will also have the issue. The Node logs will show: 02/26/19 12:29:17 (261) 5D896262DB776B00B94581F239961980 Change in class detected, switching from: cmdb_model to: cmdb_hardware_product_model sys_id: 93c365aabf2111007c94c0647e0739a3 02/26/19 12:29:17 (326) 5D896262DB776B00B94581F239961980 Background message, type:error, message: Data Policy Exception: The following fields are mandatory: Comments Workaround After carefully considering the severity and frequency of the issue, and risk of attempting a fix, it has been decided to not address this issue in any current or future releases. We do not make this decision lightly, and we apologize for any inconvenience. If you have any questions regarding this problem, contact ServiceNow Customer Support. To prevent this happening, you will need to carefully design your Data Policies, taking into account this limitation. Avoid moving a record to a sub-class that has extra fields, and the data policy has a mandatory requirement on one of those extra fields, because this problem will happen every time, as that field value will inevitable by empty as there was no way to fill it in until after the class change. Defining the Data Policy on only the top level table, and using only fields in the conditions that exist in the top level tables will avoid this. e.g. A data policy on cmdb_ci and conditions on only fields defined on either cmdb or cmdb_ci would apply to all records in the CMDB in the same way, and not cause this problem when changing class. For additional info on what happens during a Class change, see KB0727652 What happens when you update an Extended Table record to change the Class? Related Problem: PRB631444