Ask Search:
Beth FollenweiderBeth Follenweider 

Order of Operations within Process Builder

I am pretty new to Process Builder and this may seem like a rudimentary question but I've had difficulty finding an answer. 

I have several fields I want to update on an Account record when an opportunity is created, updated, or deleted.  I have set up initial criteria for this.  Then to determine which field to update on the account, I need to check the value of a picklist on the opportunity.  

Clearly I can create different criteria for each field I want to update.  But it would be so much more efficient if I could use an if statement against the opportunity object when updating the account object.

If picklist = '1' then update field 1 else if picklist = '2' update field2.

So - my questions:
Is it possible to embed criteria against the calling object during the update?
How are the updates processed?  Are the updates happening in bulk or record by record? 
If record by record, when does the read from DB and "lock" (if there is one) on record happen?  If I set up several criteria, will the operation need to read the same record for every criteria?  or does it read the record once at the beginning of the process and make all updates?

Thanks for the help - trying to ensure I make the most efficient use of my resources!
Best Answer chosen by Beth Follenweider
Jeff MayJeff May
Q1 - you can do this in 1 PB -- use the 'evaluate next criteria' option after the first few blue diamonds to make sure you get to the last one to do the final update.

Q2 -- correct, just like Workflow Rules

Q3 - There is one, with all the updates - assuming the fields are all updated from the same action. In general, you want as few PBs as possible on each Object, and as few 'matching diamonds' as possible. Within each diamond, you can have as many Update Record actions as you want, but you want to only have 1 Update Action record for each related record (do all the Account updates in the same action)

Overall -- PB is very inefficient in terms of CPU time, and DML (database commits). And, it has a very narrow 'current record context' (unlike Workflow Rules that have 'in context' the fields from the current record and its related records). Why?  Because PB is just a UI for Flows. And, if you've ever written a Flow, if you don't retrieve a field, you can't use its value.  When a PB runs, it retrieves fields just from the current record. Everything else is out of context.

Ending up exactly where you did:  if you have a lot to do, and want it done efficiently, use a trigger or a Flow, which you build and control.

All Answers

Steve MolisSteve Molis
This is the Salesforce Order of Execution 

NOWLEDGE ARTICLE
Process order for automation rules and Apex triggers
Knowledge Article Number 000005694 
https://help.salesforce.com/articleView?id=000005694&type=1&language=en_US
Beth FollenweiderBeth Follenweider
Thanks Steve - Title may be somewhat misleading.  I am aware of the order of operations from that perspective but I'm trying to determine how Process Builder updates data in the database so that I can be efficient when using process builder.  We're a small org with a lot of external processes that hit quite close to our limits.  I need to be as efficient as possible when using resources - which means I would really like to understand the mechanics for how this works.  
Jeff MayJeff May
Each process builder process is its own Flow, and it will update the fields as you've defined in the process.   When a record is updated by a Process builder process, the order of execution is applied.
Kevin StrangeKevin Strange
Hi,
 I may not be reading this thread correctly - BUT I think Beth is wondering about the Order of Operations "within" Process Builder itself.  Which process fires first, fires second etc as this would matter depending on the data and how she wants to process the data.   

Beth,
 I'm not sure what you mean by "hit quite close to your limits".  I wouldn't worry about salesforce process limits - 
Jeff MayJeff May
@Kevin - you can't control the order within identical steps of the order of execution. In other words, any Process that is defined on an object update could run first, last, or in the middle. The Order of Execution is well defined for diffferent steps in the transaction though (so, triggers always fire before Workflow Rules)
Kevin StrangeKevin Strange
Jeff - I realize this - I only commented that it looked like Beth was wondering about the order of execution strictly within PB Processes as she said:
"but I'm trying to determine how Process Builder updates data in the database so that I can be efficient when using process builder." 




 
Beth FollenweiderBeth Follenweider
Apologies for the confusion, I am/was trying to determine how efficient process builder is. I was fairly new to process builder so my wording is a little off.

I have 3 fields on my Account object A1, A2, A3, A4.  I have two fields on my opportunity: O1, O2
This is the logic I was trying to accomplish: 
  • If O1 = X then update A1 = O2
  • Else if O1 = Y then update A2 = O2
  • Else if O1 = Z then update A3 = O2
  • And no matter the value of O1 update A4 = O2
Q1: Can I build this into a single statement and avoid using 3 steps for this process.  I now know that isn't possible.  and therefore have 3 steps in the process builder, all evaluating the value of O1. (aka: ANSWERED)

Q2: Are the updates being made in a batch?  I should have been more clear.  If I batch update 200 records, will the process builder fire one time for each record or could they be processed in batch?  I now realize that this would be a record by record based operation by nature (aka: ANSWERED)

Q3:  My next question was how Process Builder would operate on multiple updates to the same record. Let's use a different scenario:
3 Fields on Account object A5, A6, A7; 3 fields on opportunity O5, O6, O7
  • If O5 = q then A5=​ 1
  • If O6 = K then A6 = 2
  • If O7 = J then A7 = 3
All of these updates are happening on the same Account record but each step is evaluated individually.  So, if the value of O5 is q and O6 is K and O7 is J, then are there 3 separate commits to the Account object/table or 1?  Could I change the second line to be:
  • If O6 = K then A6= 2 + A5 
and expect the value of A6 to be 3?

Ultimately it comes down to how often the process builder commits.  This was important to me at the time because I wanted to control the updates because I wanted to control the triggers.  But then I decided that Process Builder is kind of buggy and wrote custom code for the problem I was trying to solve. :)
 
Kevin StrangeKevin Strange
Hi! 
  Glad to see you solved your issue -  It does seem like Process Builder is becoming more and more stable with each release - If you are familiar with Flows then there are a couple of things you can do to control PB processes - anyway I'm glad you figured it all out!  Nice job!
Jeff MayJeff May
Q1 - you can do this in 1 PB -- use the 'evaluate next criteria' option after the first few blue diamonds to make sure you get to the last one to do the final update.

Q2 -- correct, just like Workflow Rules

Q3 - There is one, with all the updates - assuming the fields are all updated from the same action. In general, you want as few PBs as possible on each Object, and as few 'matching diamonds' as possible. Within each diamond, you can have as many Update Record actions as you want, but you want to only have 1 Update Action record for each related record (do all the Account updates in the same action)

Overall -- PB is very inefficient in terms of CPU time, and DML (database commits). And, it has a very narrow 'current record context' (unlike Workflow Rules that have 'in context' the fields from the current record and its related records). Why?  Because PB is just a UI for Flows. And, if you've ever written a Flow, if you don't retrieve a field, you can't use its value.  When a PB runs, it retrieves fields just from the current record. Everything else is out of context.

Ending up exactly where you did:  if you have a lot to do, and want it done efficiently, use a trigger or a Flow, which you build and control.
This was selected as the best answer
Anha SinghAnha Singh
User-added image
Pawel DobrzynskiPawel Dobrzynski

Seems like Jeff's May answer from November 3, 2017 was the most relevant answer and this one should be marked as "Best Answer".

Thanks, Jeff for this clarification - the official docs are missing this kind oif nitty-gritty (or it is hard to find)

Beth FollenweiderBeth Follenweider
Thanks Pawel, I didn't see Jeff's answer.  It is indeed the best answer.

Thanks Jeff - this is exactly what I was trying to evaluate.  I have lots of triggers firing from a managed package and keep hitting SOQL limits.