Data Policy allows creating mandatory rules for fields that only exist in sub-classes of extended tables - Causing record deletion when the record's class is changed - Known Error

Data Policy allows creating mandatory rules for fields that only exist in sub-classes of extended tables - Causing record deletion when the record's class is changed Description Data Policy allows creating rules for fields that only exist in sub-classes of extended tables, where the field does not exist for other tables in the same extended table hierarchy. This causes data loss due to the record being deleted from the source table but prevented from being re-inserted in the table restricted by the data policy during a reclassification of the record. A Data Policy setting a field Mandatory prevents the database insert.

This problem is specifically for the use case where a data policy exists for a field that does not even exist on the class for the record before reclassification, so it is impossible for the condition of the rule to be met before reclassification to prevent the data loss during the reclassification.

Data Policy for "Mandatory" should not be allow to be saved in the first place, if the field only exists for some classes within the extended table. This should be a restriction of the features forms and user interface when configuring a Data Policy.

The behaviour of the GlideRecordClassSwitcher code when an extended table record is reclassified is to delete the record from the old table and insert a new one in the new table. That underlying platform behaviour is not going to be changed due to the risk and complexity and so this feature now needs to work within that limitation (see PRB631444). 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?

Steps to Reproduce

Create a new Hardware [cmdb_ci_hardware] record. This class does not have the OS Service Pack field. Create a Data Policy that makes the OS Service Pack field on the Computer [cmdb_ci_computer] table mandatory: System Policy - Rules - Data Policy: New. Table = Computer [cmdb_ci_computer]. Save. Data Policy Rules: New. Field name=OS Service Pack. Mandatory=true. Submit. Reclassify the Hardware record to Computer. This is easily done from a list with the Class column added. This message appears "Data Policy Exception: The following fields are mandatory: OS Service Pack" Actual behaviour: The record is deleted at step 3 Expected behaviour: Insertion of the mandatory rule for an extending table field should be prevented prevented at step 2

Workaround This problem is currently under review. You can contact ServiceNow Technical Support or subscribe to this Known Error article by clicking the Subscribe button at the top right of this form to be notified when more information will become available.

There is no workaround in code. You must avoid configuring mandatory data policies for child table fields. You can define the Data Policy on top level fields (e.g. task, or cmdb/cmdb_model/alm_asset). This will avoid moving a record from a class that doesn't have the field, to a class where the field is mandatory.

However that is not going to prevent data loss in all cases:

There are over a hundred extended tables in the platform out-of-box. Task and CMDB are the biggest, with Asset and Model. This is particularly important for the CMDB as reclassification of CI records is required and expected by ITOM features such as Discovery or CMDB Identification and Reconciliation.

If Data Policies need adding for Mandatory fields after data already exists, then that data should be updated to meet the new rules before the rules are activated. That will avoid deletion of existing records when they are reclassified subsequently. Values should be added to the fields of all records that are missing them first, then enable the policy. However that does not help for this specific Problem, where there can be no value entered beforehand due to the field not existing for the class the records was in.

If this problem ticket results in new restrictions on creating new Data Policies specifically for mandatory fields in child tables, it will not totally solve the problem. When values are missing and a record is reclassified it can still be deleted by the GlideRecordClassSwitcher code, and those cases are still being tracked by problem ticket PRB631444/KB0727701 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 table .

It would be better to use an alternative method of making the field mandatory.

UI Policies or Client Scripts on the form to enforce mandatory fields before submission. This is client side code that prevents the update before even sending it to the server side code. Fields set Mandatory in the Dictionary, which is usually relevant to user forms and often ignored by code. Related Problem: PRB1476580