1

I am tasked to migrate an existing Process Builder which has several scheduled actions in it with different conditions/criteria (i.e. scheduled actions on different decision nodes).

How would I achieve the same with just one flow? It has to be just one flow because:

  • There are actions (i.e. set field value, update fields) that need to be executed first before a schedule path can be set
  • So we can ensure that different conditions are evaluated on the order the business prefers
  • We have a 1:1 object-flow policy

Thank you and have a good day!

3 Answers 3

2

Unlike process builders where the criteria is defined first followed by scheduled actions, you will have define Scheduled path first followed by Decision element in the case of lightning record-triggered flow. Take a look at the sample record-triggered flow screenshot below:
enter image description here

On the record-triggered flow, you can define multiple Scheduled paths (in each path, you will define when it needs to execute via Time Source, Offset Option & Offset Value) and then define the Decision element for evaluating the conditions that would allow the scheduled path to continue (basically the criteria defined in your process builder + any additional condition). Within the Decision element, you can also define multiple outcomes (which can be further condition based) or after the Decision element, add more flow elements for further processing.

The conversion of the process builder with scheduled actions into a lightning record-triggered flow may not be a simple straight-forward conversion because under few process builder criteria, you might have both immediate actions & scheduled actions. So in such case, under the immediate Scheduled path, you might want add few Decision elements and conditionally perform immediate actions. Also, in the delayed Scheduled path (for example, Run after 1 day in the above image), the Decision element might not be exactly same the process builder criteria because you are conditionally performing both immediate and scheduled paths. And, that would require additional conditions to be defined in the Decision element. There could be few corner case that are quite tricky to achieve via this approach.

Your existing process builder and the business requirements will eventually determine how to define the scheduled path & decision elements in the lightning flow. Note that the scheduled path execute under system context.

One point worth assessing before jumping into creating the lightning flow, esp. w.r.t your following point:

There are actions (i.e. set field value, update fields) that need to be executed first before a schedule path can be set

"Was the existing scheduled actions in process builder really thought thru and needed? Or do you just need to execute action based on updates/ decision outcomes?". If the answer to the first question is NO and the answer to the second one is YES, you can avoid using Scheduled path and design your flow using Decision/ outcomes & other flow elements.

1

As @arut did, I tried to sort out how you could do this recursively, by adding 'Scheduled Paths' to a record triggered flow. But you may not even be using a record triggered flow, and for almost all of the possible use cases I could imagine you having, that strategy just really doesn't work anyway.

Luckily, it looks like the answer is pretty simple. You can just use a 'Pause' element, as explained in this similar question.

3
  • Had forgotten about this option (although I had used it many times :)). This is a better solution in case of "auto-launched flows", but for record-triggered flows I guess scheduled paths is the way to go. Since, they were recently released by Salesforce, I guess they were just designed to be able to run a part of the flow dynamically at a different scheduled time. This question could actually be marked as duplicate of the question linked in your answer.
    – arut
    Jul 20, 2022 at 18:01
  • Thanks for the comment @arut! The problem with the scheduled paths is that the decision about whether to do the stuff on the 'future' paths is dependent on decision criteria that need to be made now. So you can't necessarily put the decision element on the scheduled path itself. I thought maybe you could put the decisions on the 'run immediately' path and use them to set some booleans on the record like 'should_run_one_day_later_scheduled_action' - then the scheduled path could look to that boolean. I think that could work sometimes, but it really depends on the use case. Jul 21, 2022 at 2:54
  • Yes, that's the approach I intended. I didn't really call it out explicitly, but mentioned Decision element might not be exactly same the process builder criteria & would require additional conditions to be defined in the Decision element. Downside to this approach is that its a bit of overkill if too many new fields are to be created for decision evaluation; might not be good from DB model perspective. Upside to this approach is that one might be able to club many conditions in a single decision element with multiple outcomes. Its dependent on the use case, requirements & the designer.
    – arut
    Jul 21, 2022 at 4:45
-1

You can create multiple scheduled paths using flow trigger explorer

try to segregate your process builder ,create rough sketch of paths if you have reusable logic then create a sub flow ,use it in your main flow

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .