Go with the Flow. But Plan First!

Flows are a hot topic right now with them quickly becoming the way of the future. With constant new (and awesome) updates coming with every release it’s important that you appropriately plan your implementation. Below I’ve included some basic steps for you to follow to help better plan and implement your flows (and other solutions).

Understand the Requirement

As with implementing anything on Salesforce you first need to understand the ask.

• What is the problem that trying to be solved?
• Why does the problem exist?
• Who are the impacted business users?

Write your solution

Key questions to ask:

• Is Flow the appropriate solution? Is it better that it’s built with a Lightning Web Component or in Apex? I love Flows, but I also acknowledge that they are not always the best solution. By understanding the requirement you can better solve by keeping yourself open (where possible) to other solutions.
• How is the solution scalable? What would change if instead of 5 records being created it was 500?
• What type of Flow is the right one? Am I updating related records? Do I need Users to input?

It’s important to take the time to answer the above not only when planning your Flows but anything that you’re looking to build on the platform. As the famous saying goes “Prior preparation prevents poor performance”.

Mapping

Now we map out the flow on whatever you feel comfortable with such as a whiteboard, piece of paper, LucidChart, or any other tool that works well for you. The aim here is to help you map your process before opening Flow Builder and dealing with creating Elements and components that you don’t really need. It doesn’t need to be pretty, it is helping you think further about your solution to work through those little kinks and is how I apply the “rubber duck debugging” method. Here’s a link to the Wikipedia article on the concept.

You want to ensure that you map out:

• Elements
• Component
• Variables

The aim for it is not to be perfect, it is there to help visualise your solution. Next, we move on to the fun part.

Create your Flow

With your Mapping in hand now you go ahead and create your Flow. Remember: Use the description fields and use easy-to-understand names for your Elements and Variables. If you get hit by a bus tomorrow no one is going to know why a Variable is called 1stAcctVar unless you’ve put in what it’s used for. Let’s build it how we want to find it.

Throughout this process, it’s also important that you iteratively test. Go through these simple steps:

1.??????Build one process

2.??????Test

3.??????Tweak

4.??????Test

You can have up to 50 versions of a Flow (and you can delete old versions to keep it under the same name) before needing to create a new copy of the Flow. Use them, don’t aim to build the perfect Flow in version one as it’s harder to remember what you changed when a test goes wrong.

Test. Test. Test.

For Record Triggered Flows the Test functionality now generally available should be used for all your paths and scenarios. Make sure to write them the way in which your users would and in their personas. I’ve been caught out in the past by testing as Admin and forgetting about Field Level Security and permissions. Don’t be me!

For Screen Flows make sure you Debug all paths making sure to run as the appropriate Users. Be sure to also check the Debug Details to confirm variables and values are calculating as you expect.

And that’s it! A 5-step process that helps you go through the process of building not only Flows but any functionality that you’re introducing.

I’d be interested to hear how you approach your Flow building.