What to Know About Flow
Order Up the Right Flow Type for a Delicious User Experience
At 2021 Dreamforce, Salesforce announced plans to retire Workflow Rules and Process Builder and officially support Flow as Salesforce’s declarative automation tool of choice. And for good reason. When we enter into a fine dining establishment we walk in with high expectations for everything including great service, beautiful ambiance, clean bathrooms, and of course delicious food. In a word, we expect a great experience. Likewise, organizations paying top dollar for Salesforce expect a top-notch user experience when they login. Flow is the key for Admins to open the door to a whole new world of data visualization, automation, and integration for their users. As a result, incentives for Salesforce Admins to master Flow have never been higher.
This blog series aims to help Admins discover ‘the art of the possible’ with Salesforce Flow using illustrations and examples to outline best practices around designing, building, testing, and deploying Flows. In today’s article, we start with Flow design and focus on the various Flow types available as well as when and why to use them.
What is Salesforce Flow?
Salesforce Flow brings the declarative and programmatic worlds of Salesforce together and opens a door for Admins to deliver solutions to complex technical challenges previously restricted to programmatic solutions such as Triggers and VisualForce pages. With Flow, Salesforce admins can automate field updates, emails, Chatter posts, custom notifications, and CRUD (create, read, update, delete) operations; initiate approval processes; enable programmatic record access; call out to external systems; even create visual wizards to guide users along a custom process.
These capabilities can be used to meet a variety of business requirements. Need to update the closed date on an Opportunity when the status changes to closed-won? Do it faster and more efficiently with Flow. Need to send a mobile push notification to sales managers when a sales rep closes a deal? Use Flow. Need to create guided scripts for call center agents handling customer service? Again, Flow can make it happen.
Flow Types: What, When, and Why
When arriving at a fine restaurant, known for its variety of decadent dishes, the first order of business is to familiarize oneself with the menu. Each time we create a new Flow, the first screen shows our menu of options (Flow types) along with a brief description. Picking the wrong dish can ruin a restaurant experience; likewise, picking the wrong Flow type can lead to frustrations and headaches and ruin an otherwise happy day of Salesforce solutioning. Just as a good waiter will talk us through our likes, dislikes, and curiosities to select the best dish; we need an understanding of the different Flow types to help guide us into selecting the best choice to meet our automation needs.
Continuing with our restaurant metaphor... if our ‘fine dining’ establishment was Burger King, Screen Flows would be the beloved Whopper. Of the dozens of Flows I’ve ordered up in my own career, I’d estimate a good 75% have been Screen Flows. Why? To steal a line from Burger King, Screen Flows let you ‘Have it Your Way.’ While the introduction of Lightning Experience and Dynamic Forms have greatly improved the ability to customize the Salesforce user experience, Screen Flows remain the go-to option for Admins to tailor the Salesforce UI in order to guide users along a business process.
With Screen Flows, Admins connect multiple screens together by branching logic. Each individual screen can be heavily customized to include rich-text formatted display text, data from almost any record in Salesforce (or even outside of Salesforce), the ability to make this information conditionally visible and organize it into multiple sections and columns, and options to fire off pretty much any form of automation you can think of as users move along the process. Admins can also extend out-of-the-box Screen Flow functionality with help from developers by embedding custom Lightning Web Components and calling invocable Apex.
Finally, building screen Flows is fast. Crazy fast. The same requirements that may have taken weeks to implement through a purely custom solution can often be built in a matter of days using a Screen Flow. In the example below, call center agents need guidance and resources as they receive inbound calls and guide callers through making an order, getting directions, or handling a complaint. In a matter of hours, a Salesforce Admin can put together a proof of concept such as the one below. This solution could either be enhanced through additional features such as integration to an external order system or later replaced through the purchase and configuration of a CTI solution.
Pros:
- Add manual overrides and controls to embedded automation.
- Provide visual confirmation of automation executed (no custom code required).
- Stitch together data from multiple sources.
- Initiate from various locations in the Salesforce user interface, including the home screen, record pages, the utility bar; and from add-ons such as Actions & Recommendations, Flow Orchestrator, and Einstein Next Best Action.
Cons:
- Introducing new screens can sometimes frustrate or overwhelm users who prefer the magic be done behind the scenes.
- Users may neglect to initiate the Screen Flow if they can’t find the button or never bother to click it.
Use Cases:
- Guide call center agents through customer service interactions.
- Walk sales reps through creating a contract.
- Visual automation of almost any business process imaginable.
Options 2 and 3: Record-Triggered Flows and Platform Event-Triggered Flows:
People are notoriously forgetful. Automated lights and faucets were invented for a reason. Restaurant and other building owners long ago learned that by removing light switches from their walls and handles from their sinks, they could save enormously on electricity and water. Record-Triggered Flows and Platform-Event Triggered Flows provide a similar convenience to Salesforce users who may or may not remember to click a button and initiate a Screen Flow. In the right scenarios, these two types of Flows work beautifully. But a word of warning, all automations are prone to mistakes. Just like a good restaurant owner doesn’t want their customers frustratingly waving their hands around in front of a faucet to wash their hands, we must ensure Record-Triggered and Platform Event-Triggered Flows are always written with a clear understanding of when, and when not, to fire.
Record-Triggered Flows enable Admins to trigger automation when a record on a specified Salesforce object is created, updated, or deleted. Generally, the introduction of record-triggered Flows has eliminated the need to execute such logic through Workflow Rules and Process Builder; as well as handle more advanced logic previously requiring an Apex Trigger. The advantages of migrating Process Builders and Workflow Rules into Record-Triggered Flows include centralizing declarative logic, helping to avoid overwrites caused by order of execution issues, improving overall system performance, and ability to handle greater levels of complexity.
In the example below, Sales Executives want to automatically change the Record Type of Accounts from Prospect to Customer the first time an Opportunity is closed-won. While Admins can also accomplish such a task using Process Builder, building the automation in Flow provides better options to handle complexities if requirements expand. For example, what if in addition to changing the Record Type we need to call out to an external system to provision a master customer number, and wait until the customer number is assigned before initiating services? Starting with Flow sets us up for success with abilities such as running asynchronous Apex, using an External Service, and leveraging add-ons such as Flow Orchestrator.
Platform Event-Triggered Flows enable Admins to trigger automation when a Platform Event occurs. Platform Events are messages sent either by an external system, or within Salesforce itself, and are a good way to let interested parties (subscribers in a pub-sub model) know that something important has happened. Admins who have created Process Builders initiated by a Platform Event can migrate automation logic to this type of Flow.
Pros:
- Faster performance than Workflow Rules and Process Builder.
- Create hybrid declarative/programmatic solutions by supplementing with invocable Apex.
- Toast Message can be displayed to provide visual confirmation when an automation occurs (Custom code required, Record-Triggered Flows only).
- Ability to use Scheduled Paths to run automation minutes, hours, or days after the triggering event occurs (Record-Triggered Flows only).
Cons:
- May fire in unintended circumstances, such as during a data load.
- Greater level of difficulty than Screen Flows to handle errors and edge cases for exceptions to when logic should fire.
- Salesforce doesn’t provide a good Flow substitute for Apex test classes. As a result, testing is typically done manually.
Use Cases:
- Automatically change an Account’s record type from ‘prospect’ to ‘customer’ the first time a related Opportunity record is closed/won.
- Email a satisfaction survey automatically after closing a Case.
- Transfer files from the parent record when users create new child records.
- Access object’s share table and Apex sharing reasons to enable programmatic sharing of records.
- Replace and retire Workflow Rules and Process Builders.
Option 4: Schedule-Triggered Flows:
A good chef buys their ingredients early in the morning before the restaurant opens and a wave of hungry customers start making orders. Likewise, database administrators have long learned to handle as much system automation as possible overnight, while users are not actively using the system and taking up processing power. With Scheduled-triggered Flows, Admins no longer have to rely on developers to write scheduled jobs to handle such automations.
Admins should also consider using Schedule-Triggered Flows to handle requirements previously done through time-based Workflows and scheduled actions in Process Builder. For example, we may receive a requirement to send an automated email to customers 15 days after an Opportunity’s Closed/Won Date. Rather than writing a time-based action, we can write the following three-step solution. First, write a ‘Fast Field Update’ Record-Triggered Flow to stamp a custom date field, Follow up email date, on the Opportunity 15 days after today’s date. Second, write a Boolean (checkbox) formula field, Send email today, that returns true when Follow up email date is equal to today’s date. Third, use this formula field in a Schedule-Triggered Flow’s Condition Requirements to send emails overnight. The Scheduled Flow will automatically run this logic for every Opportunity record where Send email today equals true.
Why not write a Record-Triggered Flow with a 15-day scheduled path instead? While this approach requires more steps to build, it pays off in the time saved during testing and debugging by dividing up the logical components. For example, if an Opportunity owner does not get a reminder email, replicating the issue becomes much more straightforward: (1) was the ‘send reminder email’ date stamped with the appropriate date? (if not, retest and debug the record-triggered flow); (2) Does the email appear in the Salesforce email log? (if no, retest and debug the Schedule-Triggered Flow; (3) was the email sent by Salesforce but never delivered? (if so, work with IT to debug the deliverability issue). Alternatively, the same debug process for a time-based workflow rule, scheduled-action in Process Builder or pause element/scheduled path in Flow requires a more difficult process of hunting down whether or not the record was initially added to the scheduled queue, and if so, why and when it was removed from the scheduled queue during the 15-day interim. Additionally, this option allows an easy way for users to override the logic and cancel the automation through updating a field.
Pros:
- Free up processing power and help minimize order of execution-related errors by running bulk automations during system downtime.
- Simplified testing and debugging process when compared to Pause Flows, Time-based Workflow Rules, and Scheduled-Actions in Process Builder.
Cons:
- Limited to schedule to daily or weekly.
- Limitations in condition requirements often require workarounds such as creating formula fields.
- Users not aware the automation is scheduled will complain about bugs when they expect an immediate result.
Use Cases:
- Create a set of daily (or weekly) Tasks for Sales reps to call on Leads.
- Escalate any unresolved Cases to customer service managers before Friday morning.
- Schedule a series of customer-facing emails with the ability for users to cancel them before they go out.
- Make calculations and data transformations necessary for reporting purposes.
- Rebuild and retire time-based Workflow Rules and Process Builders with Scheduled Actions
Option 5: Autolaunched Flows:
Even though different dishes are cooked at different temperatures, you wouldn’t buy a separate oven for each type of dish. Instead, a single oven can be used and the temperature adjusted depending on the recipe. Similarly, there are functions to any automation that are reusable across multiple processes. Rather than building and maintaining each function separately, these reusable functions should be built as Autolaunched Flows and reused across several points of automation. Just as the chef can adjust the oven’s temperature depending on the recipe, an Admin can build Autolaunched Flows with input variables, and adjust their functions depending on what is passed in by the parent Flow.
Autolaunched Flows generally contain the same elements and capabilities as the other Flow Types, but require some other form of Salesforce automation to initiate, including other Flows, Process Builder, Flow Orchestrator, an Apex Class, or even an Einstein Bot. Previously, Admins were forced to initiate Autolaunched Flows from Process Builder when solutioning for record-triggered automation. With the introduction of Record-Triggered Flows, this is no longer necessary.
In our example, let’s look at how a Screen Flow can implement a reusable process by calling an Autolaunched Flow as a subflow. Our Screen Flow, Capture CSAT (customer satisfaction score), is designed to guide Account Executives through a process to collect key data points related to customer satisfaction. If the customer expresses interest in buying more widgets, we want to send a mobile push notification and assign a task to a team of Sales Reps assigned to the Account. Because this later function has the potential for future reuse (i.e. other scenarios exist where we want to engage our sales team in a similar manner), the logic to get the custom notification type, send the mobile push notification, and create/assign the task should be contained in an Autolaunched Flow initiated as a subflow, rather than embedded in the Screen Flow itself.
There are two major advantages to this approach. First, if the custom notification type needs to be changed or a new value needs to be added to the automated Task, such changes can be made in a single place. Second, if a future process also calls to engage the Sales Team in a similar fashion, this Autolaunched Flow can be reused and accelerate the speed to delivery.
Pros:
- Eliminate building and maintaining the same logic in multiple places.
- Helps with delegating effort and avoiding having multiple people working on the same Flow.
- Can now be initiated by Record-Triggered Flows natively.
Cons:
- Cannot be called from Platform Event-Triggered Flows.
Use Cases:
- Any form of logic that can be reused across multiple business processes.
Bon appétit! I hope you got your fill of Flow inspiration in today’s post. In future posts, we will continue to cover topics related to Flow design, including: (1) the different options to initiate Screen Flows from the Salesforce user interface; (2) additional security considerations to make when implementing a Flow-based solution; and (3) why Flow automations can overwrite (or be overwritten by) other automations and how to avoid these order of execution issues. Have a question or suggestion for a future post? Let me know in the comments.
Found this article useful? Hit that clap button. Really like it? Hold the clap, give it two, or fifty!
Follow Slalom Technology and read more articles on thought leadership in Technology.
