The end of Process Builder and Workflow Rules?
Salesforce tips
Getting on the Flow-train
Automating complex business processes without having to write a single line of code has long been one of the many fantastic aspects of the Salesforce platform. It seems like eons ago when Salesforce first gave us the Workflow Rule engine.
Then in 2015 Process Builder hit the shelves, and it was absolutely amazing. Suddenly we weren’t limited to just updating parent records, but could also create new records as well as updating related records in both standard and custom objects. It’s fair to say that Process Builder provided system administrators with a tool that – at the time – seemed like it could reasonably compete with Apex.
For a really long time I saw Salesforce Flow (formerly Visual Flow and Lightning Flow) as the extra-complicated version of Process Builder and Workflow Rules. I didn’t use Flow if it could be done in Process Builder. It just seemed too ‘heavy’ in my view, and I saw little reason to adopt it as my go-to tool.
What changed?
My point of view changed for good about a year ago – for three reasons:
- I witnessed first-hand how much quicker records were getting created or updated using Flow compared to Process Builder/Workflow Rules
- Salesforce expanded the capabilities of the Flow tool to include both record-triggered Flow and schedule-triggered Flow
- In June 2020 Salesforce officially changed their recommendation to say that Process Builder and Workflow Rules would no longer receive product updates, and Salesforce Flow would henceforth be considered the new tool of choice for declarative process automation
Now I have definitively boarded the Flow-train, and I’m not looking back.
Here is an example of a Flow:
Salesforce Flow which creates a platform event
What exactly did Salesforce say?
In June 2020 Salesforce published a blog post (read it here – it is still getting updated) which detailed Salesforce’s own views on what would – from that point onwards – be considered best practice for process automation in Salesforce. The blog post listed 3 key takeaways:
- Takeaway #1: If you need to update a Salesforce record, use a “BeforeSave“ Flow, as this is faster than Process Builder (they could possibly outperform Process Builder by a factor of 10). End users will be able to save and update records a lot faster!
- Takeaway #2: If you need to create records or send emails, then use an “AfterSave“ Flow – this will also increase the performance for the end user when compared to using Process Builde
- Takeaway #3: If the logic of a Flow gets overly complex then it’s probably best to move it to Apex coding
In other words; don’t increase your reliance on Workflow Rules and Process Builder, and start leveraging Flow instead. Because Salesforce won’t enhance Workflow Rules and Process Builder anymore, but they are investing heavily in the ongoing development of Flow.
What is Giveclarity’s recommendation?
In the autumn of 2020 we starting training our own consultants to help them get more familiar and comfortable with Flow, and it is now considered our standard in any new project to use Flow where we might previously have used Process Builder or Workflow Rules. Even to this day, there exist some minor functional gaps, i.e., things PB and WFR can do which Flow can’t. But Salesforce is continuously closing that gap.
Our high-level recommendations are:
- Don’t create new Process Builders or Workflow Rules in your org – start getting comfortable with Flow
- If an existing Process Builder or Workflow Rule is causing an issue, then convert it to a Flow instead of trying to fix the PB/WFR (the complexity of the existing PB/WFR must be taken into account when attempting this – you might not want to dive in at the deep end on your first try!)
- If an existing Process Builder or Workflow Rule is working well in your org, then leave it where it is
With regards to recommendation #3 we do have a caveat; if there is a single step in your existing Process Builder that is causing a problem, then we recommend converting the whole Process Builder to one or more Flows. This is in line with the general recommendation of aiming to have a single process automation tool per object, i.e., avoid having both Process Builders, Workflow Rules and Flows on a single object.
Bye, bye Process Builder and Workflow Rules?
So, is this the end of Process Builder and Workflow Rules? Well, not quite (yet!). Salesforce will continue to allow system administrators to maintain existing and create new Process Builders and Workflow Rules.
But think of it in the same way the Classic interface is still available; it’s not going to be enhanced any further, and at some point you’re going to want to move on from it. And both you and your users will be happy that you did.
Salesforce Flow which auto-populates a record name
How to make the transition to Flow?
There is some excellent training material available online:
- SalesforceBen.com – one of the most revered blogs in the ecosystem – has some great introduction posts about the basics of Salesforce Flow:
https://www.salesforceben.com/introduction-salesforce-flow/
- Terry’s Tidbits – a YouTube channel – has some excellent material which can help walk you through how to get comfortable with Flows if you are used to using Process Builder:
https://www.youtube.com/playlist?list=PLPXY38WvYAn6TcMkMCzzQhCPtOHbbRkYQ
And of course you can always reach out to Giveclarity for a refreshing chat about Salesforce Flow!
Aske Bong-Saxe is Head of Functional Solutions at Giveclarity, and has been lead consultant on multiple large Salesforce implementations for Giveclarity, including our UNICEF Sweden project which won the ‘2020 Partner Innovation Award’ in the Nonprofit category.
Giveclarity are a Salesforce partner working exclusively with charities, providing Salesforce consultancy, training and support.