In 2020, following the release of before-save and after-save flow triggers, Salesforce announced that they will not be making any further investments in Process Builders or Workflow rules. While these types of automation will still be supported for the time being, this announcement ultimately signalled a full transition to Flows.
With an increased reliance on Flows, it’s time for admins to get familiar with what Flows can do: and, most importantly, how to avoid common errors that Flows can cause if not configured properly.
Replacing Cloud Flow Designer in the Spring 19’ release, the Flow Builder provides admins with a powerful and flexible tool in a low-code environment to improve automation. Built using the Flow Builder, Flows have the ability to use code-like logic without using Apex. This allows admins to do the following actions, and more, totally code-free:
As we’ve said before, with the great power given to admins in this environment comes great responsibility. Therefore, admins building Flows can benefit from learning how to think more like developers in order to safeguard against a wider range of possible errors.
When building out Flows, admins will work under the same Governor Limits that coders do. That’s why admins need to be aware of each limit to avoid crashes in the process. The limits outlined below apply to one transaction at a time.
There are 6 Governor Limits to be aware of:
If any of the Governor Limits are exceeded, Salesforce will deem that your org is taking up too much of its resources. As a result, you’ll receive a transaction error, meaning your process has crashed.
In order not to exceed these limits, you’ll need to ensure that 1) there’s only one Flow per object 2) you’re not querying elements in a loop, 3) you’re not updating elements in a loop, and 4) you’ve consolidated updates into a single action.
With Process Builders, there is no way to run test processes. Instead, you have to trigger the entire process and wait for the end result to see if it was successful.
That’s not the case for Flows. Using the debugging tool that’s available to Flows, it’s possible to test the paths of a Flow without actually triggering an action. This will save you tons of time and energy as you won’t have to save multiple versions of your Flow to “test” them, not to mention that there are no consequences if the test runs into an error in the Flow.
The debugger is simple to use: all you need to do is save your Flow and press “Debug.” With this tool, you can pass in any parameters such as record ID to simulate triggering the action, allowing you to see the paths that it took within your Flow.
Another great benefit of Flows is that you’re able to call on different Flows, allowing you to make the processes modular and easier to manage. This means that you can select specific Subflows to update without needing to worry about the main Flow.
Take advantage of Subflows by creating a master Flow that will call on smaller Subflows, depending on the actions you need. You can also reuse Flows to avoid spending time building out the same action multiple times.
Once you have called on Subflows, the Flow Builder will allow you to map out the specific variables you want to be passed from the master Flow into the Subflow. Organizing your processes with Subflows will eliminate any future headaches that come with updating and maintaining large processes.
In some cases, your lookup in a Flow won’t be able to find a record. Coders in Apex handle these situations using “Null” checks.
In the Flow Builder, you can assign null values to missing records to keep the Flow running. To do this, click the “Assign null values to the variable(s) if no records are found” checkbox when performing “Get” or “Lookup” in your Flow and add a decision check for Null in the variable you assign.
If you don’t instruct your Flow to assign a null value in an empty variable, your Flow will crash.
Flows are constantly being updated. Here are just a few of the notable new Flow features from the latest release (Spring ‘21):