Process Definition triggering too much

Hi Vinod Kumar Suthar,

Have you implemented any logic hooks in the targeted modules? 

Yes

That is the reason. PD is not enough mature that it can deal with its logic and Logic Hook logic separately. They normally work in a parallel fashion that is why Logic Hook often triggers many times when we used PD.

I will suggest that minimize the use of PD and in your case, if it is truly necessary then in Logic Hook there is normally 3rd parameter which is "$argument" if you will print this you can get the information of related module or parent module to know actually which module triggers the Logic Hook. 

If it is PD then you can isolate your logic with the current logic implementation in your logic hook. 

Hope it will help.

Logic Hooks are different than the PD's logic. Process is triggering multiple time so we need to restrict to trigger only first update.

In any of the logic hooks, do you call save() on the record manually? That could be one of the reasons. 

The code that triggers the PDs, is a Logic Hook. It is an after_save Logic Hook with the order of 100. Every time you save a record, the PD will be triggered just like all of the other Logic Hooks.

My guess is that the record being saved multiple times?

But according to my observation, they don't actually work at the order of 100. Although it is mentioned in the community I analyzed it in detail. There is no proper order. If we place the order 100 then still there is no guarantee that it will run at the last. 
These all are work in parallel fashion sometimes it runs before and sometimes it runs after.
So, the only solution from my side explicitly checked the triggered module in the Logic Hook to make the distinction.

Maryam Aslam,

going off memory here, as I have not checked right now:

- I believe the hooks triggering SugarBPM are application level hooks, not module level hooks

- I believe that application level hooks trigger before module level hooks

- Going by the above two statements, if you want something else to trigger BEFORE, you would have to create an application hook with order < 100 through the extension framework. On the other hand, I would personally act always after the relevant BPM in most real-life cases... wouldn't you?

Hope it helps answer the ordering question, and feel free to try that out on a sandbox system too!

Cheers

Maryam Aslam,

going off memory here, as I have not checked right now:

- I believe the hooks triggering SugarBPM are application level hooks, not module level hooks

- I believe that application level hooks trigger before module level hooks

- Going by the above two statements, if you want something else to trigger BEFORE, you would have to create an application hook with order < 100 through the extension framework. On the other hand, I would personally act always after the relevant BPM in most real-life cases... wouldn't you?

Hope it helps answer the ordering question, and feel free to try that out on a sandbox system too!

Cheers

Hi Enrico Simonetti,

Thank you for the detailed feedback. The statement which you mentioned "I believe the hooks triggering SugarBPM are application level hooks, not module level hooks" I am not sure about the application hooks that PD also triggers for them too or not because in my project in which I experienced this behavior had no hook at the application level.

But I am pretty much sure about it that PD triggers for the module level hooks because suppose we created an after_save logic hook for the Contacts modules in which we are doing something and suppose we defined a PD for "Create Contact" when defined criteria will meet then the records which will create by the PD will also trigger my Logic Hook which I defined at the module level for Contacts.