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?

[kchorny]

This is happening on our company's production instance, but because I can't reproduce it, and because it's a custom rule, SN support is not able to (or won't) help any more than they already have.  They checked some logs, and suggested the before rule at order 1, but other than that they have closed the case.

The rule is in the same domain as the users for which I need it to run, but I may move it to the global domain and add a condition such that it will only run for my target users.  That's the only thing I can think to do at this point, to rule out some kind of domain-related hiccup.

Thanks for staying with me on this. 🙂

[DirkRedeker]

Hi

You are welcome.

And you are welcome to mark some of my answers as helpful, which donates some honor to my writing....

So, let's try to solve your issue together.

It looks like a tricky and interesting one. Stay tuned.

BR Dirk

[DirkRedeker]

Hi

"Trying" on the Production Instance is not the best idea, and should be just the "Last guess" to go if there is no alternative.

Do you have some (sub production) clone of the instance, where that problem exists?

If you have, the same issue should occur there as well, and you can feel much more safe, just to try out what happens in detail and "try" different scenarios.

I think, this will be one of the next steps to achieve:

To find a Sub Production instance where to reproduce this behavior. Then try to sort out one by one. If you can reproduce it, you will know the cases, when the issue occurs. This will also help a lot in investigation about the root cause.

Maybe you can review also the cases, that occured on the production instance, to find out some pattern. Computers ALWAYS works in a determinable way. They are stupid! They just follow what them was told. It's hard for us sometimes to find out, WHAT exactly we told them 😉

But it is always possible to find out about the root cause.

Let me know about your progress for the clone and case elaboration about when it happens.

Have a nice day and never give up!

BR

Dirk

[kchorny]

We have two sub-prod environments.  I always test my changes in our dev environment before I duplicate them in production.

So far, I have not been able to find a pattern in the users or their time entries. Because it only happens <1% of the time, to replicate I would need to get a bunch of users to create a bunch of time entries in dev, and watch each one to see if I can find some kind of pattern in the failures. 

I made the change I mentioned yesterday afternoon - moved the rule to global and added conditions so it would only run for users with a particular role.  So far it's working and the rule is triggered every time, but I don't want to get my hopes up yet.

Thanks again for your help. 🙂

[DirkRedeker]

Hi

Thanks for your update.

Just let me know if that issue occurs again. Maybe that gives another piece in the puzzle for investigate the root cause.

Maybe it's solved now, so that I would also be glad to hear - at least - in a couple of days, if it's now working as expected.

Let's cross fingers!

BR

Dirk