3

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:

  1. When Recursion - Allow process to evaluate a record multiple times in a single transaction? - YES

On Account update, there were 7 trigger cycles.

  1. 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.

1

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.

1
  • @salesforce-sas, did this actually resolve your issue? Was it side-effect executions due to not protecting the update with a condition?
    – Phil W
    Mar 17 '20 at 19:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.