We have a Process Builder which currently gets a hardcoded Salesforce Id out of an abused label and assigns it to the record. Of course, this means the solution causes tests to fail outside production.

I would like to refactor it. Instead, I'd like to store the name of the record in a custom setting, use SOQL to look up the Id, and then assign the Id to the record. But, obviously, because of governor limits, I don't want the SOQL to execute again for every record.

If I store the value in some static variable and check whether the value is null before executing the query, or using the value if it is not, can I rely on the SOQL query only executing once regardless how many records are being processed?


Process Builder is bulkified, which means it would only perform one query per 200 records. That said, if you wanted to store data in a static variable, it would persist across the entire transaction, in before triggers, after triggers, and yes, even InvocableMethod calls. I would suggest simply trying the query-then-assign method by using Process Builder + Flow unless you really need the extra performance.

| improve this answer | |
  • I may look into it, but honestly, ultimately I want to kill the entire PB anyway. – Brian Kessler Sep 18 at 16:42

If your Process Builder is doing any record field updates then be aware that each of these is dealt with in a separate invocation of your entire "save procedure", as per point 14 in the order of execution documentation, but as part of the same transaction/session.

This can cause you all sorts of trouble if any related triggers are not written to cache relevant query results (e.g. easily exceeding the SOQL number of queries limit, the SOQL number of records limit and even the CPU limits). Take a look at the governor limits documentation for further info on limits you face.

Of course, the queries you need to cache may actually vary on the records input to the process, and maybe even the data in those records, so you might have to do some clever stuff to invalidate parts of the cache and requery some data if inputs to the query change (due to specific changes in the records). This may then mean you are scuppered anyway (e.g. because each iteration through the PB/trigger sequence causes additional changes that invalidate the cache) and here you then have to refactor the solution, likely removing the PB and replacing it with processing in your trigger(s).

| improve this answer | |
  • 4
    It's exactly this sort of thing which makes me want to wipe PB off the face off the planet. – Brian Kessler Sep 19 at 23:32

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.