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".
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....
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
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?