Notifications

32 views

Description

Typically, if you wish to delete a record without triggering business rules and other workflow engines, you call setWorkflow(false) on the GlideRecord before performing the deletion. However, if you construct the GlideRecord on a class that has sub-classes (like "sys_metadata") then workflow engines will still be triggered for the sub-classes.

Steps to Reproduce

1) Create a business rule on the sys_db_view table that is triggered on deletion, and simply prints out a log message

2) Create a test record on the sys_db_view table and grab the sys ID

3) Run this script:

var gr = new GlideRecord('sys_db_view');
gr.get('12345'); // Sys ID from step 2
gr.setWorkflow(false);
gr.deleteRecord();

4) You will notice your log message is not printed, because the business rule was not triggered (This is the correct behavior)

5) Create another test record on the sys_db_view table and grab the sys ID again

6) Run this script:

var gr = new GlideRecord('sys_metadata');
gr.get('54321'); // Sys ID from step 5
gr.setWorkflow(false);
gr.deleteRecord();

7) You will notice your log message IS printed this time, because the business rule was triggered (This is the incorrect behavior)

Workaround

The only workaround is to make sure you are constructing the GlideRecord with the exact class of the record you wish to delete. For example, if you are deleting a sys_db_view record, you would need to pass "sys_db_view" in the constructor. Passing the parent class ("sys_metadata") will expose you to this PRB. This is especially difficult if you are performing mass-deletion of records on a table with child classes. For those cases, if you must disable workflow engines, it is recommended to start at the very bottom of the hierarchy where there are no more child classes, and work your way up.

For example, if you want to delete all Record Producers (including Services) but do not want to trigger workflow engines, you need to take into account the class hierarchy and work from the bottom up. In this case, the bottom of the hierarchy is the Services class. You would first need to delete all records from this class by constructing the GlideRecord with the class name "sc_cat_item_producer_service". To delete the remaining Record Producers, you would perform a separate deletion, this time constructing the GlideRecord with the parent class name "sc_cat_item_producer".


Related Problem: PRB1354376

Seen In

SR - IRM - Audit Management - New York 2019 Q3
SR - IRM - GRC Profiles - Madrid 2019 Q2
SR - IRM - Policy and Compliance - Madrid 2019 Q2
SR - IRM - Risk Management - New York 2019 Q3

Intended Fix Version

Paris

Safe Harbor Statement

This "Intended Fix Version" information is meant to outline ServiceNow's general product direction and should not be relied upon in making a purchasing decision. The information provided here is for information purposes only and may not be incorporated into any contract. It is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. The development, release, and timing of any features or functionality described for our products remains at ServiceNow's sole discretion.

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2019-10-14 18:20:39
Published:2019-10-15