Retirement of Process Builder and the future with Flows
10 min
Salesforce has always believed in the value of Automation and thus has invested in continuously developing tools to make the lives of its users a little more convenient. Back when Salesforce started, there were only two business automation tools: Workflow Rules and Flows – not to be confused with the new Lightning Flows that Salesforce currently supports. While Lightning Flows runs on the latest version of HTML5, its predecessor runs on Flash, which as of December 2020, is already unsupported in all modern browsers.
In Spring 2015, Salesforce released a new automation tool – Process Builder, a revamped version of Workflow Rules. This allowed users and administrators to somehow work around the many challenges Workflow Rules faced. You can even say that Process Builder is a user-friendly version of Flows. This empowered Salesforce Administrators and business users to build more complex business logic with a few clicks of a button.
However, a new feature also comes with its own sets of challenges. For one, Salesforce now ended up supporting three different tools that serve almost the same purpose, with a few variations here and there.
- These problems include, but are not limited to:
- Business requirements are getting complicated, requiring much powerful tools.
- Expensive and tedious to create and maintain business automation processes across multiple tools.
- Difficulty in debugging which automation tool caused an error.
- Difficulty in keeping track of the overall picture of all automation, mainly when spread across multiple products.
- Having various automation tools will likely hit the Data Manipulation Language (DML) limit per transaction, especially if most of the logic done are field updates.
- Processes share some limits with Workflow Rules and Flows. Please see Process Limits.
Before the introduction of Flow Builder in Spring 2019, users were forced to use the most straightforward tool which would fit the bill. Remember the days when only Workflow Rules could do Outbound Messages? Now, we are coming to a period where all these three automation tools’ capabilities are being supported into one – Flows!
The evolution of Flow
Flow was originally one of the three declarative tools which allow you to automate complex business processes using the “click, not code” approach and is by far the most versatile of the three.
In 2012, Cloud Flow Designer, also known as Visual Workflow, was released but was entirely built using Flash.
Then in 2019, as modern browsers started to phase out and end support for Adobe Flash, Salesforce released Flow Builder with the full intent of replacing the old Visual Workflow as its non-Flash alternative.
How powerful is Flow?
Flow is a much more powerful and capable feature than Workflow Rules or Process Builder. Most, if not all, of the challenges experienced in using either tool, have been addressed and implemented in Flows.
- Flow brings the following:
- Fast Field Updates (Before Save) for improving same record update automation.
- Better Error Handling, Troubleshooting and Debugging.
- Can be made granular as a sub-flow so that it is repeatable and reusable.
- Able to perform actions that used to be done only using Apex Triggers, such as Before-save and being a listener for Platform Events.
- Can whip up a quick form and do simple actions depending on the user inputs.
- Overall better performance, with the ability to streamline high-volume automation via features like Run Asynchronously, Entry Conditions, and fast field updates.
Besides the migration of many features built onto Workflow Rules and Process Builder, Flow also offers a lot more flexibility and variety thru its different categories:
- There are five main categories of Flows:
- Screen Flow
- Schedule-Triggered Flow
- Record-Triggered Flow
- Auto-Launched Flow
- Platform Event-Triggered Flow
Screen Flow
Screen Flows can be initiated through a Button or an Action. You can launch or embed a Screen Flow within a Visualforce Page, Lightning Aura Component, or a Lightning Web Component.
Screen Flow takes the User through on-screen, step-by-step questions or text. Information inputted by the user will determine the subsequent actions.
You can also let your users “pause” flows. It is handy when users cannot finish a flow interview (a running flow instance). An excellent example is when a customer does not have all the necessary information. It enables the Service Representative to pause on the screen where the lacking information is and continue working on the same screen next time. Please see: Let users pause interviews on how to enable it.
Schedule-Triggered Flow
Schedule-Triggered Flows are auto-launched flows that run at a specified time and frequency. You can say it is the declarative counterpart of the Apex Scheduled Batch Job. However, unlike its Apex counterpart, you can’t change the number of records it processes per batch - they only run in batches of 200 records.
Before you start using Schedule-Triggered Flows, please spend some time reading the considerations using Schedule-Triggered Flows here.
Record-Triggered Flow
A Record-Triggered Flow runs when a record has been created, updated, or deleted. You can also specify when this flow will be triggered – before (for Fast Field Updates) or after (for Actions and Related Records) the record has been saved to the database; it is considered the declarative counterpart of Apex Triggers.
If you are not familiar with the concept of before save or after save - remember governor limits? When doing a field update on Workflow Rules or Processes, it always runs after the actual save on the database. This means one field update consumes one precious DML statement out of the 150 you are allowed in one “transaction.”
- What is a transaction?
- An equivalent to an action, just like when you click a button. All the actions done after you click the button will be counted against the allowed limit.
- For example: If you have 3 workflow rules and 5 processes that update accounts, you will consume a total of 8 DML statements. This is on top of the DML statements that an Account Apex Trigger will make. 150 DML statements might seem many, but you are bound to hit the limit if your organization has lots of automation that do the same thing.
For more information, please read some other considerations here.
Fast Field Updates
Fast Field Updates are used to update a field on the same created or updated record. This optimizes your process because it does not consume any DML statement. However, you cannot do anything else like updating related records and other actions besides updating the fields in the triggering record.
A consideration when using Fast Field Update is the order of execution. I recently migrated all field updates into Flows and stumbled upon this learning: I used a field in a condition, and the action after the condition is not executed. The reason is that the field’s value is determined using a complex logic in a “before insert” trigger. Before-save flows run before Before-save Apex Triggers.
Actions and Related Records
This flow runs after the record is saved to the database. You can update any record and perform actions, like sending an email, Outbound Messages, and many more. It is the flow counterpart of the field update and “create a record” actions of the other two declarative tools. You can also modularize your flow in an “after-save” flow because Sub-flows can be selected as an action. A sub-flow is simply an auto-launched flow.
Auto-Launched Flow
It launches when invoked by Apex, processes, REST API, and more. It doesn’t need any user interaction to start.
Since they can be invoked by another process, much like Process Builder, it lets you modularize your process by utilizing it as a sub-flow.
Platform Event-Triggered Flow
These are triggered when a Platform Event message is received. This is the equivalent of creating an Apex Trigger for a Platform Event.
What to expect
With Salesforce advocating the “click, not code” approach or the no/low-code solution, Process Builder and Workflows are slowly being retired, with plans of ending feature support soon. But do not fret. The retirement will be completed in phases and will be a gradual process over the years.
Processes will not instantly stop working when Salesforce retires it. However, in around 2023, you will no longer be able to create new Processes.
Let us take a look at the retirement timeline announced by Salesforce during Dreamforce’21:
.png)
As you can see, no immediate action is required as Salesforce is keeping both Process Builder and Workflow for some time. But that does not mean you should wait until Salesforce switches off Workflow Rules and Process Builder! With a proper migration plan in mind, you will, in no time, be able to migrate your Process Builders and Workflow Rules and become “in” into the future.
How do I transition existing Process Builders to Flows?
You can say that Flow is the next big thing; it’s the recommended declarative tool on the platform, announced in Summer 2020. However, this presents a dilemma for organizations that heavily utilize Workflow Rules and Process Builders until this point.
- Some frequently asked questions include:
- What about all the workflow rules and processes integral to our business processes?
- What are the limitations of using Flows?
- What is the plan for Flow?
Whether you’re a business owner or an administrator, the task may seem daunting, but don’t worry! Here are some tips that could help guide you along the way:
#1 Review all your existing Workflow Rules and Processes
It may be beneficial to take time to review your organization’s existing Workflow Rules and Processes rather than migrating them as is. It is like things you have built later in your career, being up-to-date and better than the ones you made earlier. Most of the time, business logic built-in Workflow Rule or Process Builder is built just because it is the best and simplest tool to do the job at that time. Nowadays, it is all about re-usability and enhancing the overall automation performance.
#2 Learn How to Build Flows
This might not come as a surprise, but part of migrating is learning how to use it. There will be a learning curve for many who have come to love workflow and process builder for their simplicity. Building a Flow is like writing an Apex code, except you are not writing anything and memorizing syntaxes – just clicks! Fortunately, Salesforce already has Trailhead to introduce and give a glimpse of their new features. Learn how to do flow by completing Trailhead’s Salesforce Flow module. If you are looking for more challenges, try the Process Automation Super Badge.
#3 Know the Flow Standards and Best Practices
Before building your new Flow strategy, it is essential to know the best practices and standards. Making your Flows without knowing how it should be done correctly will be costly and time-consuming to fix - so better start it right!
Many best practices like this list from Salesforce create cleaner, presentable, and efficient flows. But it would be best if you understood that 3 is the magic number.
- As a rule of thumb, 3 is the strongly recommended number of flows per object because it enables you to do these:
- Before Create or Update
- After Create or Update
- Before Delete
As usual, there are exceptions, however. This will solely depend on how you design according to the business requirements, your organization’s size, or how old your Salesforce org is.
#4 Put on the hat of a Programmatic Developer
Ever wonder what things Programmers learn and consider when writing code in Salesforce?
Jargon
Much like learning another language, Flow introduces new terminologies often unheard of when using Process Builder or Workflow.
- You will come across these commonly used terms as you build your flows:
- Element – Represents an individual tile used to build a Flow. Depending on which Flow you create, different elements are available for used
- Flow Resources – One of the critical pieces of flows, with Element as the other one. A resource can be individual variables or constants that stores data within the elements, or they can be a formula, Screen Components, Choice Options, Decision outcomes, and so on
- Flow Actions – Simplifies the flow-building process by connecting and performing actions on third-party systems without configuring any integration or writing any code
- Flow Interviews – It is an instance of a running Flow. Each time a Flow is started by a user clicking a button, it creates a new Flow Interview. This can also be paused and resumed if enabled.
- Flow Variables – Think of it as a container. It may contain Text, Record, Number, Boolean, etc. Variable values can be changed throughout the flow
- Constants – Similar to Flow Variables with fewer Data Types that it can store. The difference is that the value cannot be changed throughout the flow
- Loop Variables – A variable that can contain multiple values of the same data type. It can be iterated using a Loop element
Limits
Programmers are known for being able to write efficient code that can withstand hundreds or even thousands of records. Why do they even have to? Because there are “limits”.
- The first question that will come to your mind is: “Why are there limitations?”
- Salesforce is built using multi-tenant architecture. You can think of it as one organization renting out a space in Salesforce’s apartment. This apartment runs on shared resources- power, water, internet, and building maintenance. So, Salesforce implemented “Governor Limits” to ensure that no tenant can hog up all the shared resources. Imagine your inconsiderate neighbor downloading huge files from the internet while you are working from home. Frustrating, right? To avoid being shouted at by your neighbors, you will also need to do your part in using your resources wisely and within the usage cap, including “bulkification”.
Now that we got a background about why limits are there, let’s go over the common limits that you may experience with Flows:
Limits per Flow Interview
Versions per Flow: Think of versions as a snapshot of the current state of the Flow. Learning creating flows might have you activating a version to test, and updating it afterward creates a new flow version. Keep in mind that you are only allowed 50 versions per flow. You will have to delete old versions after that.
Executed elements at runtime per-flow: You can only have a maximum of 2,000 elements being executed for each flow interview. To simply explain this, refer to the image below:
Limits per Transaction
Per-transaction limits are enforced by Apex. When a transaction exceeds these limits, the whole transaction is rolled back.
Total number of SOQL Queries issued - 100: You are only allowed a maximum of 100 SOQL Queries. Elements that count as SOQL Query includes Get Record, Update Record, or Delete Record that uses filter conditions.
Total number of records retrieved by SOQL queries – 50,000: You are only allowed to retrieve a maximum of 50,000 records.
Total number of DML statements issued - 150: There is only a maximum of 150 DML Statements you can use. Actions that count as DML Statement include Create Records Update Records and Delete Records.
Total number of records processed as a result of DML statements – 10,000: You are only allowed to modify up to 10,000 records.
Maximum CPU time on the Salesforce servers – 10,000 milliseconds: CPU Time is the amount of time the server takes to complete processing an action. The maximum is 10,000 milliseconds or 10 seconds.
Total number of duplicate updates allowed in one batch: You are allowed to update the same record up to 12 times
#5 Be the critic of your work and learn how to find faults
As you become more comfortable building Flows, you will eventually learn that it’s not always everything that will go as planned. Before you move your flow to another sandbox for testing, it is a rule of thumb to always test all scenarios your Flow covers. How do you test a Flow? Check out this link.
If a scenario failed, is there any way for you to find what part of the flow caused it? Of course! Check out this link. Please also take time to review considerations when debugging a flow.
#6 Check out the Flow Migration Tool
Salesforce rolled out a tool in Spring ’22 to help migrate your Workflow Rules Processes into Flows. Sounds like a nifty tool? It is, especially if you have few Processes and Workflow Rules. But remember that the Flow Migration Tool will convert 1 Process Builder into 1 Flow; it won’t automatically combine your processes for you. This is where Tip#1 comes in handy.
#7 Think of Flows as the first option
Do you have requirements that will fit to be automated? Why not use Flow for it? Not only are you now “in” with the future, but you’re able to be proficient every time you use Flows.
Now, you received a request to update a Process. Why not rebuild it in Flow? We have all been there. “I just want to update this; why should I rebuild it in Flow?” This is also what I thought. I did a favor to my team by migrating our Workflow Rules and Processes into Flows early on. We now only have a few processes left to migrate, with a lot of time to spare! This will also give you a chance to revisit other similar processes and combine them into a Flow.
Are you ready?
We understand that the task may not be an easy one. It will take time but see it as an opportunity to learn and upskill as a Salesforce professional.
