The “What” and “When” of Salesforce Flow

Application Architect, Bruce Stewart explains what automation tool upgrades to expect when adopting Salesforce Flow.

If you’re curious about automation in Salesforce, in the past few years you’ve definitely been encouraged to “go with the Flow.” Clicks before code has long been the “best practice” mantra. Now with Workflow Rules (WFR) and Process Builder (PB) retiring (no new WFR as of Winter 23′), Salesforce Flow is by far the preferred method to add declarative automation to your Salesforce instance.

You may have been asked to adopt Salesforce Flow without a deep background on this automation tool, or the 2 automation tools that preceded it.

Automation in any form – development (code), integration, WFR, Process Builder, or Flow alike – contain 2 aspects: when-to-act and what-to-do. The various tools may have different names or representations. For example:

• A Workflow Rule (when) runs Workflow Actions (what)
• A Process Builder (entry criteria/criteria node tells when; an action node tells what).

Workflow Rules

When (Rules) – After Record Create or Update (not Delete). No screens (User interface, so no user input).

What (Actions) – Field update (same record only), create task, send email alert, or “outbound message” (a form of integration).

Process Builder

When (Entry Criteria & criteria nodes) – After Record Create or Update (not Delete). No screens (User interface, so no user input). “Entry Criteria” means which field values, changes, or even formulas will consider the criteria and actions within the process. Process Builder is graphical, and works from the top down, so your entry criteria go first.

Example: Entry Criteria: should I do anything to this record?

• If yes, the action(s) are run (across). 
• Then the next criteria node is considered, action(s) run or not, and so on down the screen.

What (Actions) – Field update (same object or related: Lookup or Primary/Detail) or “child” related records. Email alerts, submit for approval, fire platform event (a form of integration).

Whatever it’s referred to above – the “when” was always after a record creation or field value update that succeeds (meaning one that is written to the database, passing validation within transaction limits).

Flow

Let’s dig into the various types of flows, and several choices or experiences of the “when” and the “what”. 

Schedule Triggered Flow

Apart from any other “change” in the system, you can schedule a flow to run when you say. One time only (ever period). Or, schedule it up to once per day.  Note: You can copy a scheduled flow and change the run-time to achieve > 1/day. Scheduled flows can look at a “collection” of 1 object’s records that meet entry criteria when your flow next runs. It can consider values, perform decision logic and act on individual records in the collection, act on other related (or unrelated) records, or perform some summary job like sending a notification. This can be a powerful tool to see what records may look like “right now” as changes may have occurred over time or to various child records, all adding up to something greater than the parts.

Example: Every Day, check if any open Opportunity (value > x) has more than y product families among its line items” and if so, notify operations.

Subflow

Since flows can “call” another flow, you can set a flow up as a “little machine” which is called a subflow. Simply said, you package up the “what” (simple or complex) so that you or others can run it whenever. Subflows are labelled in the system as “autolaunched” flows. (No Trigger). This means you supply the trigger by “calling” your automation from another flow. Add such subflows to any other flow as an “action” alongside any “get records” “assignment” “Update” or “Loop” nodes.

Consider using this for any operation you may want to make happen the same way (or considering the same factors the same way) in different parts of your org. Maybe you want a notification sent when an opportunity stage is changed, but the stage may be changed by various methods such as modifying line items, modifying the opportunity record itself, or the account etc.

Record Triggered Flow

• “Fast Update” or “Before Save” – Similar to Field Updates in WFR, this kind of flow can only update the record whose change launched the flow, and meets the entry criteria. Edit your “Big Deal 2023” Opportunity, and its before-save flow can get other records, make decisions about them, but ultimately update ONLY the “Big Deal 2023” record that started things. This is an important flow type, in that its updates occur before the record-create (or the user’s edits) are written to the database. As such, they happen along with those edits, and occur much faster than other clicks-not-code updates have been able to in the past. They do NOT produce a separate “last modified” date/time value, as they occur right along with the user’s edits

• “After Save” – Can update the record whose change launched the flow (and met entry criteria), or update, delete, create other records, too. The records you affect do NOT have to be related to the modified record. Like Process Builder, updates occur after any user’s edits. These flows can do all the things a PB could (launch approval, create platform events, send email alerts, create custom notifications, etc).

• Record Triggered Flow “Before Delete” – This is a powerful new addition to the flow power tool aisle. In the past, nothing other than Apex triggers could respond to a record deletion. Now that flow can too, you may have to do some double-duty and consider what happens when a child (Opportunity product of your Big Deal 2023 is added or changed, but ALSO (now that you can) consider what may happen when one is about to be deleted. A roll-up summary out of the box reacts to any of these things, and now your custom automation can, too. 

Platform Event-Triggered Flow

This is a special kind of “after create” record-triggered flow, based on a special kind of object – a Platform Event, which you define. Often based on some other object or record change (or something that happens in a system apart from Salesforce), this kind of flow waits for and processes incoming “Platform Events” that meet the criteria you specify.

Screen Flow

This is unlike either WFR or PB. Those 2 older tools always did what they were told, when their criteria was met. They evaluated records when changed, and if criteria were met, they did what your actions instructed. Screen flows allow users to take part (do what you provide for them when they may wish). Maybe you just want to show users the Opp products from that big deal. Maybe you want to give them the chance to fill in some missing data, or choose to leave it blank or override something.

The choice is theirs; you can display information in familiar screen controls, include custom controls of your own, or ones that you obtain from AppExchange, or UnofficalSF. You can present screens with very few or many controls, and you can show or hide them based on record data or on previous actions by the user. You can build these screens up into steps, providing a “wizard”-like experience for your users to safely view or alter needed data. You can apply logic to their entries, and if needed do what the other flows can do – edit the record, edit other records, create records, send notifications, or even delete records, all with user participation.

Templates

You may see other flow types in your Flow Builder, when choosing [New Flow] – due to other packages installed in your org. Field Service Mobile, Salesforce Scheduler, Contact Requests, Recommendation Strategy, Orchestrations are just a sample.

No matter what type of flow you choose for your current automation task, there can be multiple record-triggered flows on a given object (and you can determine the order they may fire). Overall, the Salesforce platform provides 2 more “when” and “what” frameworks or limits.

• “When” framework, is the Order of Execution, which is a strict order in which “types” of activities fire during a record-save in Salesforce. Strict means – on a given release of Salesforce – Before-Save flows go before Before-Triggers (Apex), which go before system validation, etc.  “types” of activities means that while “Before Save” flows go at this time, (which ones go in which order) is either not-determined, or is determined by you the admin if you specify a Trigger-Order value.
• What framework is the set of Execution Governor Limits covering how long or how much work a given transaction can accomplish. A transaction is the entire save operation (See Order of Execution) for the given record and any records its change may affect. Think of Houdini’s to-do list while handcuffed underwater in a barrel). Every element of the transaction must complete within limits, or the operation may fail.

Any of the flow types above can contain rich logic and looping controls that WFR and PB did not offer. In addition to taking the actions you intended, you can also add “Fault Handling”, a way of trapping errors. From these occurrences, you can send notifications, or even create “Error Log” entries as activities, or a custom object record.

They all help contribute to uniform processing within your org – meaning you as an admin establish “how” we do things, and they can automatically do or assist users in doing them that way. They all run at some time, either by user interaction with a screen flow, or by editing a certain field a certain way. There are lots of pathways to implement safe and robust automation that scales with your organization’s needs. It can be confusing when to implement such tactics, and what to entrust them to do for maximum impact.

RafterOne has experts who can help you establish the best when/what combo’s to move your business forward. Let’s connect.