Your web browser is out of date. Update your browser for more security, speed and the best experience on this site.

Update your browser
CapTech Home Page

Blog April 26, 2019

Nine Tips for Using Salesforce's Lightning Flow the Right Way

Adam White

Lightning Flow is the new hot thing in the Salesforce world with the newly redesign and Flash-less Flow builder. This blog post assumes you have a good understanding of Flow. For those that are just getting started, Flow sits somewhere between Apex and Process Builder in terms of Power and Complexity in the Salesforce automation tool chest:

Don't be discouraged or disheartened! There are TONS of ways to learn Flow, including Trailhead. However, there are some things that no amount of Trailheads or practice will teach you, and that’s where this blog post comes in.

If you want to learn more about the pro’s and con’s of each of the four automation tools, David Liu over at sfdc99.com has a fantastic blog post covering it: http://www.sfdc99.com/2018/01/22/workFlow-process-builder-Flow-apex/

The Salesforce Admin Portal also recently published a series of tutorials on the new Flow builder which is also a great way to learn about its capabilities: https://admin.salesforce.com/getting-started-with-the-new-Flow-builder

Keep in mind – Flow can currently only be launched via:

  • Process Builder
  • An Apex Trigger
  • A Button on a page layout
  • Embedded in a Lightning Community/ Lightning Component
  • Embedded in a Lightning record page

Without further adieu, here are are my top tips for using/learning Lightning Flow.

Tip #1: Document, describe, detail

In the programming world as long as code is commented and formatted correctly, even if your code is poor, you still get a pat on the back. Leaving breadcrumbs or comments in your code for the next person to inherit your work is critical. The same applies for configuration-based solutions.

  • Flow Descriptions: Be sure to include what your Flow does, the objects your Flow touches, and where it is invoked from (such as what page layout to use if it’s a screen Flow, which process builder process to use if it’s an auto-launched Flow).
  • Variable and element naming conventions: Much like programming, it’s good to stick to naming conventions when creating variables and elements in Flow. Include in the variable description what it is you are capturing. A little bit of work up front will go a long way for future ‘you’ or somebody else that inherits the Flow. There’s no right or wrong way to do this, just keep it consistent within the Flow.
    • Examples: vCustomerInputDate, sObj_Case, formula_TODAY, sObjCollection_CollectedCases
  • Step descriptions: Write a short blurb in each step and talk through what your goal is and why you’re doing it – it will help you remember when you pick it back up months later or for the next person to adjust it.

Tip #2: Screen Flow = User Context, Auto-launched Flow = System Context

Always remember when designing a screen Flow that the Flow will operate using the permissions of the user running it. If you’re updating a field or looking up a record up in your Flow, ensure that your target audience has access to do everything the Flow can do, otherwise you’ll get errors. If you want to do a screen-based Flow that bypasses user permissions, think about teaming up with a developer to do some embedded Lightning components or Apex actions within the Flow... or wait patiently until Salesforce adds this feature.

Conversely, if you’re creating an auto-launched Flow from Process Builder (with no screens), permissions will not be an issue as it will run under the ‘system’ context, which is essentially full access.

Tip #3: Use the debugger instead of saving multiple versions

Salesforce recently released the Flow debugging tool to help avoid needlessly saving version upon version to ‘test’ your Flow. Don’t be intimidated by it, as it’s easy to use. Simply save your Flow and press the Debug button – you will be able to enter in values for almost any variable. There are some limitations, however:

  • Testing the Flow runs the Flow as well as any DML operations in it – so even though you are testing it to see if it works, it still runs it.
  • You can't set values into input variables of collections, sObjects, and sObject collections.
  • You can’t set the ‘running user’ of the Flow, so if you use formula variables based on that, you’ll probably need to activate the Flow and test it by logging in as another user

Tip #4: Always have a fault path after a Lookup, Update, Create, or Delete element

One of the most common mistakes an up and coming Flowmaster makes is not building in Fault paths – even, I still do it on occasion. A fault path is designed to handle when a Flow encounters an error and you then tell it what it should do. The two most common uses are showing an error screen for screen-based Flows or sending an email alert containing the error message to a group of people.

To create a fault path, connect your element to the ‘next’ element in line, then drag another line from the same element to your fault action. It should look something like this:

Read up on Salesforce’s documentation on faults here (including how to make one): https://developer.salesforce.com/docs/atlas.en-us.salesforce_vpm_guide.meta/salesforce_vpm_guide/vpm_designer_elements_connector_fault.htm

Tip #5: Always have a decision after a Lookup/Get element to check for no results

When performing a ‘Get’ or ‘Lookup’ in a Flow, be sure you look for the checkbox that says ‘Assign null values to the variable(s) if no records are found’. There will be plenty of scenarios where your lookup doesn’t find a record, so you want to plan for that in your Flow.

Directly after the Lookup, add a decision check for Null in the variable you assign in the ‘Get’ step. See below for an example of the Lookup and the Decision/null check. If you're a coder, imagine this is your 'null' check.

Lookup/Get Record screenshot:

Lookup

Decision screenshot:

Decision screenshot

Tip #6: Utilize subFlows & custom labels to save time

Did you know that you can call a Flow from another Flow? This helps with keeping the clutter down in your Flow if it starts to get out of hand. Another use case is re-using other Flows and calling them from within your Flow. All you need to do is drag in a Subflow from the action Panel:

Tip 6

After you drag the action into your Flow, you can map the variables you want to pass into the child or subflow. You typically pass in the record ID of the record that triggered the Flow, but it depends on what you’re trying to do. I like to use a ‘Send Error Email’ subflow where you pass in the Fault Message and other tidbits from the 'parent' Flow, that way you can control how your error email behaves across Flows and you only need to change it in one place.

Speaking of re-using data across Flows, as a rule of thumb, you want to store information you might reference in multiple Process Builders, Flows, or Formula Fields in a custom setting, custom metadata type, or a custom label.

Jennifer Lee wrote a fantastic article about this on her blog: https://jenwlee.wordpress.com/2016/02/02/using-custom-metadata-type-in-visual-workFlow-fault-emails/

Rather than reinvent the wheel, I suggest you check out her article. It focuses more on custom metadata types, but you can also reference global custom labels. In the past, I have used custom labels to reference record type IDs, queue IDs, specific users, and more. Which brings me to my next tip…

Tip #7: Don’t hardcode IDs

One of the downsides of Flow is that it doesn’t let you reference the Developer Name of things like Record Type, Queues, or Public Groups like in Process Builder. That doesn’t mean you should be hard coding the ID in the Flow though.

Instead, do a lookup to get the ID and store the ID in a variable. This will save you headaches when deploying through your environments since Record Type IDs and other unique identifiers might differ between environments.

As an example, create a ‘Get Records’ lookup step on the ‘Record Type’ object, then in your conditions provide the ‘DeveloperName’ field and store the found record ID (the record type ID) in a separate variable.

Tip #8: Don’t put DML (Lookup, Delete, Create, Update) inside of a loop

One of the cardinal sins of Apex development is putting a DML operation inside of a loop – the same applies for Flow. This is due to Salesforce-imposed ‘governor’ limits on how many database operations you can do in a single transaction.

Instead, create an sObject collection variable and assignment step, then create them all at once at the end. There are lots of tutorials out there on how to do this. Here’s an example that Salesforce provides, which I found to be pretty helpful: https://developer.salesforce.com/docs/atlas.en-us.salesforce_vpm_guide.meta/salesforce_vpm_guide/vpm_designer_example_loop.htm.

This tends to be one of the harder concepts for people to grasp - so don't fret if you struggle at first. Stick with it - it will click eventually. Keep practicing.

There are times where it might be okay to do a DML inside of a loop in cases where you’re 100% certain the scope will be limited and you’re positive governor limits won’t be an issue – but be careful. Screen Flows with limited selections tend to be where this comes into play, but I would caution against it in auto-launched Flows.

Tip #9: Stay ahead of the game

Looking to stay ahead in the Flow world? Here are my favorite Flow-focused sites/blogs and other resources:

I hope you found this information helpful. Flow is one of the best things an admin can learn to level up their skill set and really get a deeper knowledge of the inner-workings of Salesforce. While it has its limitations, Salesforce continues to put resources behind Lightning Flow to make it even better each release.

Related Content