In Salesforce, a flow is an application that automates complex business processes. Simply put, it collects data and then does something with that data.
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.
Flows fall into five categories:
Screen Flows:
These are flows that have a UI element and require input from users. These types of flows are either launched as an action or embedded as an element on a Lightning page.
Schedule-Triggered Flows:
These autolaunched flows launch at a specified time and frequency for each record in a batch, and they run in the background.
Autolaunched Flows:
Run automated tasks with this flow type. Autolaunched flows can be invoked from process builder, from within an Apex class, from a set schedule, from record changes, or from platform events.
Record-Triggered Flows:
These autolaunched flows run in the background when a record is created, updated, or deleted.
Platform Event-Triggered Flows:
When a platform event message is received, these autolaunched flows runs in the background.
Check out this example of a schedule-triggered flow, pulled from a well-known Salesforce group:
When/why should I use a flow?
To answer this question, we really need to look into what automation is needed. In most cases, the type of automation to use for a specific process 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.
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.
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.
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. Processes also cannot query records unrelated to the invoking record.
When should I not use a flow?
Generally, you should not use a flow in the following situations:
There is complicated logic involved that is better managed with Apex code. An example of this is the flow shown in the Overview section. The logic in this flow is so complicated that it makes debugging a pain, plus it makes documenting and managing the flow difficult.
Your Salesforce edition limits how many flows you can create. Essentials and Professional editions of have a limit of five processes (per process type) and flows (per flow type) in each organization. For most logic in these editions, it is easier to use a process.
How do I create a flow in Salesforce?
Open Flow Builder. From Setup, enter “Flows” into the Quick Find box, select Flows, and then click New Flow.
Select the Flow Type, then click Create.
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.
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!
Save your flow.
After you build a flow, make sure that it’s working correctly by thoroughly testing it. Once you’ve tested it, 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. Just remember, no matter how you execute it…you’ve got to go with the flow.
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.
You need to be able to control the batch size of your automation in order to prevent limit errors.
You need to present an error message in the UI if the automation fails or doesn’t find what it’s looking for.
Flows vs. Processes
Processes are more user-friendly as far setup and management goes.
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).
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.
Flows can be test-run and run in debug mode on the flow canvas, including in a rollback mode, which allows you to test your automation without making changes to your data.
The following actions are only available for processes:
Quip actions
Send survey invitation
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.
Testing Flows
To test a flow, click the Debug button on the canvas, input your variables, and click Run. Then run through the flow to make sure it works properly. This process is especially helpful with screen flows.
Note that as of the Winter 2021 Salesforce release, a beta feature called Debug on Canvas is available. This feature makes flow debugging easier by visually demonstrating the path your flow will take when it runs. It also shows query limits of the flow in the debug details. Additionally, debugging now offers a two more options than it did previously: Run flow as another user, and Run flow in rollback mode.
Where is the Flow Builder in Salesforce?
To find the Flow Builder in Salesforce (Lightning) navigate to Setup > Process Tools > Flows.
What are the different Flow Types in Salesforce?
Auto-Launched Flows with No Flow Trigger
These flows don’t require user interaction, and they don’t support screens, local actions, choices, or choice sets. The available distribution methods available are:
Flow actions
Lightning pages
Lightning community pages
Custom Aura components
Custom Lightning web components
Custom buttons or custom links
Web tabs
Direct flow URLs
Visualforce pages
Lightning out
Embedded service deployments
Auto-Launched Flows with a Schedule Trigger
These flows only run from a schedule that the user sets. They don’t support user interaction, screens, local actions, choices, or choice sets. The available distribution methods are:
Processes
Custom Apex classes
REST API
Web tabs
Custom buttons or custom links
Visualforce pages
Screen Flows
Screen flows require user interaction because they include screens, local actions, steps, choices, or dynamic choices. Screen flows don’t support Pause elements. A schedule-triggered flow only runs at the scheduled time and frequency.
Auto-Launched Flows with a Record Trigger
These flows are designed to quickly make simple changes to a record when the record is created, updated, or deleted. They can also be configured to make those changes either before or after the record has been saved to the database. In a before-save flow, the supported elements are Assignment, Decision, Get Records, and Loop. After-save flows have access to all flow capabilities, but they cannot launch sub flows.
User Provisioning Flow
User provisioning flows provision users for third-party services. You could use this flow type to customize the user provisioning configuration for a connected app, linking Salesforce users with their Google Apps accounts. A user provisioning flow can only be implemented by associating it with a connected app when running the User Provisioning Wizard.
Field Service Mobile Flow
These flows require user interaction because they have one or more screens.
Field Service Embedded Flow
These flows require user interaction because they have one or more screens.
Contact Request Flow
These flows require user interaction because they have one or more screens. Use one of the following Experience Builder components to add this flow:
Contact Request Button & Flow (launch the flow in a popup window)
While a flow is an application built by your administrator that asks you for inputs and does something in Salesforce based on those inputs, a flow interview is a running instance of a flow.
For example, a flow could provide a call script for customer support calls using the information you provided to create a case. What the flow does with the information you provide is entirely up to your administrator.
When you run a flow interview, whether through a link, button, or tab, you’re running a single instance of a flow. If the terminology is confusing, consider the difference between a record and an object. You create an account record, which is a single instance of the account object that your administrator customized.
How do you call a flow from a button in Lightning?
Since Winter 2018, Salesforce has offered an easy way to trigger a flow using a Quick Action button in Lightning.
Note: Only screen flows or field service mobile flows may be launched from a Quick Action button.
Create a custom action for the record in question by navigating to Object Manager > (Object Name) > Buttons, Actions and Links.
Select “Flow” as the type for the custom action.
Configure the custom action to reference the flow, then name it.
Add the custom action to the page layout of your choice.
Common Mistakes When Designing Flows
We see a lot of flows here at Kicksaw, and we build even more of them. Here are some common and avoidable mistakes we’ve identified:
Using the wrong field or variable
Not checking for null values
Too many SOQL queries
Object & field-level security for running user
No access to running flows
Using PRIORVALUE of a record in a Lightning flow
Salesforce allows you to add access to the PRIORVALUE of a record in a Lightning flow, in a way that is similar to the way the Process Builder worked. This brings flows to the next level.
After selecting the object, Salesforce will automatically create a record variable ($Record__Prior) for it. You will then be able to refer to it anywhere in the flow.
No comments:
Post a Comment