Need information on Current.update() used on before or after business rule.

vinuth v · ‎08-05-2024

Hi All,

please any one guide me when to use the Current.update() method and in which BR..

Thanks,

Vinuth

Bert_c1 · ‎08-05-2024

You can review here:

https://docs.servicenow.com/bundle/xanadu-api-reference/page/script/business-rules/concept/c_Busines...

Good luck

Satishkumar B · ‎08-05-2024

@vinuth v

The current.update() method in ServiceNow is used to save changes made to a record. Its usage depends on the context of the Business Rule (BR) and what you're trying to achieve. Here’s a guide on when and how to use current.update() in Business Rules:

1. Before Business Rule

Purpose: Generally, you do not use current.update() in a Before Business Rule because the record has not been saved yet. Calling current.update() in a Before Business Rule can lead to recursive calls or save the record before all necessary data is available.
Common Use Case: If you need to modify the record based on some conditions before it gets saved, perform those changes directly on the current object without calling current.update().

Example:

(function executeRule(current, previous /*null when async*/) { if (current.some_field == 'some_value') { current.other_field = 'new_value'; } })(current, previous);

2. After Business Rule

Purpose: Using current.update() in an After Business Rule is appropriate if you need to perform additional actions that require the record to be saved first. This is where you can update the record again after the initial save, or update related records.
Common Use Case: Updating the record based on the result of the initial save, or creating related records or logs.

Example:

(function executeRule(current, previous /*null when async*/) { if (current.state == 'completed') { current.comments = 'The record has been completed.'; current.update(); // Save the changes made in this after business rule } })(current, previous);

When to Use current.update():

After Business Rule: When you need to perform additional updates to the record after it has been initially saved.
Special Use Cases: If you are in a Before Business Rule and need to trigger some logic that involves saving the record multiple times, consider handling such logic differently to avoid recursion or performance issues.

When Not to Use current.update():

Before Business Rule: Avoid using current.update() as it can cause recursive updates and conflicts, because the record is not yet committed to the database.
Avoid Recursion: Be cautious with current.update() in After Business Rules to prevent unintended recursion or performance problems.

In summary, use current.update() in After Business Rules when you need to make further changes to a record after it has been initially saved. Avoid using it in Before Business Rules to prevent potential issues with record saving and processing.

please mark my response as helpful 👍and accept the solution ✅if it helps you

Amit Pandey · ‎08-05-2024

Hi @vinuth v

We should avoid current.update() function in Business rules. Main reason to avoid update function in BR is that it can lead to recursive call to same business rule. Servicenow has internal detectors for this but to prevent an endless recursive call of BR can cause performance issue in instance.

There is almost never a case when the current.update() should ever need to be used in an Business Rule. Lets discuss each type of business rules one by one.

🌟current.update() in Before Business Rule?

In Before BR current.update is not necessary as SNOW saves all values stored in current object after BR executes.

Eg : current.state = 7 ; current.description=”hello there”;

🌟current.update() in After Business Rule?

In After BR try to rethink about using current.update() as this can cause Before BR run again. To avoid this, change your After BR to Before BR so you won’t need to use current.update.

🌟current.update() in Async Business Rule?

Async BR executes after data is modified in database, so its solution is similar to After BR.

🌟current.update() in Display Business Rule?

Display BR runs when record is first displayed on the screen. So, it is not a good practice to update record when it is just accessed. Alternatively use client scripts in those cases.

🌟When to use current.update()?

In the rare case in which a current.update() cannot be avoided, in order to prevent recursion that can cause preformance issue then current.update should be used in conjuction with setWorkflow(false).

current.status = 1;
current.setWorkflow(false);
current.update();
current.setWorkflow(true);
This will suppress any business rules from triggering and will also prevent the update from being audited.

So this is all about usage of current.update(). You can take you own changes and try to avoid using the function.

https://grow.usecoda.com/do-not-use-current-update-in-business-rules

Regards,

Amit

Sumanth16 · ‎08-05-2024

Hi @vinuth v ,

Description

The current.update() function should be avoided within Business Rules, due to performance impact. When calling the update() function, any associated Business Rules to the object of the update() function are also called which can end up causing a string of recursive calls to the same Business Rule. While the system has internal detectors for this and will prevent an endless series of such Business Rule executions, the detection of this has been known to cause performance issues in that instance.

It should also be noted that any update() function call will usually cause any Business Rules related to the object which is the subject of the function to be called. Thus, in some cases, updating another object could also result in the original object being updated again which could also cause this similar issue. Again, the system is designed to detect this, however there is the potential for performance issues when these Business Rules run. Thus, any update function should be reviewed when added in a script within a Business Rule.

Details

There is almost always an alternative way to perform the needed task in a Business Rule rather than using current.update().

In a "before" Business Rule, an update of the current record should not be necessary as the record will be saved upon completion of the highest ordered Business Rule. Furthermore, in certain cases, the save may need to be stopped in the chain of Before business rules (with use of the setAbortAction function), and if the record has already been updated, data may have already been saved which would normally be an invalid save by the logic of the Business Rule.

In an "after" Business Rule current.update() should also not be used. Any action that might be performed in an After Business Rule can usually have been added in a high ordered Before Business Rule, eliminating any need for an explicit update() function call. In addition, updating in an After Business Rule will cause all Before Business Rules to run again, which, as mentioned previously could cause performance processing issues.

An "async" Business Rule is, for this discussion, essentially the same as an After Business Rule. It is simply a Business Rule that executes sometime after the actual record is saved, but not in the user's current session. As in a standard After Business Rule, any updates or changes to field on the current record that could need to be called in this Business Rule should be able to be called in a Before Business rule without the need for a current.update() function call.

Not only should the current.update() function not be used in a "query" type Business Rule, it actually cannot be called and will generate an error if called in this type of Business Rule. This is because, at the time this Business Rule is called, upon the initial query of a list or collection of records, there is no concept of a "current" record.

A "display" Business Rule is run when the record first is displayed on the screen and is usually used to populate temporary, internal variables with some values that may not be accessible once the form for the record is actually fully loaded. As a general rule, you should never have the need to save the record immediately upon display of the record, and doing so will call the usual chain of Business Rules associated to that record.

Thus, there should rarely, if ever, be the need to actually use the current.update() function call in any Business Rule. This would also apply with a client script that might be called through a Business Rule. In any case in which the use of the current.update() can be avoided in favor of another method to accomplish what is needed, the alternative option should generally be used due to the known potential for performance issues that night occur when using this function in any Business Rule.

Occasionally, an existing Business Rule may be found that uses the current.update() function, sometimes even an out-of-box object. These are the rare exception and if another method can be found to perform the same task, that method should probably be used instead.

Finally, "current" is a reference to a GlideRecord object and that object may encapsulate a result set which multiple records, not just a single record. If current.setWorkflow(false) is called before current.update is used, then it will disable business rule execution and auditing not just for the currently selected record in the result set, but also for all subsequent records still to be processed.

Resolution

In the rare case in which a current.update() cannot be avoided and must be used as no other method can be found to accomplish the update as needed, in order to prevent the recursion that can cause the performance issues, the current.update() should be used in conjunction with the setWorkflow(false) function. As an example, the following code snippet shows a very basic update to a record and use of the setWorkflow() function:

current.status = 1;
current.setWorkflow(false);
current.update();
current.setWorkflow(true);

However, this will suppress any business rules from triggering, and will also prevent the update from being audited, see the explanation in the description above.

Mark the comment as a correct answer and also helpful once worked.

Thanks & Regards,
Sumanth Meda