setWorkflow (false)

[vijay_sangewar1]

DeleteAllBusinessCapability(); //Calling the function

function DeleteAllBusinessCapability() {

    var gr = new GlideRecord('cmdb_ci_business_capability');
    gr.addQuery('active', true); // It takes active business capability
    gr.query();
    gr.setWorkflow(false); //Don't fire any business rule, notification
    gr.deleteMultiple(); 
}

I have wrote the above script to delete all the business capabilities record from "cmdb_ci_business_capability" table in order to load new capabilities records.  I have put setWorkflow as false to reduce load on the system while deleting the records also to avoid any process or workflow during the deletion of the records. 

Now the client is saying it can lead to orphan records if I use setWorkflow as false.

I need a clarification on the below mention points

1. what are the consequences of using setWorkflow(false).

2. If the above script lead to any orphan records because of the setWorkflow(false), how can i find those orphan records?

[Tony Chatfield1]

Hi, as setWorkflow(false) will stop business rules & workflows from running, so functions to delete related records would not be triggered resulting in orphaned records. To find these records you would need to search related tables\M2M related tables for NULL\empty references to the table you are cleanzing.
How many records are involved? Perhaps it would be better not to use setWorkflow(false) during the delete process

[Paul Curwen]

1. Using setWorkflow(false) prevents any related Business Rules from running as a result of your script. In many instances you want them to run, removing related records is one good example, in other cases you want the script to not affect anything else and you would want to use it. The best way to determine this is look at the existing Business Rule defined on the table you are manipulating and deciding if you want those to run or not depending on your desired outcome. 

2. Yes your script may well lead to orphaned records. Finding them would be very difficult depending on the amount of data the script changed  after the result. If you ran this as a background script look under Rollback and Recovery > Rollback Contexts in your menu (as an admin). Find the record where you ran the script and open it. Under the Related links there is a 'Rollback' option, using you would be able to roll back the results of the script then take out the setWorkflow(false) and run the script again to prevent orphaning. 

Extra Info: setWorkflow(false) is often used with autoSysFields(false);

‘autoSysFields’ is used to disable the update of ‘sys’ fields (Updated, Created, etc.) for a particular update. This really is only used in special situations. The primary example is when you need to perform a mass update of records to true up some of the data but want to retain the original update timestamps, updated, update by etc , etc.

//Change the category of all 'software' incidents to 'hardware' without updating sys fields
var gr = new GlideRecord('incident');
gr.addQuery('category', 'software');
gr.query();
while(gr.next()){
gr.category = 'hardware';

gr.setWorkflow(false);
gr.autoSysFields(false);
gr.update();
}

 

If helpful please mark as Helpful/Correct

[Riya Verma]

Hi @vijay_sangewar1 ,

Hope you are doing great.

1. The consequence of using setWorkflow(false) in your script is that it disables the execution of business rules and notifications during the deletion process. you are bypassing these additional functionalities and reducing the load on the system, which can help improve performance during bulk record deletions.

setWorkflow () is often  used with‘autoSysFields’ is used to disable the update of ‘sys’ fields (Updated, Created, etc.) for a particular update.

2. the script with setWorkflow(false) leads to orphan records, you can identify them by querying the 'cmdb_ci_business_capability' table for records that do not have any associated relationships. Orphan records are typically those that were not properly deleted due to the bypassing of workflows and business rules.

[Vishnu Prasad K]

Hi,

The reason for the generation of orphan records is the table in which you are running the query and not the setworkflow, it's a cmdb table.

So in order to see in which all tables orphan CIs are created, you should look at the relationships for business capability table (which you can see from the schema diagrams). Then you can avoid the orphan CIs by adding more query conditions.

NB - More the relations, the harder it becomes to define the query conditions.