function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
CRM JediCRM Jedi 

Workflow Field Update cause trigger to re-execute, but not reseting the limit

Example of the scenario:

 

The LIMIT - maximum number of query is 20.

 

We have a trigger with 10 queries. So each execution will take away 10 from the LIMIT.

 

After update, field update executes, and cause the trigger to run again. However, the LIMIT is not RESET. When the second execution starts, it starts from the limit of 10 (due to the first execution), which ended up 20 queries in one execution.

 

Our problem now is that we have more than 10 queries in our triggers, multiple execution will cause "Too many SOQL queries: 21" error. Multiple field update will also cause this issue. (this also applies to other limits like script statements)

 

The question here is: Can we reset the LIMIT when field update triggers the trigger again?

sfdcfoxsfdcfox

No, you can't reset these limits; they're in place to prevent excessive platform usage. Instead, you should rewrite your triggers such that they take into account recursion and therefore don't execute a second time. It's hard to say exactly how to resolve the issue. It could be as simple as redesigning the triggers to check and see if any work is necessary, or maybe just combining multiple triggers into one trigger, or optimizing your queries by taking advantage of relationships or subqueries.

CRM JediCRM Jedi

That's bad news :(

 

Our company actually implemented quite alot of functionalities on the object, and new requirements are coming in every release. We've already did our best to optimize the code but is now reaching the bottle neck where we can't reduce the number of query anymore. This would also mean that we will not be able to implement new functionalities to this object.

 

Not using WF Field update might be the only option to prevent this from happening, which beats the "no code" principal of SFDC :(