Notifications

923 views

Overview


This article details information around using the class switcher to reclassify a record within ServiceNOW. It is important to note that calling the class switcher from a script or simply changing the value from a list view results in a process where we initiate a rip and replace. The process essentially involves taking a copy of the data, deleting the record, and then re-inserting the record into the desired target class.

 ie. (a known PRB1300274 has been submitted to address an issue where a non-admin user can simply change the value of this field. Recommendation from support would be to create a list edit ACL on this field in task to lock down unintentional list edits.)

Example


User decides they want to reclassify an incident as a normal task record after the incident has been closed using the following script


 var reclassRecord = new GlideRecord('incident');
 reclassRecord.addQuery('number','INC001234');
 reclassRecord.query();
 
 while(reclassRecord.next()) {
 reclassRecord.sys_class_name='task';
 reclassRecord.update();
 }

On the incident table there are fields which are native to incident that do not exist on the task table such as the incident_state field. When the class switcher is invoked since the the task table has no incident_state field the data in this field is lost. This will occur with any data where the field on the source table does not exist on the target class where we are switching classes.

 

IMPORTANT TO NOTE: If there are any data policies in the target class where we are switching the record to a class where fields are mandatory, this will most likely result in complete record loss where we successfully delete the record from the source class but do not insert the record into the target class. Sys_class_name changes should always be tested in a sub-prod environment with the expectation that it is possible that data may not carry over. ServiceNOW does not advocate for or advise against this method of changing classes, but the decision to do so is under the discretion of the customer/user. If reclassifying is needed support advises using this method against any table that extends the Application File table (sys_metadata) as reclassifying records in this particular hierarchy is illogical. Re-classifying records is generally used for raw data like task or cmdb but should only be implemented after fully understanding potential consequences.

 

Article Information

Last Updated:2018-08-24 14:37:54
Published:2018-08-24