How can we decide that a given 'before business rule' should be kept as it is or changed to 'after business rule'?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-06-2017 08:15 PM
Hello All,
According to ACE reports 'Before Business Rules' should not update() or insert() records on other tables. Now I have to decide whether I should keep the 'before business rule' as it is or change it to 'after business rule'. I wanted to know how to decide that.And I have a wierd code, it would be nice if someone could help me with this.
This business rule runs before insert and update and it is made on the table sysauto_db_check.The code is as shown below:
current.script = "var gr1 = new GlideRecord('ha_db_check');gr1.setValue('check_type',current.check_type);gr1.setValue('target_database',current.target_database);gr1.setValue('auto_repair',current.auto_repair); gr1.insert();";
Should this be kept as it is or changed to after business rule?
Regards,
Reeba

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-07-2017 12:31 AM
Sorry, but this is not what ServiceNow gives out as a technical best practice.
Before Business Rules:
- Should only update the current record to make changes to the data entered in the form or which comes from an integration
- Never ever use current.update() here, as it will end in recursion
After Business Rules:
- Should generally not be used to update the current record.
- Are used to update foreign records, where you immediately need to see the result. If you don't need to see it immediately consider changing to async instead
- Never ever call current.update() from an After Business Rule, as it would trigger the whole commit again and will run again through Before Business Rules
In your case, as this is an insert on a foreign record, this is clearly either an After, I would even suspect it could be an Async Business Rule as it is anyway triggered by a scheduled job and no user needs to see the result immediately.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-07-2017 01:09 AM
Hello Ulrich Jugl,
Thankyou so much for sharing this information. Could you please tell me how you came to know that this is triggered by a scheduled job? I haven't yet worked with async business rules that is why I am asking.
Regards,
Reeba

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-07-2017 01:15 AM
sysauto_db_check sounds like a table which inherits from sysauto, which is the Scheduled Job table. Scheduled Jobs are backgrounds job where a user is not expecting immediate results (e.g. you submit a form and the state should automatically change from Pending to Open).
When working with async business rules keep the following things in mind:
- You don't have access to the previous object
- Without access to previous, you will not be able to use conditions like changes from / changes to / changes
- The BR is scheduled to be taken up by the system scheduler and you cannot define in which order and at which exact time this BR is executed, but usually it is taken up a few seconds after it was triggered.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-07-2017 01:37 AM
Thankyou so much Ulrich. It was like you said, sysato_db_check extends from sysauto_script.
Just one more doubt I have. There is one more before business rule which is from sc_task table. This is from sc_task table. The code is as below:
var gr_req=new GlideRecord('sc_req_item');
gr_req.addQuery('sys_id',current.request_item);
gr_req.query();
while(gr_req.next())
{
gr_req.assigned_to=current.assigned_to;
//gr_req.u_number_of_units_of_work_trea=current.u_number_of_units_of_work;
gr_req.time_worked=current.time_worked;
gr_req.update();
}
In this line gr_req.addQuery('sys_id',current.request_item); it is taking the sys_id of the current request item. But in case of insert operation the request item is not yet created, so we won't get the sys_id, so I think this should be an After business rule. Am I correct about this?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-07-2017 01:49 AM
Following the guideline from above, this definitely qualifies for an after business rule, as you are updating a foreign record. Here you need to decide if it can qualify for async, as I would suspect the user assignment should be done immediately and visible for the user, async might not be an option.