Async business rule not updating related record

Sebastian Gonz2
Giga Contributor

Hi,

I am running an async business rule on insert on table A that updates a record on table B. Now, there may be multiple records in table A that need to update the same record in table B. What I am seeing is that when multiple record are inserted in table A (like over 20) at the same time, the updates on the on the record in table B do not all happen.

Table B contains a comment box with comma-separated strings. Table A contains 2 fields, one field for a value that should be found in the comment box in table B and another for a status of when the records has been processed. Once the rule runs on table A, it is supposed to remove the value from the comment box in table B and save the record. This usually works fine, but I noticed that when multiple records are inserted into table A that need to update the same record in table B, not all updates are successful.

I thought that by making this rule Asynchronous I would avoid these issues, but that does not seem to be the case.

Any help is appreciated.

1 ACCEPTED SOLUTION

From looking at the logs I realized that the rules are overwriting what one another put on the comment box before the update occurs, causing some weird behavior.



Thanks!


View solution in original post

4 REPLIES 4

sergiu_panaite
ServiceNow Employee
ServiceNow Employee

An ASYNC business rule will just create a scheduled job (with name: "ASYNC: <BR name>") that should run in that moment. If by any chance the job doesn't run or there are no available workers you might see this kind of behavior.


Are these updates all happen at once?


Yes they may when multiple records are inserted at once, which does happen. Is there some kind of collision happening between updates or are the jobs just being dropped when no workers are found?


The jobs are not dropped, and they should still be executed, even if there are multiple at once. I would add a gs.log line in the BR to include the record number or something that can identify the record and then watch the logs to see how many times the job run on update.


From looking at the logs I realized that the rules are overwriting what one another put on the comment box before the update occurs, causing some weird behavior.



Thanks!