Mapping of Flows in Salesforce

What is Salesforce Flow?

Flow is a powerful business automation tool that can manipulate data in Salesforce in a variety of ways. Such application can be created right from the org’s setup with just drag-drop/point-click. The ease of creating flows makes it the number one go-to tool when it comes to complex business requirements. It is not only easy to create, but also it does not require any coding. Beware! That does not mean you don’t need to know the Salesforce platform’s object relationships and overall how Salesforce runs. You have got to have (at least) mid-level understanding of SFDC and its features in order properly use flows.
First, we are going to show how a flow is created and how it flows (it is a flow after all, isn’t it?). Flows can be created from Setup, enter Flows in the Quick Find box, then select Flows, and then click New Flow. 

When should I use Flows vs Process Builder?

Flows and Process Builders are similar. Here are some of the key differences and similarities between the two:

• Process Builder is more user-friendly in terms of its setup and management. Setting up a flow takes more time and significantly more complex.
• Flows allow you to add screens where users can enter data
  • Process Builders do not have this capability.
• Flows can be Auto-Launched or started by users.
  • Process Builders run automatically (either immediately or scheduled) when criteria is met.
• Flows and Process Builders can have scheduled actions.
• Flows can be paused by users, Process Builders run when the criteria is met and cannot be paused.
• Flows and Process Builders both contribute to CPU limits and other automation limits in Salesforce.
• Process Builder actions are executed in the order in which they appear in the process definition.
  • Flows can have different and more complex orders of operations.
• Flows can be built to cycle through multiple un-related and related objects.
  • Process Builders are limited to the base object (i.e Opportunities) and related objects (Accounts).
• The following actions are available in Process Builders only:
  • Quip Actions
  • Send Survey Invitation
  • Invoke a flow

Here are real-life examples where a Process Builder makes more sense:

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

How do I create a Flow in Salesforce?

Below are the steps to create flow:

1. Open Flow Builder: From Setup, enter "Flows" in the Quick Find box, select Flows, and then click New Flow.
2. Select the flow type, and click Create.
3. Drag the elements you want to use onto the canvas. Each element represents an action that the flow can execute. Examples of such actions include reading or writing Salesforce data, displaying information and collecting data from flow users, executing business logic, or manipulating data.
4. Connect the elements to determine the order in which they’re executed at run time. Don’t forget to connect the Start element to another element.
5. Save your flow.

After you build a flow, make sure that it’s working as you expect it to by testing it thoroughly to make sure that it works as expected. Then activate the flow. You’re now ready to distribute the flow to users.

Pro tip: Flows can be executed in several ways, depending on who the flow is designed for. Internal users, external users, or systems can run a flow, or a flow can be deployed for another organization.

When/why do I use a Flow?

In most cases, the type of automation to use for a specific process can be determined by evaluating where the data for the processes originates from and where it needs to go.

• Flows are able to create, edit, and delete any record passed into the flow. Records do not have to be related to pass data in a flow. Flows are also able to be scheduled to run on a set interval with a collection of records.
• Workflow field update can write data to the same record that invoked the workflow rule or 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.
• Process builder can be used to write data to the same record that invoked the process or records related by either lookup or master-detail relationships. Processes can also create records but not delete.

Flows vs Apex

Flows and Process Builders are similar. Here are some of the key differences and similarities between the two:

• Apex requires a dev and Sandbox to deploy, meaning it can only really be built in organizations that are Professional and above. Flows can be built in all editions, as a sandbox is not required for deployment.
• Apex is not available in Essentials, some Apex features are limited in Professional. Orgs with Enterprise and above have no Apex limitations. Flows features are not limited based on the edition.
• Apex requires constant development and discipline with upkeep. Flows are less work to keep up to date.
• Flows can be built by admins, Apex is typically built by devs only.
• Apex is considered a tool of last resort, Flows are simpler and should be used before Apex.
• However, to the point above as to when you should not use a flow, if the logic is too complex, Apex should be used. There is unlimited potential with Apex, Flow capabilities are catching up but are still behind Apex.
• Renewal Generation, OLI creation and other pieces of automation that were traditionally built as Apex can now be built as flows, preserving code space for projects that require Apex.

Apex should be used in the following scenarios;

• Complex Salesforce automation that requires multiple steps and actions, where a flow will become cumbersome.
• Custom-built integrations with other systems (such as a connection to a SQL database that requires bi-directional syncs)
• ERP integrations.

Common mistakes

• Using the wrong Field or Variable
• Too many SOQL queries
• Object & Field Level Security for running user
• No Access to Running Flows