For me, the Process Builder was kind of like finding a magic unicorn.
Seriously, think about it – it does so many things that we could previously only accomplish with Apex code. It also takes workflow functionality to a whole ‘nother level! This example of Workflow Rule vs. Process Builder is my favorite…
The request: “We have this field on the Account, that tells us which Account Manager should be assigned to a specific customer. We need you to automate assigning an Account Manager based on where the account is located/how much they’ve spent/support level/whatever criteria.”
My response: “Yes! A workflow rule! No problem.”
Sound familiar? (I know I’m not the only one who has walked right into that one!) I went to create my workflow rule, and found that, in a field update to a lookup field, you are only able to assign one value to that field. This meant that I had to have a separate workflow rule for every Account Manager.
So… I built out all of those workflow rules. And I’ve done this more than once, for different lookup field requirements. One time, I actually created fourteen workflow rules – each with a different field update – for one lookup field. This is a perfect example of how, as admins, we sometimes create system clutter because we need a workaround. Only we admins can see it – but it’s still clutter! (I won’t even go into what a mess I made when Account Managers began switching territories, leaving the company, etc…)
And then one day, the perfect solution appeared like a magic unicorn – the Lightning Process Builder! When it was first rolled out, it promised a lot – and I just couldn’t wait to experiment with it. One of the things it promised to do was to give us the ability to consolidate multiple workflow rules into one Process – so naturally, that’s where I went first.
Process Builder has many similarities to Workflow Rules. Just like a workflow rule, it begins with an object. And just like a workflow rule, we can specify whether the Process runs only when a record is created, or when it is created/edited.
Then – also like a workflow rule – we can set criteria, and add field updates based on those criteria. But – and this is where Process Builder goes beyond workflows and gets magical – we can keep adding different criteria nodes, and have a unique field update for each one of them. Bonus: it will go through the criteria nodes in order – if the record does not meet criteria #1, it moves to criteria #2, and so on. This is great if you want to have a final criteria node to assign a default field value to records which meet none of your criteria.
Isn’t that pretty? If you aren’t yet familiar with Process Builder, here is how this works under the hood:
There are basically three things you need to do in a Criteria Node:
- Name it.
- Set your conditions (or use a formula if you prefer) – you can also add AND/OR logic just like a workflow rule.
- Determine whether you want the Process to fire only when the record is edited to meet the conditions, or every time the record is edited (and it happens to meet the conditions).
Then you can add an “Immediate Action” – for a field update, select the Update Records option.
An Action has several things to specify as well:
- Name it.
- Select what to update – here you are given the option to update the record which started the Process, or to update records related to that record.
- Optional: add more conditions that determine whether or not to make this update – very cool if you want to add several actions within the one criteria node, but say, one of the actions should only make updates if a certain field is null, etc.
- Add your field updates!
Fun bonus: When setting the lookup field value, you can specify the one value (using the ID, as I did in the above example), or you can reference and copy a value from a field on a related record! For example – if I have an Account Manager on the Parent Account, I might want to copy that Account Manager to the Child Account. To reference a field instead of setting an ID, change the Type from ID to Reference:
Then, click into the Value box and a new window will open. Select Parent Account ID to access fields in your account’s parent, and then select Account Manager as the field value to copy.
Now it looks like this (hover over the Value to view the full field name):
Voila! Now that’s magic.
This is only one use case for the Process Builder – but the possibilities are endless! Do you have multiple workflow rules that you want to combine? Do you want to do more than just send an email or update a field? Well, now you’ve got a magic unicorn that can help you. If you’re not sure where to start, try this Trailhead module, and have fun with it!
Is it possible to autopopulate also an contact to an account if some criteria Matches ? (for example Accountnumber)
Hi John! I’m not sure I understand the question – what would you be auto-populating, on which object?
Is there a way in process builder to set the lookup to a specific user based on username or something similar instead of hard-coding the ID?
Yes! You can do it based on a formula as well.
This is a beautiful post. I already tested and started to use it and I have questions.
I created a process in which the action is – update a lookup field (client manager user) in a custom project object from a user field in the account.
Projects are connected to accounts by lookup relation.
From my experience when creating a new project with an account in which the client manager exists the process work perfect and the user is updated in the project.
However, when that field in the account is empty, the process fail and the new project record can’t be save.
What should be done when the resource field is empty?
Ahh, that can be tricky. I believe you need to specify NOT (ISBLANK (Client_Manager__c)) in the criteria node, or as criteria for that action to take place.
Hi Celeste Kelle,
This is a great post which provides the power of process builder compared to workflows. Just a quick question. Once you have an account manager updated for an account based on criteria like zipcode or whatever, how do you setup permissions on the account? Who is the account owner? The sales rep who works on the account or account manager..We have a need where we want to create account managers own the account and how do we have sales reps who can work on multiple opportunities in the account still see account , contact and opportunities?
Thanks so much, I’m glad you enjoyed the post!
My account owner is usually different from the account manager – but the account manager as well as other support agents can see the account because they are on the default account team:
I believe the same can be done with default opportunity teams, but we are not currently using opp teams.