Recommended practices avoiding to use current.update() in Business RulesIssue 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.ResolutionIn 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.