Process Builder Vs Flows – Become the Ultimate Admin
We’ve previously discussed Workflow vs. Process Builder vs. Apex, but there’s another automation tool Admins should have in their tool belts as well, called Flows.
Flows, while purely a declarative tool, sit between Process Builder and Apex. In fact, Process Builder and Flows are both built on the same Salesforce feature called Lightning Flow. Although it has Lightning in the name, both tools are available in Salesforce Classic.
Beginning with Spring ’19, we have a new tool for Flows called Flow Builder. It replaces Cloud Flow Designer, which was a Flash-based tool (there are several additional enhancements in the new tool on as well.)
What’s the difference?
If both Process Builder and Flow Builder are built on the same feature what is the difference? It’s fair to say that Process Builder is purposely a slimmed-down tool. It’s designed to be a simpler tool to use, targeting the most common use cases while jettisoning more complex features. When Process Builder can do the trick that’s going to be the tool of choice.
Process Builder is pretty linear — if this occurs, then perform these actions. While you can make rather complex Processes with multiple conditions and multiple actions everything is Either/Or. Process Builder works much like IF does in formulas: Condition; Actions when TRUE; and then perhaps other conditions to evaluate when the Condition is FALSE.
Logic in Flows is more analogous to CASE formulas: Condition; Actions if A is TRUE; Actions if B is TRUE, etc.; Actions if nothing is TRUE. Just like nesting a bunch of IF conditions can be tedious and confusing in formulas, you can more easily build complex conditions in Flow as you can with CASE functions.
And it’s not only the decision logic that makes Flows more powerful; there are more actions you can take. Besides performing all of the actions that a Process can, Flows offer a few more, including delete.
One of the most powerful features is the ability to evaluate and update or create multiple records. While it’s true that Process Builder can update multiple records, that’s limited to only being able to update child records of the one that started the Process and all of them need to be updated and all in the same way. With Flows it’s possible to only update records that match a condition and they don’t even need to be related to the original record.
Here’s an example: Let’s say that you have an application where people manage schedules and need to fill shifts. You can allow users to update their own record to indicate which day(s) of the week they are available. You’re likely going to have dozens of combinations of folks’ availability. So what you want is to notify all users that have said they are available for a given shift when a Shift record is created. Well, with a Flow you can take that action by looking through all of the available records and only emailing those that match.
This combines two key features in Flow: the ability to loop through a series of records and also to create a Collection in memory of all of the matches. The action step is applied to all of the records in the Collection.
For illustrative purposes, here’s what such a Flow might look like. As you can see, it’s not linear like Process Builder.
Create a Screen Interface
Something else you can do with Flows is create Screens. These are what they sound like; you can dynamically control the user experience.
Display data to your users or collect information from them with Screen elements. You can add simple fields to your screens, like input fields and radio buttons and out-of-the-box Lightning components like File Upload.
Again, for illustrative purposes, here is an example of how your screens will adjust based on the data and actions your users take.
Want to learn Flows?
I mentioned before that Flows sit somewhere between Process Builder and Apex. When you get to building Flows you are going to need to do some things that feel a little like writing Apex. You’ll need to declare variables, be comfortable with terms like sObject, and understand Collections. If you are familiar with the basics of Apex, that will be a breeze, but if you’re not, don’t let it scare you off. It’s not much different than writing formulas that Admins write all of the time.
The syntax is a bit different, but there are plenty of resources that will guide you through what you need, including a Trailhead Trail, some tutorial videos, and a series of posts here beginning with An Introduction to Salesforce Flow.
If you’re used to writing Apex, something you’ll appreciate about Flows is, precisely because it’s not code, you don’t need to write Test Classes! You can also Validate and Deploy much quicker because you don’t have to run through the code existing in your Production org to do so. As an Admin, harnessing the power of Flows vastly extends what you can deliver for your users without calling in a developer, freeing them up to work in the projects that really do require their attention.
hi Michael nice articles on salesforce platform. we also at http://www.cloudanalogy.com write problem solving content and give servies to user .please check if you have any spare time.thank you 🙂
Christine Parker Hunt
Very helpful! Thanks!
I love how simple the article is to read and understand almost like having a little chat. Thank you! Very helpful!
Crystal clear, thank you very much.
Would be interested to have your feedback on Flow builder in summer 20 release as it seems to be pushed in the front by salesforce.
Should we move to Flow builder in the future even for simple automation actions that could be done today with Process Builder ?
Explaining difficult stuff in a clear simple way can be done only by the true Knowledgeable persons. Thanks a lot Michael!
“you don’t need to write Test Classes! You can also Validate and Deploy much quicker because you don’t have to run through the code existing in your Production org to do so”
But isn’t this exactly what WE DON’T want to do, letting code with no test classes to be on Production org. Granted, you are testing the flow as you develop it but how do you get assured that in the mix of things, this will not break apex code on the org. I think one has to be careful with what customisation/automation added, and the dev team need to be aware of it. That is if your salesforce org is part declarative part apex