Ahhh, the great automation debate: Process Builder versus Workflow. Both are powerful tools, both offering countless benefits. More than likely there is at least one of each kind of automation enabled in your org right now. But which one should you be using for that next automation request?
Based on Trailhead exercises, you should be using Process Builder. I have yet to take a trail that instructs Trailblazers to use Workflow. Just a few weeks ago I was participating in a Circles of Success at a user group meeting where we were discussing automation, and the bulk of the conversation was spent talking about Process Builder (and very little about best practices related to these tools).
Perhaps I’m old enough to still have quite a soft spot in my heart for Workflow. After all, I’ve been in the Salesforce community for 10 years now and Workflow used to be the only way a non-technical Admin could automate anything. Has Workflow fallen out of favor? Let’s find out!
Process Builder
This tool is definitely the new kid on the block. With all of its flashy Lightning Experience interface and all of the whiz-bang actions it can do (can I get a “holla” for the record create action?), it’s easy to be lured in by Process Builder’s siren call.
Process Builder is built atop the Flow (aka Visual Flow) platform but requires less technical ability than Flow. Because of the underlying architecture, it’s powerful too. Here are just a few things you can do with Process Builder.
- Leverage cross-object entry criteria
- Evaluate multiple entry criteria nodes in a single process builder (instead of say, using 80 Workflows)
- Create new records
- Create Chatter posts
- Call Flows
- Call Apex
- Submit a record for approval
With all of those benefits, Process Builder is a home run, right? Well, not so fast. There are some drawbacks to consider. For example, Process Builder is not bulkified in a way that allows for high volume transactions to be done en mass without significantly reducing the batch size. By reducing the batch size, I mean down to a batch of 10 records in some cases.
I’ve also experienced issues in highly customized orgs with lots of code and workflows where Process Builder doesn’t play nice. It has fired at the wrong time and reverted fields to old values; caused errors in bulk updates being done via code; and can be difficult to troubleshoot.
So, there are the traditional pros and cons. But what about Workflow?
Workflow
Workflow is the tried and true method that many of us are familiar with for automating business processes. It’s a workhorse. Based on the filter criteria, you can do things like update a record, or send an email. It’s simple and intuitive. It’s a minimalists dream!
True, the list of capabilities is much less impressive:
- Single object entry criteria (can only use data points found on the named object for criteria)
- New Email Alert
- New Task
- New Field Update
- New Outbound Action
Workflow is properly bulkified, meaning that Admins can run mass updates to hundreds, thousands, or millions of records and Workflows will fire and process their actions every time without fail.
But, like with Process Builder, there are downsides. Specifically, the reduced capabilities means that you’ll need to get creative with your field criteria by creating formula fields to pull related data to the object the Workflow is built on (this is a hack to cross-object entry criteria). One Workflow can contain only one set of entry criteria so you’ll need to create more Workflows to accomplish the same updates that one Process Builder can accommodate.
So, if you’re still following along, you’re probably noticing that there are major pluses and minuses to both. Which one will win this showdown?
The Verdict
The truth is that both tools are extremely powerful and terribly useful. The winner will be situational, meaning that you shouldn’t use one over the other exclusively, you should use both in your org. Evaluate the requirements, and determine the best tool for the job. Process Builder shouldn’t always be the tool of choice.
It boils down to this: if the requirements allow you to use Workflows, use Workflows. If not, then move to Process Builder. You’ll find far less issues with your business processes and related code, as well as data updates by first evaluating and using Workflow whenever possible.
Admin Hero Trailmix
If you’re new to process automation, don’t worry! Trailhead has you covered. Learn all about Workflow and Process Builder by getting hands-on with Trailhead and this custom Admin Hero – Automation Showdown Trailmix!
Have a different opinion? Leave a comment below!
Admin Hero 
What about how they interact with each other? In your opinion, if you’re working with an object that already has a Process as a prerequisite, does that skew the decision? Or when you want the new action in a particular place along the firing line.
For example I’ve been debating whether to move all workflows into a single process builder (where before there was a mix of Processes and workflows.) I’m still not sure which is the best move for either performance, or for firing order.
LikeLike
Great question Steph! I believe that Workflow and Process Builder fire at the same time in the order of execution which means that, technically, they should work well together. However, since the technology behind each is different, I’ve seen issues with the timing in several orgs. It could be that I’m not properly setting up the Workflow Rule or Process Builder to evaluate again if a Workflow Rule or Process Builder makes an update to the record. If your business process requires a very specific order of execution, I would stick with one over another (perhaps Process Builder) or look at moving to code which has much more flexibility in setting the execution order. The key for you will be to test the heck out of your solution and ensure it’s working as expected before moving the changes to production.
LikeLike
Great Post!!!!!!!
LikeLike
Thanks, Earl!
LikeLike
Thoughts:
Don’t assume you can use Workflow and have it work nicely with Process Builder… for example, don’t assume that workflow will make a field update and then the process will get evaluated. It can work, but a lot will ride on your process criteria. The order will go something like: Record Edit -> Workflow & Process -> Workflow Record Edit -> Workflow & Process. It can be a muddy complication you simply don’t want to have to deal with.
In my opinion, Process Builder has two big failings:
1. Error handling is terrible user & admin experience
2. Bulkification isn’t consistent and shares limits with Apex & Flow and there’s no way to check it
While Process Builder is “Bulkified” It’s not bulkified in the same manner as workflow rules AND it shares limits. So if you have 1 process that isn’t ALWAYS set to fire (Has actual criteria on it) and you’re doing little to no Apex or Flow… it’ll work just fine in most situations. Anything more complicated and you run a decent risk of hitting limits.
This is why I always recommend you always set the values of the records in your import that would normally have process builder set.
For example, You have Process Builder update a Territory Drop down field with “West Territory” whenever the Lead State is “CA” You should do this instead:
Process Where Lead State is CA and Territory Drop is NOT “West Territory”
Add column in your import CSV and use Excel formula function to pick the territory & import
Using this system your process won’t have additional actions to fire because your import records won’t meet the criteria to do anything.
LikeLike
Excellent tips, Brian! Thanks for the contribution of best practices!
LikeLike
Very big fan of PB! It’s allowed us to leap forward where we would have otherwise needed a much more technical resource.
The only downside for us is the really clunky view of the processes. No grouping or filtering to make that page not very useful even wit careful naming conventions.
LikeLike
Navigating the process and quickly identifying actions and criteria could be much easier. Heck, moving from one process builder to another could be much simpler and faster with improved navigation. I’m not hating on Process Builder, it’s a great tool, but needs to be used with some purposeful though and in the right circumstances. Thanks for the comment!
LikeLike
I’m also a big fan of PB but we do have to be smart in how we use it. Brian hit exactly on two of the common mistakes I see made with PB.
First, in the PB decision box, always check to be sure the process needs to run. If updating Field1 to “A” then make sure it’s not already set to “A”. It’s so easy to be sloppy and end up running processes that don’t need to run.
Second, always set the values in your file when uploading data so PB doesn’t have to.
The third thing I’d add is, don’t mix PB and WF on the same object if you’re in a highly customized (with APEX Triggers) org. If you have PB doing a field update and WP doing a field update, (unless SF has fixed this), the triggers will run at least three times. They’ll run before PB and WF, then WF will run causing the triggers to run a second time, then PB will run causing the triggers to run a third time. That will cause your system limits to escalate needlessly. So, watch that too.
LikeLike
Great comments! I’ve seen these same things in orgs and being sloppy has caused record locks, exclusivity errors, and other issues as a result. Part of the problem is understanding what some of the options mean in Process Builder because the explanations can be so vague. Thanks for the comment!
LikeLike
Don’t forget about those time based workflows – Process Builder has a miserable interface for confirming which records are pending actions, when and which action. WF has a lovely interface where you can see which records are scheduled and when for each workflow and even has a way to bulk delete items if you want to selectively remove notifications or actions from the queue.
Error messaging is also quite, well, miserable if you have apex running or other code as the fault email is vague at best and the actual condition that throws errors during the processing of the PB is often buried inside the debug log.
And of course trying to find a list of possible field updates or searching where your org is setting Type = Call for example is much more difficult- WF you can review the list view of field updates and *reuse* them across workflows. PB you have to click around and hover over fields to be able to see the full text and field updates are duplicated if they are needed in multiple situations.
I use PB only when really necessary (ie dynamically want to set user lookups or picklist values) but otherwise still love the old favorite.
LikeLike
YES! YES! YES! All of these are good reasons to only use process builder when absolutely necessary.
LikeLike
If I run into bulk errors with PB, I’ll often build in a “0 days after Rule Trigger Date” scheduled action which delays my PB action by a few seconds. This has solved a lot of those bulk error issues. I’m not sure if I’m hurting my org more than helping it with this, as it’s a common fix with my processes.
However, I am constantly going back to using Workflow if I’m able to achieve what I need with just that.
LikeLike
Interesting workaround, Micah! Thanks for sharing!
LikeLike
Hey Brent, any thoughts on whether Workflows will ever cease to be supported by Salesforce? I’ve been hearing Salesforce folks push Process Builder as the new Workflow, but I’m not sure if I’m reading too much into that statement, and making my own assumptions about Workflows going away in the future.
LikeLike
As much as Salesforce is pushing Process Builder, I’ve haven’t heard of Workflow being retired. I think it would be a grave mistake, and from what I know, it’s not going to happen (at least any time soon). This would be something that Salesforce would broadcast well in advance (like TLS 1.0 disablement) since it would have such a HUGE impact on almost every org. I wouldn’t be concerned with Workflow going away!
LikeLike
Great article. You hit the nail on the head. Sadly, I found out some of these lessons the hard way. Do we know if Salesforce has anything in the works to get PB to be more bulkified? Your flowchart is my new “go to” for choosing the right tool for the job.
LikeLike
I sure hope they do, but I haven’t heard anything. Looking at the IdeaExchange, this has apparently already been delivered, but that spurred a whole slew of new ideas expanding on the exact issues with the current iteration.
LikeLike
Brent Hi,
Thank you for the post!
I was wondering if your conclusion regarding this debate stays the same.
I’m a PB fan. Lately, I had a disagreement with my co-workers regarding this debate. They want to stay with Workflows since they think it’s more stable. I vote for PB, although I agree the Error handling is poor.
Sometimes, Salesforce Admins create a Workflow and after a month they realize they need another Workflow with a similar logic (but a bit different). So now they would create another Workflow and another one and eventually, they will end up with many Workflows.
I prefer to create the process via PB from the start and then when an additional action is needed, I will only add another PB criteria on the existing process.
A month ago I’ve “squeezed” a dozen of Lead Workflows into one Process Builder.
When you have so many Workflows, some of them might run together and It’s very hard to control their firing order.
Moreover, it is difficult to understand the logic of so many Workflows. I think It’s (a lot) easier to understand PB.
By the way, In the ‘Workflow Rule Migration’ module in Trailhead, Salesforce wrote: “Say Goodbye to Workflow and Hello to Process Builder”. It seems to me that Salesforce already chose a side 🙂
Best Regards,
Gidi
LikeLike
Hi Gidi! Yes, my conclusion still stands! Workflow first, then Process Builder. As a non-coding Admin & Consultant, I’m a fan of the Process Builder and its superpowers, but I’ve also seen it wreak havoc by throwing errors left and right with bulk data processing. Workflow is far more stable for use in those situations where bulk updates may be needed. Thanks for your comment!
LikeLike
Thank you, Brent, for your reply!
LikeLike