Flows in Salesforce, also known as Lightning Flows, are the greatest help in automating manual data entry and tedious business processes. Flows support working smarter and mitigating hard work. It ensures precision-based task completion, yet it is also a time saver. Flows are powerful and helpful tools when set properly. Here, it is quite imperative to reiterate that wrongly configured flows can result in a mess and are hard to manage too.
Flow is a powerful application in Salesforce intended to handle and automate complex activities in business processes. Here, Flow Builder acts as a declarative interface for building individual flows. This interface helps you use code-based logic without the necessity of using any programming language.
5 different categories of flow
Screen Flows: It is a UI element-based flow where input is required from the user. These screen flows are often launched as actions or possibly embedded over the Lightning page as an element.
Schedule-Trigger Flows: These Schedule-Trigger flows run in the general background to launch or activate at a specific schedule with a frequency in a batch for every record.
Auto-launched flows: This is a flow type that helps to run tasks that are automated. Record changes, a set of schedules, or platform events generally trigger these auto-launch flows within the Apex Class and by the process builder.
Record-Trigger Flows: This is an automated or auto-launched flow that runs in the background when there is a necessity for record creation, updating, and deletion.
Platform Event-Triggered Flows: These are also auto-launched flows that work whenever a platform event message is received, and they are also run-in background.
Purpose of flows
Salesforce Flows are worth using whenever there is a necessity for automation. Here, the purpose of automation is determined by evaluating where the data needs to go. Also, consider it based on the end goal or accomplishment in a way that Flow can handle it wisely.
Flows are capable enough to create, edit, or delete a record that passes through them. Here, the record does not have to be related for the purpose of passing data within a flow. Flows can allow automated scheduling of running on set intervals for a collection or set of records.
The field workflow update is capable of writing data to the same record that invoked the workflow rule, or else it can also be seen as writing data to the master record of the master-detail relationship over the record that invoked the rule. Here, workflow rules are not capable enough to create, delete, or edit records.
The process builder created processes capable of writing data to a record, which that process can also understand as it can write data to records that are related either through a lookup or a master-detail relationship. Here, it is quite imperative to know that processes can create records but are not capable enough to delete those records. Also, similarly, processes are not capable of querying records that are unrelated to invoking records.
Flows Prohibition: It is important here to know that there are certain situations where you shouldn’t use flows, and those are
Whenever there is complicated or complex logic involved, it is always good to use Apex code instead of Flows. For example, there is a debugging task involved that is tedious and cannot be carried out through Flows.
Generally, your Salesforce edition always comes with certain limitations, and there will be a restriction on flows to a certain number of flows. For example, Essential and Professional Salesforce editions come with five processes and flow as the limit.
Flow creation in Salesforce
From Set-Up in the Flow Builder, go to Flows>Quick Find Box>Flows>New Flow.
Here, you need to select the flow type and click Create.
You need to start your flow here by dragging all the elements to be used over the canvas. Here, elements represent an action that Flow needs to execute. Examples in this context are writing Salesforce data, reading and collecting data, displaying information, etc. from Flow users, manipulating data, executing business logic, etc.
Now, connect all your elements in an order corresponding to the proposed execution in the runtime. It is important here to remember to connect the starting element with another one.
Now, you need to save your flow.
After building your flow, it is important to test it thoroughly to check whether it is working as planned or not. Once tested and everything is perfect, you need to activate your flow. This activated flow is now ready for distribution to end-users. It is good to know here that your flow can be designed for external users or internal users, and it can be made to run on your system too. You can deploy your created and activated Flow in any other organisation too.
Flow vs Apex
An Apex code demands a developer as well as Sandbox for its deployment. So, it requires a combination of professional and above-edition Salesforce to build for an organisation. But flows can be created in all types of Salesforce editions, and a sandbox is not at all required for their deployment.
Currently, the Apex feature is not available in Essentials, and similarly, many Apex features are limited in the Professional edition too. Also, Enterprise and its above editions of Salesforce too come with certain limitations, while Flow features are seen available in all editions with no such limitations as Apex does.
Apex code maintenance requires constant development, while Flow deserves very little work to keep it up to date. Admins can create and build flows, while Apex code generally requires building by developers only.
Apex code is always a last-resort tool, while flows are very simple to use before apex code.
Whenever the logic involved is too complex and tedious, Apex code is the only option, whereas flows are inferior to Apex as they fail to withstand complex logic.
Earlier, OLI Creation, Renewal Generation, and complex automation pieces and actions were developed in Apex, but now it is not the case as these are built through Flows in a way to preserve code space for Apex projects.
The situations that only deserve apex
Flows will be cumbersome and highly impossible while dealing with complex automation tasks with multiple steps and actions in Salesforce. In such situations, Apex is the only option.
Custom-built integrations with some other systems deserve only Apex, and Flows cannot be a better fit. When there are ERP integrations, Apex should be used.
When there is a chance of limitation errors due to batch size in automation processes, it requires Apex code only. If error message presentation in automation is needed, then Apex is the only choice.
Flows vs processes
From the perspective of set-up and management, processes are much more user-friendly than flows.
Screen addition to input data for users is a good capability in flows, while processes don’t have it.
There is a possibility to invoke flows at a set frequency and customised time by initiating by users and triggering a change in records. But in processes, things run automatically when set criteria are met immediately or at a scheduled time. Also, there is a possibility to invoke another process that was created in the Process Builder.
It is possible to schedule actions in both flows and processes.
Actions in a process in general are executed according to the order defined in the process. Flows are a little different here, with a capacity for operations with complex orders.
It is possible to build a flow that can endure the cycle through a wide array of related and unrelated objects. Here, processes are limited to related objects and base objects only.
It is possible to design a flow to run either after or before saving the record in the database. Processes are different here, with the ability to trigger only after saving the record to the database.
Flows are designed for triggering upon deletion, creation, and updating of a record, while processes are designed for triggering only for updating and creating a record with no triggering for deleting.
Flows are possible to test-run for debugging over the canvas, with a facility for rollback mode that tests automation without enabling any changes to your data.
There are two significant actions credited to processes, unlike flows, and that is:
- Quip Actions
- Send a survey invitation.
Flows vs Workflow rule
All Salesforce editions and Essentials editions are credited with flows, while WFR, or Workflow Rules, are not available in Professional Editions and Essentials.
Every new Salesforce release includes updated release flows with new capabilities and features, but this is not the case with WFR, and Salesforce does not actively update these.
There are always limitations with WFRs about how many can be active at a single point in time.
Scheduled actions are available in Flows as well as WFRs, but there is a limitation of one thousand triggers per hour for WFRs, unlike Flows.
It is possible to call multiple flows and Apex codes in a flow, while WFR can only make one decision.
WFR capability about actions is limited to a few, like creating a record or task, email sending, field updating, or sending an outbound message. Flows are capable enough to do many more.
Flows testing
Clicking the Debug button on Canvas can initiate your flow testing process. You need to input all your variables here and click Run. It will test the effectiveness and performance of your flow. Screen flows will benefit a lot from this testing process. If you’re using the 2021 Salesforce release, then you have access to the “debug on canvas” feature, which is a beta version. This feature is proven to be easy to debug for your flow, yet it demonstrates a visually flowing path during its run. The query limits of the flow debugging details will be shown clearly in it too. This version is credited with two more additional features for debugging, and those are “run flow as another user” and “run flow in rollback mode”.
Different types of Flows in Salesforce
Auto-Launched Flow with No Trigger: This is a type of flow where user interaction is not required and they do not support screens, choices, choice sets, or local actions. Distribution methods available in it 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, and embedded service deployments.
Auto-Launched Flows with Schedule Trigger: These are the types of flows that run on the user-set schedule. These flows cannot support screens, user interaction, choice sets, choices, or local actions. The distribution methods available in it are Processes, Custom Apex Cases, REST API, Web Tabs, Custom Buttons and Custom Links, and VisualForce Pages.
Screen Flows: These are the kinds of flows that require user actions due to their inclusion with the screens, steps, local actions, dynamic choices, or choices. Screen flows do not support pause elements. In it, a schedule-triggered flow runs only at the scheduled frequency and time.
Auto-Launched Flows with a Record Trigger: This is a kind of flow designed for making quick changes to a record during its creation, updating, and deletion. It is possible to configure this flow to make the changes either after or before that record is saved to the database. With a before-save flow, elements that are supported are decision, assignment, loop, and get records. With After-Save Flow, it has access to all the capabilities of Flow but is not capable enough to launch sub-flows.
User Provisioning Flow: This is a flow that enables users to provision for third-party services. This is a flow for customising user provisioning configuration for a connected app and linking Salesforce users’ Google Apps accounts. It is imperative to run this User Provisioning Wizard by associating it with your connected apps.
Field service Mobile Flow: This is a flow with one or more screens with a facility for user interaction.
Field Service Embedded Flow: This is also like Mobile Flow with one or more screens and enabled with user interaction.
Contact Request Flow: This is like the above mobile and embedded flow with one or more screens and user interaction. It is important to add one of the two Experience Builder components to this flow, which are “Contact Request Button & Flow (to launch Flow with a pop-up button) and Flow (to embed flow directly over the page).
Salesforce Flow Interview: A flow interview in Salesforce is a running instance of that flow. Here, Flow is always an admin-built application that requests inputs in order to carry out a Salesforce task. For example, a case can be created as a flow with the provided customer care call script. It means the administrator will create Flow using the information provided as input, and in turn, Flow will perform accordingly.
How to call a flow through a button in Lightning: There is a Quick Action Button available in Salesforce Lightning since 2018, which is a great help to trigger a flow easily. It is quite imperative here to remember that the Quick Action Button can launch only mobile flows or screen flows. Let us learn how to call a flow using this button:
A custom action should be created for the record in question by navigating via Object Manager>(Object name)>Buttons, Actions, and Links.
You need to select “Flow” as your type for the custom action.
You need to name it hereafter when configuring your custom action to reference the flow.
Now, add this custom action to the page layout of your choice.
Possible Mistakes in Designing Flows: There is often a possibility for common mistakes while designing a flow. Let us investigate those avoidable mistakes:
Wrong variable or field usage
Null value verification queries
Too many SQL queries
Field and object-level security for running users
Running Flows access failure.
Flows in Salesforce are definitely useful and effective when used wisely. Cloud Odyssey, as a Salesforce consulting firm, helped many clients with an innovative approach in Flows. It is important here to decide when to use flows, and an effectively created flow can definitely serve its purpose to the fullest.
