Introduction to Flow in Salesforce

Replacing Process Builder With a Flow in Lightning Experience

Salesforce Flow offers users to automate business requirements by creating Flows, which collect, update, edit, and create Salesforce data, and make those flows available to the appropriate users or systems.

The declarative interface for creating individual flows is called Flow Builder. Without using a programming language, Flow Builder can be used to create code-like logic.

Flows can run logic, connect with the Salesforce database, invoke Apex classes, and walk users through data collection and update pages.

Flow is made up of three blocks

1. Elements that show up on the canvas.
2. Connectors define the flow’s path during execution. They instruct the flow as to which element should be executed next.
3. Resources, such as field values or formulas, are containers that represent a particular value.

When to use Flows?

In most cases, determining the type of automation to utilize for a certain process begins with determining where the data for the process comes from and where it needs to go. Consider whether a flow, workflow field update, or process is the best way to accomplish your goals.

Flows can create, update, and destroy any record that is supplied to them. To pass data in a flow, records do not need to be connected. Flows comprising a group of records can also be scheduled to run at a specific interval.

The workflow field update can write data to the same record as the workflow rule, or to the master record in a master-detail relationship on the same record. Workflow rules can’t make changes to records or delete them.

Processes established in the Process Builder can write data to the same record that triggered the process, as well as to records linked via lookup or master-detail connections. Records can be created by processes, but they cannot be deleted. In addition, processes are unable to query records that are unrelated to the initiating record.

But, it is important to know when we should not use something even if we don’t know when to use it. That is applicable for Flows as well.

There’s a lot of logic here that’s easier to manage using Apex code. The flow shown in the Overview section is an example of this. The logic in this flow is so convoluted that debugging it is a hassle, and documenting and managing it is challenging as well.

The number of flows you can build is limited by your Salesforce edition. Each organization can only have five processes (per process type) and flows (per-flow type) in the Essentials and Professional editions. It is easy to use a process for most logic in these editions.

Let’s see some differences and similarities between Flow and Process.

In terms of setup and management, the processes are more user-friendly. You can utilize flows to create screens where users can enter data. This is not something that processes can do.

Flows can be triggered by a record update, launched by users, or scheduled to run at a specific time and frequency. When requirements are met, a process, on the other hand, runs automatically (either immediately or later). It can also be called another Process Builder-created process. Scheduled actions can be included in both flows and processes.

Users can pause flows, but processes run as soon as the conditions are met and cannot be stopped. In Salesforce, both flows and processes contribute to CPU and other automation restrictions. Process actions are carried out in the order they appear in the process definition, but flows might have alternative and more complex operation sequences.

Flows can be created to cycle across several objects, both unrelated and connected. Processes, on the other hand, are limited to the base item (for example, opportunities) and linked objects (accounts).
Processes can only be triggered after a record has been saved to the database. Flows can execute before or after a record has been saved to the database.
Flows can be set up to run when a record is created, updated, or deleted. Processes can only be triggered when a record is created or updated.
On the flow canvas, you may test and debug flows, including in a rollback mode, which allows you to test your automation without changing your data.

Let’s discuss Workflow Rules (WFR) and Flows

All Salesforce editions, including Essentials, include flow capabilities. In the Essentials and Professional editions, workflow rules (WFRs) are not available. Salesforce does not update WFRs on a regular basis (but you can still use them for the time being). With each Salesforce release, Flows are updated with new features and capabilities.

The number of WFRs that can be active at the same time is limited, however, they rarely contribute to CPU constraints until the WFR activates a process or flow through one of its updates (such as a field update).

Scheduled actions are possible in both flows and WFRs, however, WFRs are limited to 1000 triggers per hour. Although WFRs can only make one decision, flows can call other flows and Apex code.

WFRs can only do a few things: create a task record, send an email, update a field, or send an outbound message. Flows can perform all of these tasks, as well as many others.

Let’s implement a Flow for a simple requirement. We’ve already discussed displaying Phone and Email in Task Record Page using Process Builder.

To recall or to refer, Phone and Email on Tasks or Events in Lightning Experience.

Let’s replace the Process Builder with a Flow.

• Go to setup and search “Flow” in the quick search area
• Go to Flows and click New Flow.

Flow

• You’ll be taken to this screen

Flows fall into five categories:

1. Screen Flows: These are flows with a user interface element that demands user input. These types of flows can be initiated as an action or integrated as a Lightning page element.
2. Schedule-Triggered Flows: These background-running autolaunched flows execute at a predetermined time and frequency for each record in a batch.
3. Autolaunched Flows: Use this flow type to do automated actions. Process builder, Apex classes, a specified timetable, record updates, and platform events can all be used to launch autolaunched flows.
4. Record-Triggered Flows: When a record is created, changed, or removed, these autolaunched flows execute in the background.
5. Platform Event-Triggered Flows: These autolaunched flows run in the background when a platform event message is received.

Select Record-Triggered Flow and click Create.

• Select the object

Since we have to populate data to Task, Let’s select Task for this Object. And it should get triggered when a new record is inserted or updated.

And select the rest of the things mentioned. And click Done.

• You’ll get a screen like this.

• Create a new resource

• Add an element (Decision) to check which operation is happening (insert or update)

Select If the condition requirements are met for When to Execute Outcome. Rename the default as Before Update.

• Add another decision

• Set the criteria as this

• Add an Assignment now

• Set the things as this

• Give the end here

• Now do the same for the Update case as well

• In the end, the flow will be like this

• Save the flow and activate it

• Now it is activated

• Now, go and create a new task

The fields Email and Phone are getting populated with the values.

How to test a Flow?

Click the Debug button on the canvas to test a flow, then enter your variables and click Run. Then test the flow to ensure it is working properly. This method is extremely useful when working with screen flows.

A beta functionality called Debug on Canvas is available as of the Winter 2021 Salesforce release. This feature simplifies flow debugging by displaying the path your flow will take when it runs. The debug information also shows the flow’s query restrictions. Furthermore, debugging now includes two additional options: Run flow as another user and Run flow in rollback mode.

Hope this article can help. Share your thoughts too.