There’s no doubt that Salesforce Flow can be intimidating, especially as you move beyond the basics. Therefore, I want to share my thoughts on moving seamlessly from simple, to more complicated flows.
While teaching Flow over the past few years, I have seen that new users can understand and implement some flow concepts far easier than others. Let’s take a look!
If you have never used flows before, there is a good chance that you have unrealistic expectations about your learning journey. Let’s bust some common misconceptions:
- Flow is not just an enhancement of Workflow or Process Builder. While Workflow and Process Builder are primitive versions of record-triggered flows, Flow Builder can do much more than record-triggered automation.
- While you might have many complex business processes that you would love to tackle by building declaratively, this is not where you should begin your ‘flow journey’. Instead, build up your skills and confidence by tackling low-code automation functionality one step at a time. If you are a new Flow user, the best advice I can offer is to start simple!
When new learners want to tackle that one complex flow that loops the related records and the related records of the related records, and processes complex business logic, they are setting themselves up for frustration!
Once you have a few simple flows under your belt, you’ll be ready to face the next stage in your flow builder journey.
Tackling Advanced Flows: What You Need to Know
There are a few fundamental knowledge areas that are essential for success when using intermediate and advanced level flows.
You don’t have to wait until you learn all these topics to get started with the Flow Builder. However, if you do not understand these topics well, you will most likely stumble as you build your more complex flows.
“Process” describes what organizations do daily to get things done. It is a chain of events that produces the desired business outcome.
The fundamental process work is not about technology; it is about extracting and documenting the correct process steps to be measured and repeated to help the organization reach its targets.
If you don’t have any experience in this area, I highly recommend developing your process skills by learning process mapping.
2. Standard Objects and Field Types
Here are the essential Standard Objects:
You need to learn these five like the back of your hand. You also need to know which required fields are on these objects. You don’t have to memorize these; a good understanding of the concept will be sufficient.
Start by asking yourself the following essential questions:
- What are the standard field types?
- How are checkbox, picklist, text, and number fields used?
- How can I pass one value from one field to another?
- Do I need to convert values and formats?
- Do I need a formula resource?
You can find the answers to all of these questions with a solid fundamental knowledge of field types.
3. Relationship Types
Time for more questions:
- What are the available relationship types in Salesforce?
- How are the standard and custom objects I will use related to each other?
- How do I get from one object to the other and grab the field values I need to process?
- Do I need to build everything in my flow, or can I leverage roll-up summary or formula fields?
Before tackling process automation involving many related objects, I always go to the schema builder to view all the objects and their relationships. Have you used the schema builder? I recommend giving it a go – it will be very beneficial for you.
4. Variables and Collections
If you build record-triggered flows only, you may get by without knowing variables very well. Therefore, I teach variables after I teach record-triggered flows.
When you start building other types of flows or tackle loops inside any flow type (including record-triggered), you’ll need to learn variables and collections very well.
Variables are your temporary containers for values that you will use in your flow. There are many different types of variables, and they hold specific types of values for you. On the other hand, record variables hold all field values for a certain type of record.
However, there will be cases where you’ll want to hold multiple values in a container. These containers are called “collections”. Collections hold a number of values for you to process in your flow. Collection actions and elements are limited in flows. Therefore, you often need to loop through these variables to process each member one by one.
Loops are essential when you want to process multiple related records. There are limited operations you can perform on multiple records in flow. In most cases, you need to loop through the records to process them.
Flows have limits, and these limits are often associated with the number of elements used and the number of elements of a particular type executed.
When you use a loop or loops in your flow, the elements inside the loop will be executed every iteration of the loop, and the number of iterations is often not known at the time of build.
In addition, if you make a mistake – if something goes wrong in the loop – you will make a mess of every iteration your loop runs. You will have a more significant clean-up to deal with afterwards!
Therefore, you need to be very careful with designing loops containing loops.
6. Fault Handling
Flow fault handling is an interesting concept. You can build fault paths coming out of elements in Flow, allowing you to take a different route when this happens, but the flow will still generate an error email. So, in a way, going down the fault path is like avoiding an accident, but still coming away with a scratch. In other words, while you should build fault paths, it’s preferable to avoid using them.
Use “decision” elements to predict and handle all possible outcomes. For example, check whether your “get” elements found any records by doing a “null” check using a decision.
7. Testing and Debugging
For safety, you should be doing your development in a sandbox or a dev org. But how do you ensure that your flow is ready for deployment?
Your flow may have decisions and paths that depend on various criteria. Therefore, you should aim to test all paths in your flow by creating and using test data that facilitates it.
Do you initial testing in “debug mode”. Debug mode will allow you to use the roll-back option for most flow types. You can debug without making changes to the data in your org. Follow your debug log step by step on the right panel of your canvas. Pay attention to record IDs and field values that are important for your process automation. Read the error message carefully. Check what path your flow took and where and how it stopped when the fault happened.
Once you eliminate all faults, activate your flow and run it on several test records. If you see an error, check the fault email that is produced. Check the error message on top, but also make sure you scroll all the way down to see the point of error. The bottom of the email sometimes includes more detail about the error. And it will show you exactly which element was executed before the error, which is also important.
Having read this blog post, you probably have more questions than answers. This is good! You should leverage the many resources available online to learn about Flow concepts.