Business rule not always running as expected

[kchorny]

We have a before business rule that should always run on insert/update (no other conditions) into the task_time_worked table via a time worked update on tasks, but about 1% of the time it does not run.  The rule is intended to create/update time cards, but because of this issue, it's not doing so consistently. The record does get inserted, just triggers no business rules.

There does not appear to be any kind of a pattern to when this happens - it seems completely random.  

I have searched high and low for other rules that may be preventing this rule from running (containing setWorkflow(false))

I'm at my wits end and need some advice on other ways to troubleshoot.  I can't reproduce what's happening... and HI won't help; the rule is custom because we needed some additional functionality that the OOB rule did not provide.

Any ideas?

[SanjivMeher]

Is this the only BR you have on the task_time_worked table?

Did you try impersonating the user who reported this issue and tried this scenario, just to make sure, no access issue.

Another suggestion, this should have been an async business rule. This may be causing UI performance issue. I hope, user's doesn't cancel the transaction, if it takes more time, which may be causing it to fail. The script could also be put into a script include. You can always update the task_time_worked using a GlideRecord.

Did you also check if there are orphaned time card record, which may be getting created, but not linking back to task_time_worked

[kchorny]

"Is this the only BR you have on the task_time_worked table?"

There are 6 rules, 3 before and 3 after.  The rule at 400 does have a setWorkflow(false) statement, but because it's an 'after' rule, it should not stop 'before' rules from running.

The before rule at order 100 only runs under this condition 'current.time_in_seconds > previous.time_in_seconds && gs.getSession().isInteractive()', only runs on update and would generate a user-visible error.

My test rules at order 1, that simply generate log records, do not run either.

"Did you try impersonating the user who reported this issue and tried this scenario, just to make sure, no access issue."

This happens to multiple users who have no common attributes that I can find that are different from any other users, and the list of users it happens to changes every day.  Also, it works as expected for the same users 99% of the time as well. It has happened to me as well, once.

"Another suggestion, this should have been an async business rule. This may be causing UI performance issue. I hope, user's doesn't cancel the transaction, if it takes more time, which may be causing it to fail. The script could also be put into a script include. You can always update the task_time_worked using a GlideRecord."

I'm sure it could be written more elegantly and I will try to make it more efficient in the future, but because a log entry never gets generated, I do not believe users are cancelling anything. I have spoken to some of the more proficient users - no errors, no other indications that anything was wrong.

"Did you also check if there are orphaned time card record, which may be getting created, but not linking back to task_time_worked"

I have checked for orphaned time cards - there are none. And since the rule is not running at all, I wouldn't expect there to be any.

Thank you for your suggestions, but I believe I have ruled all of them out.  I'm sure I'm overlooking something, I just don't know where else to look. 😞

[DirkRedeker]

Hi

Maybe your issue is, that the BR will not fire at all...

So, if this is the case, you can check if there is another BR with the SAME trigger, but with a LOWER Order value.

That one will trigger BEFORE the one you showed in the Screenshot (having the Order = 300). If there is another one, check if that one stops FURTHER processing of subsequent BR.

This may be the cause, why it is not fired at all.

You need to review all BR, that runs on the same Table!

Please review that and let me know.

Never give up!

BR

Dirk

[kchorny]

Thanks for the 'never give up' because I'm at my wits end with this! 🙂

There are very few rules running on this table.  The only one with 'setWorkflow(false)' is an after rule, so should not be impacting the triggering of this 'before' rule.

I have also searched all business rules and script includes for 'task_time_worked' AND 'setWorkflow(false)' in the script, and found nothing.

[DirkRedeker]

Hi

I just reviewed your Screenshots of the BR and just saw now, that you have Domain separation in place.

This may also be another reason, why it may not fire.

Personally, I have no experience with domain separation, sorry.

Do you have some ideas on, your side, what may affect your scenario, regarding Domain separation?

Let me know if you have any idea.

Your topic becomes more and more interesting.

Is this happening on a PDI or on a company instance?

If that occurs on a paid instance, you can consult ServiceNow by raising a HI Ticket. 

BR Dirk