Flow: How To Use Different Type of Flows

Flow is one of the fastest growing Salesforce products. A while ago it started with Screen Flow and Autolauched Flow and now there are five options. It involves from something reliant on Process Builder to a tool that can be used independently which even has the functionality that Process Builder does not have. According to Salesforce they have no plans to replace Process Builder with Flow, but in my opinion it does look like the long-term goal, which is also why it is very important to familiarize yourself with this product. Let’s dive into the different flow types so you know how each of them helps increase the productivity of your instance.

Summary

Flow type	Launch Independently*	Specialty	use case example
Screen Flow		Can interact with users and show them an interface	– Walkthrough of creating a contract – Registration form – Quick Start of setting up accounts
Autolaunched Flow		Runs only in the backend and can be referenced by many different places	– Used as subflow
Record-Triggered Flow		Replace Workflow and Process Builder with more flexible setups	– Update account when case is closed
Schedule-Triggered Flow		Runs scheduled, batched actions at a given interval	– Delete obsolete data periodically – Send out monthly emails
Platform Event-Triggered Flow		Execute follow-up actions when a platform event occurs	– Notify admins when receiving platform event

1. Screen Flow – My Love!

This is my favorite flow type as you can create so many possibilities with Screen Flow. You can guide your users through a complicated process, ask for input from them, or simply post messages or notes. Think about the auto-bots that you often see on different websites, and that is what you can achieve with Screen Flows. The magic is really at the Screen component. Once you are familiar with that, you can make a lot of fun solutions. The walkthrough of the Screen component can be found in this article.

However, note that Screen Flow is one of the two types that rely on another interface to launch the flow. This means, after you finish the flow, you need to either create an action, a button, put the flow inside a Process, or put it on the Lightning Page. Check here to see how to launch flows in different ways.

2. Autolaunched Flow – The Foundation of Other Flow Types

This type should be very straight forward. You simply ask the system to do things without any interaction with users. Except from the system logs, no one would know what have been triggered and done. However this is really the foundation of other flow types that we are going to introduce.

At the early stage of Flow, you have Screen and Autolaunched type, both of which are reliant on other interface to fire the flows. For example, if you want to show a screen for users to enter their name after an account is created, you will first create a Screen flow, then create a process in Process Builder which trigger this flow whenever an account is created. This is time-consuming, but kind of make sense because Process Builder simply cannot interact with your users.

But does it still make sense for an autolaunched flow? Assume you want to change the account rating to Hot whenever the account’s annual revenue reaches 1 billion. With Flow, you would first create an autolaunched flow to change account rating, and put this flow into a process which should be triggered when annual revenue is changed. Do you see the problem here? Why do we have to create one flow and one process, while everything can be done in just one process?

So then the Record-Triggered and Scheduled-Triggered flows were born. They enables you to fire the flows without having to refer them from a process.

Then you might ask – do we still need the autolaunched flow? The answer: Depends!
Sometimes you might have the same set of actions that should be run on record changes of different objects. Then you can create an autolaunched flow and use it as Subflow. So yes, it still has its own value.

3. Record-Triggered Flow – An More Flexible Type To Replace PB

This is the most complicated type in my opinion, just because the flexibility! It is so flexible that you have 11 different combinations of scenario! Let’s go through them section by section.

1. Flow Trigger Time (4 Options)

Similar to Workflow and Process Builder, you can define whether the flow should be triggered upon creating or updating. However while Workflow and Process Builder bundle the updating with creating (Option 3 in the graph), you can separate that in flow.

Furthermore, you can also trigger a flow to run when a record is deleted, which is not achievable in other automation tools but APEX.

2. Action Execute Time (2 Options)

While the first setting means when the flow should start, this setting means at what time should all the actions be executed. Salesforce provides two times – before or after the record is saved, and the difference is on the performance and the technical restriction.

Not to dive too deep into the developer’s world, let’s simplify the explanation.
For before trigger, the system uses less time to handle the actions, so the flow can be run faster. However you can only update the same record that triggers this flow.

For after trigger, the flow runs slower, but you have more options of actions.

If you want to know what can/cannot be done for each trigger, check out this Salesforce Help article.

3. Action Execute Criteria (2 Options)

If you are familiar with Workflow and Process Builder, you must think the first setting seems strange, like something is missing. You are correct! We are missing the “any time it’s edited to subsequently meet criteria” as in Workflow, and that is represented by “When to Run the Flow for Updated Records” under the “Choose Object” section. Here is the comparison of this setting with other tools.

Workflow	Process builder	Flow	Explanation
Evaluation Criteria: Created, and every time it’s edited	Under each node > Advanced > Do you want to execute the actions only when specified changes are made to the record?: Unchecked	Every time a record is updated and meets the condition requirements	As long as the criteria is met, the automation will be triggered every time the record is edited
Evaluation Criteria: Created, and any time it’s edited to subsequently meet criteria	Do you want to execute the actions only when specified changes are made to the record?: Checked	Only if the record that triggered the flow to run is updated to meet the condition requirements	The automation will only be triggered at the first time the criteria is met

4. Why Continue Using Workflow and Process Builder?

Very good question! Even though Flow can pretty much do everything that Workflow and Process Builder can, there are still some benefits of using the latter. Check out this article to find out.

5. Why 11 Scenarios?

We have 3 settings with 4 options, 2 options, 2 options respectively, so some might think there should be 16 combinations. However, not all settings are as flexible as others. For example, if you choose to trigger the flow when a record is deleted, you can only choose the before trigger. Here is the table of all possible scenarios.

Setting 1 – trigger time	Setting 2 – execute time	setting 3 – execute criteria	sum
Record is created	1) Before save; 2) After save	Not Applicable	2
Record is updated	1) Before save; 2) After save	1) Every time edited; 2) First time criteria met	4
Record is created or updated	1) Before save; 2) After save	1) Every time edited; 2) First time criteria met	4
Record is deleted	1) Before delete	Not Applicable	1
Grand Total			11

4. Schedule-Triggered Flow – Something Only Flow Has!

This one is really cool! You can set your flows to run at a specified interval and a given time, so you can schedule periodic actions that will be automatically executed. (Ex. clean up outdated data, send monthly emails, etc).

The main difference is the option of “Set Schedule”. When click on this option, you can set the start date, start time, and the frequency. Should be easy to set this up, so give it a try if there are currently some routines that are still taken care of manually in your instance!

5. Platform Event-Triggered Flow

Platform Event is something that developers will track a lot, but not necessarily administrators. To simplify, platform events are messages that different systems send to each other or send within themselves. I have never used this type of flow as admin, and probably never will, so check out the developer’s guide if you want to learn more.

Official Salesforce Help Article On Flow Types