Infinite Flow Refined

UPDATE - 7.7.15: This will eventually trigger an error and is now a known issue, with expected behavior listed as “TBD”. So as I expected, its not known whether this will be a supported use case or not. Using a fast lookup / update this will run about 30 times before failing, using a regular lookup / update will run about 90 times before failing. Use at your own risk, but its still pretty damn cool.

In a previous post I provided a proof-of-concept for a simple flow that posts to chatter every hour, forever, on an opportunity. Will call that version A.

I have iterated to demonstrate a version with controls (Version B), so it fires on a recurring basis as long as the opportunity is open. From there, I have created a version (Version C) that waits for last modified date, thereby only posting if the record has been modified within the given time period.

Version B of the flow consists of the following elements

1. Wait element (start of flow)
2. Fast-lookup to pull in opportunity fields
3. Decision element to determine if the opportunity is open
4. Post to chatter if open
5. Fault element to post to chatter in case any unexpected error occurs

The fast lookup pulls in the opportunity IsClosed field, and the decision element evaluates whether IsClosed is false. If IsClosed is false (the opp is still open) , then the flow proceeds to post to chatter.

The actual goal I set out with is to only post if the opportunity has not been modified, so to post X hours/days after Last Modified Date.

Conveniently, Wait elements treat dates similarly to time-based workflow rules, where they will update the time to fire if the date field changes (see the section on “relative time alarms limitations” on this documentation article. And (unlike workflow rules) we can reference Last Modified Date in Flows!

So, Version C works as follows.

1. Wait element - start of flow, waits for last modified date on input variable
2. Fast Lookup - pull in key fields to an opportunity Sobject Variable
3. Decision to see if opp is open
4. Chatter post
5. Assignment that sets a value for a DateTime field
6. Fast Update to set custom DateTime Field on Opp (so that last modified date is updated on the record)
7. Wait element 2 - waits for last modified date on SObject Variable
8. Fault element, in case something goes awry

The reason I used 2 wait elements is that it allows me to use one less lookup. The initial wait element on the flow is configured to wait for LastModifiedDate from a variable set by the flow trigger ( vaOpportunityID )

The second one waits for LastModifiedDate from the Sobject variable that is populated by the fast lookup.

Note that I did not need another lookup after the fast update to pull in last modified date. The wait element appears to pull in the updated value of the last modified date field by itself, as otherwise it would fire immediately.

The 2nd wait element might not be necessary. The infinite flow might work with just an initial wait element and an update operation. The wait element might pick up the change to last modified date and delay appropriately. I will update this post when I get around to testing that version.

And the proof..is in the timestamps

Use with caution. Keep your flow limits and time-based flow limits in mind, such as:

*An organization can have up to 30,000 interviews waiting at a given time.
*An organization can process up to 1000 events per hour.
*After you deactivate a flow or flow version, the associated waiting interviews continue as usual.

That said, this official sample flow that waits for many Events is not all that different from the infinite flow model, so I think (safe harbor) that this should work for just about forever.