Our org has recently got many transactions with 101-soql error and apex CPU time error (and many other performance problems). On analysing we found that its basically because of process flows. We found some queries running upto 24 times.
Here is what I analysed:
Created a new dev org and implemented process builder on Account to update its Description = Name + ' Some description'. Implemented Account trigger on before/after update and debugged only some info – no logic in trigger.
Lets consider 1 trigger cycle is before update and after update together.
Observed following:
- When
Recursion - Allow process to evaluate a record multiple times in a single transaction? - YES
On Account update, there were 7 trigger cycles.
- When
Recursion - Allow process to evaluate a record multiple times in a single transaction? - NO
On Account update, there were 2 trigger cycles.
Now, this does'nt make sense. If I simply want to update description field, why would trigger get invoked 2/7 times? For example, if I do the same thing in trigger code (in before trigger), only 1 cycle is run.
Salesforce keeps highlighting go for declarative approach if available or else go for code. And so many companies implement process builders for simple to medium complex tasks like above. But this appears to be hugely affecting performace when apex triggers are there.
Does this mean when triggers are there, we should never implement process builder? Or
For what use cases can we implement processes without hampering performance?
—– added ——-
According to apex steps of execution (https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm), processes run after before and after triggers. So it makes sense that trigger cycle has run 2 times when Recursion - Allow process to evaluate a record multiple times in a single transaction? - NO. When Recursion is enabled, it should ideally run for only 1 more time (3 times total), but why 7 times.
Best Answer
In the process builder, have one more criteria to the node of the process builder, such as update description only if it is null or if the field has changed. Having these kind of checks prevents multiple updates in one transaction.