Flow

Flow

What is a Flow in Salesforce?

Flow is an application inside the Salesforce that automates a business process by collecting data and performing operations in your org or an external system. Flow can fetch, delete, update and create records on multiple objects.

Flow Builder is the declarative interface used to build individual flows. Flow Builder can be used to build code-like logic without using a programming language.

Types of Flow:


Screen Flow

Requires user interaction because it includes screens, local actions, steps, choices,or dynamic choices. Screen flows don’t support Pause elements.

Autolaunched Flow with No Flow Trigger

Doesn’t require user interaction. This flow type doesn’t support screens, local actions, choices, or choice sets.

Autolaunched Flow with a Schedule Trigger

Runs only from a schedule. This flow type doesn’t support user interaction, screens,local actions, choices, or choice sets.

Autolaunched Flow with a Record Trigger

Makes before-save updates to the new or changed record that launches the flow. Only these elements are supported: Assignment, Decision, Get Records, and Loop.

User Provisioning Flow

Provisions users for third-party services. For example, use this flow type to customize the user provisioning configuration for a connected app to link Salesforce users with their Google Apps accounts.

Field Service Mobile Flow

Requires user interaction because it has one or more screens.

Field Service Embedded Flow

Requires user interaction because it has one or more screens.

Contact Request Flow

Requires user interaction because it has one or more screens.

Checkout Flow

Used in Lightning B2B Commerce to create a checkout for your store. Requires user interaction because it has one or more screens.

Below is an example of a schedule-triggered flow, pulled from a well-known Salesforce group:

When or Why should flow be used?

We need to know what automation is needed. In most cases, the type of automation is determined by evaluating where the data for the processes originates from and where it needs to go. Consider whether what you need to accomplish is best handled by a flow, workflow field update, or a process.

  • The workflow field update can write data to the same record that invoked the workflow rule, or to the master record of a master-detail relationship on the record that invoked the rule. Workflow rules are not able to create, edit, or delete records.
  • Flows are able to create, edit, and delete any record passed into the flow. Records do not have to be related in order to pass data in a flow. Flows can also be scheduled to run on a set interval with a collection of records.
  • Processes, created in the Process Builder, can write data to the same record that invoked the process, or to records related by either lookup or master-detail relationships. Processes can also create records, but they cannot delete them.

How to create a flow in Salesforce?

To create the flow, follow these steps:

Go to Setup -> Quick Find Box -> Search for “Flows” -> Click on Flows -> Then Click New Flow

It will open below screen.

You can create any of the four flows. Here I am creating Autolaunched Flow which will send an email to the selected users when a lead is created. For that I am creating a flow:

First, I’ll get the record from any of the object using any source of the flow, for that first we need to create a new resource of data type record:

Then you need to go to the elements tab:

Then run the flow:

And the mail will be sent to the Lead Owner.

Flows vs. Apex

  • Apex code requires a developer and Sandbox to deploy, meaning it can only really be built in organizations using a Professional or above edition of Salesforce. Flows can be built in all editions, as a Sandbox is not required for deployment.
  • Apex is not available in Essentials, and some Apex features are limited in Professional. Organizations with Enterprise and above have no Apex limitations, but flow features are not limited based on the edition.
  • Apex code requires constant development and discipline to maintain. Flows require less work to keep up-to-date.
  • Flows can be built by admins, while Apex code is typically built by developers only.
  • Apex code is considered a tool of last resort. Flows are simpler and should be used before Apex code.
  • If the logic is too complex, Apex code should be used. There is unlimited potential with Apex; flow capabilities are catching up, but they are still inferior to Apex.
  • Renewal generation, OLI creation, and other pieces of automation that were traditionally built as Apex code can now be built as flows, preserving code space for projects that require Apex.

Apex code should be used in the following scenarios:

  • You’re dealing with complex Salesforce automation that requires multiple steps and actions where a flow will become cumbersome.
  • You need custom-built integrations with other systems (such as a connection to a SQL database that requires bi-directional syncs).
  • ERP integrations are involved.

Flows vs. Processes

  • Processes are more user-friendly as far setup and management goes. Setting up a flow takes more time and is significantly more complex.
  • Flows allow you to add screens where users can enter data. Processes do not have this capability.
  • Flows can be invoked, started by users, triggered by a record change, or scheduled to run on their own at a custom time and frequency. A process, however, runs automatically (either immediately or scheduled) when criteria is met. It can also be invoked by another process created in the Process Builder.
  • Both flows and process can include scheduled actions.
  • Flows can be paused by users, but processes run when the criteria is met and cannot be paused.
  • Flows and processes both contribute to CPU limits and other automation limits in Salesforce.
  • Process actions are executed in the order in which they appear in the process definition, but flows can have different and more complex orders of operations.
  • Flows can be built to cycle through multiple unrelated and related objects. Processes, however, are limited to the base object (opportunities, for example) and related objects (accounts).
  • The following actions are only available for processes:
  • Quip actions
  • Send survey invitation
  • Invoke a flow
  • Flows can be designed to run either before or after a record has been saved to the database, but processes can only trigger after a record has been saved.
  • Flows can be designed to trigger upon creation, update, or deletion of a record. Processes can trigger only for creation or updates to a record.

Here are a few real-life examples of where a process makes more sense than a flow:

  • You need to automatically submit an opportunity for approval when the value in the Amount field is greater than $200,000.
  • When an account is deactivated, you want to deactivate all the associated contacts.
  • After creating a new user or internal contact, you want to create a case for background verification.
  • You need to invoke custom approval logic that is written in Apex code.

Flows vs. Workflow Rules

  • Flows are available in all Salesforce editions, including Essentials. Workflow rules (WFRs) are not available in Essentials or Professional editions.
  • WFRs are not actively being updated by Salesforce (but you can still use them for the time being). Flows are constantly being updated with new features and capabilities in each Salesforce release.
  • There are limitations with how many WFRs can be active at once, but they typically do not contribute to CPU limits unless the WFR triggers a process or flow through one of its updates (such as a field update).
  • Both flows and WFRs can have scheduled actions, but WFRs are limited to 1000 triggers per hour.
  • WFRs can only make one decision, but you can call other flows and Apex code with a flow.
  • WFRs are limited to just a few actions: creating a task record, sending an email, updating a field, or sending an outbound message. Flows can do all of these actions and many more.

This is a use case where a WFR makes more sense than a Flow.

  • You want simple field updates, such as outbound emails or sending email alerts when high priority cases are created.

How to launch a Salesforce Screen Flow from a button?

First, go to Setup > Object Manager and locate the object you want to add the button to. That’s the Opportunity object in our case. On the left side of the screen, select “Buttons, Links and Actions” and then click “New Action”.

The New Action screen looks like this:

Change the Action Type [1] picklist to Flow. The next field will change to a picklist of available Screen Flows [2]. If you don’t see your Flow in this list, go back and check that a) it’s a Screen Flow, not an Autolaunched Flow and b) that you set it to active in the Flow Builder.

Select your Flow.

Enter a Label and Name, then click Save. Note that the label is what the text the button will show in the UI so keep it fairly short.

Go to Page Layouts in the left nav and click into the page layout you’re using for this record type:

In the layout controls, select “Mobile & Lightning Actions”. You should see your new action listed there. Drag it into the “Salesforce Mobile and Lightning Experience Actions” section. (If your “Salesforce Mobile and Lightning Experience Actions” section doesn’t look like the above, you may need to click the little wrench icon to allow you to modify it.) Click Save.

Click it!