I am currently tasked with migrating all of an Org's Workflow Rule (WFR) and Process Builder (PB) logic to Flow. This was mostly a trivial task, as each WFR entry condition and each "TRUE/FALSE blue diamond" in PB was equivalent to a Decision element in Flow, and the "TRUE" path connecting to the necessary actions (like update record, send Email Alert, Post to Chatter etc). I say this is a trivial task, because I did not need to fundamentally change the logic of the WFRs or PBs. I could just copy the entry condition into Flow (even for conditions which run only on create and when updated to meet criteria, instead of when created and updated) as well as the related actions to execute.

Now I am facing the following problem:

There are several (nine to be exact) WFRs which have the following parameters:

  1. The "Evaluation Criteria" is set to Evaluate the rule when a record is created, and any time it's edited to subsequently meet criteria
  2. Each individual rule has either an immediate field update OR a field update as a Time Based action (7 days after LastModifiedDate)
  3. On all these WFRs, the option "Re-evaluate Workflow Rules after Field Change" is ticked

After spending some time analyzing these WFRs, I have come to understand that they seem to be configured this way to create a sort of "loop" by always "queueing" new WFRs which fit the new condition after the field update from the old WFR. This kind of "7 day domino effect" then continues with the newly triggered/re-evaluated WFRs.

The WFRs with immediate actions (even though they need to be re-evaluated) could be mimicked in Flow by reconnecting the update element back to the top of all WFRs (to be evaluated again basically). But I cannot for the life of it figure out how I can mimic the case with Time Based Actions and "Re-evaluation" with Flow. The main issue I have is that WFRs can only run Time Based actions, if they are set to Evaluate the rule when a record is created, and any time it's edited to subsequently meet criteria, but this option is not available for Scheduled Paths: scheduled Paths will not know if the current record did not meet the conditions before.

Does anyone have an idea how I could go about this without fundamentally analysing the logic behind the WFRs and trying to implement them without "re-evaluation"?

1 Answer 1


Ultimately you're going to need some sort of analysis of what the workflow rules are trying to do, and then to write that analysis down; otherwise you'll just be doing this again in a couple years.

One possible refactor (i.e., I've done this, but am not sure how well it would apply to your specific case) would be to use a daily scheduled flow instead of a record-triggered one for your delayed actions, along with a (presumably hidden) date field as a timestamp: you set up one flow to immediately fill in the timestamp on meeting the original criteria, "Only when a record is updated to meet the condition requirements" (that's definitely still an option for flows).

You then set up the second flow to fire on all records that (1) meet the original criteria AND (2) have a timestamp of ("exactly" or "at least") 7 days ago. Do your delayed actions in that flow, and (if you picked "at least") also have it clear the timestamp field.

ETA: The main benefits of this approach (that I can think of offhand) are maintenance, predictability, and portability.

For maintenance, if you discover a mistake in the logic somewhere, you can fix it and have the changes apply immediately (rather than after a week while all the prior-version flows play out).

For predictability, well, you can run a report at any time and see which records will be affected during the next run, rather than having to go into "Paused and Waiting Flow Interviews" and digging around in there.

For portability, well, those paused-or-waiting flow interviews aren't really exportable if you ever need to migrate instances (or to another CRM), or need to replicate behavior in a sandbox on a less-than-glacial timescale.

  • Thank you very much Steven, I haven't thought of that solution yet!
    – Daniel L
    Commented Jan 27, 2023 at 5:23

You must log in to answer this question.

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