Salesforce Sidekick

Have you ever had to wait a moment before a record saved?  Did you think it might be something you built that is causing Salesforce to screech to a halt?  With Process Builder gaining momentum in the Salesforce ecosystem, it is important that we encourage everyone using Process Builder to build their Process to be as optimized as possible.  The trouble is not everyone actually knows what is going  on under the hood of Process Builder.  In this post, thats just what we’re going to do!

*Disclaimer, my main talking points will be related to using Record Updates, but the concepts apply throughout your use of Process Builder. 

The two main design routes (from 30,000 feet) that we can choose from:

Option #1 – Minimal Criteria – Tons of Actions with Criteria

Option #2 – Tons of Criteria – Minimal Actions and No Action Criteria

Lets discuss our business case for a moment.  You need to build a Process Builder to updating a picklist with the correct ‘range’ this Account falls into, based on the Annual Revenue.  Simple enough, right?  Before you head back to your desk, your manager just decided he wants to add an Email Alert and Chatter Post to happen every time this happens.  Does additional set of criteria change your mind on which option you’d go with?  It shouldn’t!

Why would you want to go with Option #1?  For starters, it is the easier option.  You’d only have to create the Email Alert action and Chatter Post action once!  But, the correct answer is Option #2.  However, lets keep going down the rabbit hole with Option #1, and really understand why we don’t want to do it.

If we went with Option #1, we would set our first criteria to simply check when the field’s value has changed, and then put a criteria on each Update action to determine if it meets the specific picklist value or not.  So, we’re only actually doing one Record Update in theory… right?  Not exactly…

If you notice, every action inside the criteria is run through, not just the ones where the criteria is met.  Yikes!  Now, lets take this a step further… what exactly is a Record Update?!

A Record Update is a pretty way of writing code for us.  We’re essentially doing a query of our Salesforce to find an Account that meets our Green criteria. If the record meets that criteria, we will go through and do our Update (highlighted in yellow).  Every single Record Update in Option #1 is occurring, even if the record doesn’t meet the criteria.

If you’re used to building Visual Flow, this is essentially what you just did with your Process Builder:

That is an awful lot of backend work that doesn’t need to be happening, and as of now we have no way of adding in an If… else or using some sort of Map like we could with Apex.

So, lets take a look at why Option #2 is the right choice.  We replace adding in a filtered Record Update with using the Criteria to do the filtering for us.  Our Criteria are essentially Decisions in Process Builder form.  Decisions/Criteria are speedy and require very minimal effort from Salesforce to navigate through to find the one that has the criteria met.  By doing it this way, we only actually process the Record Update(s) that we have to.  This change in architecture actually helps you bulkify your Process Builder and improve your overall performance:

1. Fewer queries
2. Queries are smaller (we wouldn’t have the additional filter on the AnnualRevenue counting against our character limit)

All of this means you get to have some speedy Process Builders that even Neo would be proud of!  And, hopefully that translates into Process Builders that your End Users love to use!