Perform Schedulable action in Salesforce Flow – Scheduled Path

Flow. A flow is a SF designed declarative tool for automation that can be used by SF Admin without need for a developer. You might know them under "Low code automation".
To build a flow you need to use three simple mechanisms – Triggering event, Element, and Path.

• Triggering Event – it is condition under record enters the flow and automation is processed.

• Element – It can be considered as a data operation – get record, update record, assing variables, etc.

• Path – Path is noted with grey arrow, and it is visual representation of processing order inside a flow. 

Path is required to save and run (even debug) flow since its job is to connect elements together. Therefore, it tells the flow in which order elements are executed. For better demonstration, Figure 1 can be used as an example. Once triggering event occurs, Get Records element is executed first continuing to Update Records element and-so-forth.

Note that example shown in Figure 1 is one of the most basic flows you can find in the real world. In the real world, there can be several decision elements (if-then statement); path can branch out quickly and make it more difficult to read flow.

What is scheduled path

A careful reader will notice "Run Immediately" sign on path mark right after triggering event. There are two ways to construct flow – Run Immediately path and scheduled path.  

The first path mentioned above is self-explanatory; this is part of flow executed once the triggering event occurs. On the other hand, scheduled path is part of flow executed after certain pre-defined period. The scheduled path is available for both – Free-form and Auto-layout.

Why and when should it be used?

In some scenarios, a SF Consultant might face a challenge where some action must be performed under certain period; or some actions need to be done on system variables (permission change, deactivating a user, etc.) and some data operation in one path.

In auto-launched flow, pause element is available where we can simply set time when our flow should continue. However, in record-triggered flows, we do not have such an option. Instead of pause element, we must use scheduled path. Soon, scheduled path will be used as replacement for Scheduled action in Process Builder when Salesforce will retire Process builders. 

Second scenario when scheduled path might come handy is when some standard object manipulation, e.g. case update, must be done in combination with system variables – permission sets, user, etc. When one combines these two elements together in one single path, salesforce will return error complaining about DML (Data Manipulation Language) limit. There are two viable solutions to overcome these limitations – create two separate flows, or split paths in one.

In Figure 4, the second example is shown. First, run immediately, path is used to get user data (yes, user is considered as system variable as well). Second, the scheduled path is set with 1 minute delay. In this path, we can work with sObjects as we are used to.  

How to debug scheduled path in Flow

The debugging process of scheduled path is the same as regular debugging process. The only aspect you should think of is to select which path will be checked. Once you select the desired path for debugging, you can proceed to select, or create a triggering event.

In some environments, admins might have a new beta feature for flow debugging called "View tests" (at the time when this article was written, test feature was in beta version, and it was not available in every environment). Scheduled path can be debugged as well.

Check which flows are scheduled 

There might be situations when admin would like to check if scheduled path has been scheduled an when it will be executed. This information is stored in Setup. In Setup, search for Schedule jobs. It's recommended to create separate view for flows to filter out scheduled apexes and other jobs running on background. Salesforce shows name of process, who, and most importantly when it will be executed.   

Salesforce Limitations and consideration

Like everything in the cloud-based world, a scheduled path has its own limits as well. At the time when this article was written, the only real limitation was the number of scheduled paths which can be run within 24 hours. The upper limit of scheduled paths to run is set to 250,000, or the number of user licenses acquired by your customer multiplied by 200. The higher number applies. Luckily for us administrators, the immediate path does not count to the limit.

It might seem that the limit provided by Salesforce is unlimited. An administrator should not forget that there are other flows running in your org and making your user's life easier. And in those flows, which might run periodically or when a user performs some action, some DML operations are executed. Therefore, it might happen that you will hit the general unquestionable Salesforce DML limit. Fortunately, this situation is quite easy to debug since Salesforce debugging tool will inform you in which flow the DML limit was met.

As it was mentioned above, run date and time must be set to execute scheduled path; for this purpose, any datetime value stored in record that triggered flow e.g., created date. This value is used as a baseline and the only thing that is needed is to tell Salesforce what time offset to use to execute scheduled path. The exact time is then stored in the Time-Based workflow section in setup. Authors note – at time when this article was created, there was no possibility to dynamically assign time offset value i.e., time offset value must be constant.

And here comes the tricky part. Salesforce is dynamically checking what time offset has been provided to it and the datetime value stored in record which is used as baseline. In other words, the baseline value can change over time, but the offset does not. This is the main consideration one should think of before setting up the scheduled path.

On the other hand, everything what seems to be disadvantage might be, in the end, turned into our favor. Let us imagine a use case when you must, for example, create automation to send a reminder to anybody who sets an appointment. As we all know, the appointment can move back and forth. To meet this request, we can use datetime field where the information about an appointment is stored and use this field as baseline value. The reminder itself can be sent, for example, one day before that appointment is scheduled.   

Author: Miloslav Dohnal | LinkedIn