Updating records with AFTER business rules

[Kris26]

Hi, all

For a while now, I have been going through some of my company's SN configuration and coding to review some of the practices that have been in place up to now. This has been particularly relevant because of some performance issues overall and ''interesting'' bugs coming up from time to time.

So one thing I've found, the team seems to be using current.update() call in a LOT of business rules across the system, but in particular for some tables. I know that this has been covered in many places and topics already and is considered very bad practice - https://hi.service-now.com/kb_view.do?sysparm_article=KB0715782 or https://community.servicenow.com/community?id=community_blog&sys_id=f12d66e5dbd0dbc01dcaf3231f961988

Now, for the before business rule, everything is clear and that is a childish mistake that we can easily fix. My dilemma is with the after business rules, what would be the correct way of substituting current functionality and allow us to avoid the recursive calls that hinder performance and is very bad practice? I am also aware of setWorkflow(false) function. I would like to know how to get rid of these for good, not putting in the workflow function, since that is supposed to be last measure in exceptional cases anyway.

So let's model a situation - we have a table of records, and some BR associated with it. When the record is updated or inserted, it triggers the BR, which changes, updates some fields of that current record. This can only be done after the DB action, though, because we want to make sure the initial change has been allowed and successfully posted to the DB.

For example - Document A is created, document approver field is filled in and you click on submit button. This would trigger a business rule after the insert/update is made and set the document stage from ''draft'' to ''in progress''. How would you go about this? Would appreciate if you could also shed some light on async type BR, when that would be best applied.

[Yash Agrawal1]

Hello Kris,

Will you please provide the issue detials. in short .

so that i can understand it better. and try to help you

Regards,

Yash Agrawal

[Kris26]

If you see the last part of the post, you'll find the essence of the issue. But again, in short, what is the best practice to design business rules, and update the current record that is triggering the BR. Is another type of BR needed? Other elements need to be used in combination so that these can be converted to before business rules, some client side scripting, etc?

[Willem]

Recursive calls and After business rule

This would trigger a business rule after the insert/update is made and set the document stage from ''draft'' to ''in progress''.

So in this case you can check if the stage is "draft" as a condition on the Business rule. If it is not in stage "draft" it will not execute the Business rule (again).

I think you are doing it right. Try to limit the number of After business rules, but where needed, use a condition to make sure it does not trigger unwanted.

Async

As for async business rules. They are queued and trigger depending on system load. You would use this if it is not time essential. For example interfacing to another system.

Note: They tun as System and not as the user initiating.

[MrMuhammad]

For your use case, what I will do is to first put a few conditions to ensure the BR runs only when needed.

The conditions would be

document approver [is not empty] AND

stage [is] draft

Async

It works like After Business rule but it may or may not run immediately, it gets queued and runs when the resources are available. 

When you need to update the current form/object, Async is not a good option. Go for After BR. When you need to make third party calls then you must use Async as third party calls take time to executes and Async will help you release resources and keep on running in the background.

So, if we take an example of your use case then I would go for After as I am updating the current record when certain conditions met.

Another use would be to trigger a survey when the incident gets resolved. Now, in this case, I would prefer Async as it doesn't require a current record update from BR. Also, survey can be triggered when resources are available.