11

IS there a way to break a single flow into 2 transactions?

we have a really long flow that does a huge part of our business process, we are hitting governor limits due to the number of update/inserts/fastlookups etc.

I am trying to break the transaction, some of the ways I found were

  1. To call an invocable method and call batch apex to recontinue the flow.
  2. Insert a wait element. as per docs.

A transaction ends as soon as a flow interview begins to wait for an event. When the flow interview resumes, a new transaction begins. Everything after the Wait element is executed as part of a batch transaction that includes other resumed interviews.

From the language above I am not sure if the new transaction still has access to the queried data from the first transaction before the wait.I am assuming the data won't be available for the second transaction.

Is there other ways folks here have used for breaking a long flow?

15
+100

Using a Wait (now called Pause) element does preserve the Flow's state, including all of its variables and the field values of queried sObjects, across the boundary into a new transaction. As expected, limits are reset across the transaction boundary.

This strategy is more or less explicitly endorsed by the documentation:

A transaction ends as soon as a flow interview begins to wait for an event. When the flow interview resumes, a new transaction begins. Everything after the Wait element is executed as part of a batch transaction that includes other resumed interviews. [...]

Consider using multiple Wait elements so that the DML operations and SOQL queries are performed in multiple transactions.

But you need to also be aware that, like Workflow Rule Timed Actions, Flow Interviews are batched when resumed, and this can cause limits consumption to not look like what you expect:

Interviews aren’t resumed independently. They’re grouped into a single batch that starts resuming within one hour after the first interview enters the batch. Actions that execute as a result of the grouped interviews are also executed in that transaction. [...] This behavior can cause you to exceed your Apex governor limits if the resumed interview executes DML operations or SOQL queries ...

Simple Demonstration

Here's a demonstration. I put together a simple Flow thus:

Flow diagram

It's an autolaunched Flow. It queries a single Account record (at random) and stores it in an sObject variable. It calls an Apex Invocable Method (below) to check Limits.getQueries() and stores the result in a Number variable. Then, it Waits for a Platform Event.

When the event is fired and the Flow resumes, it re-checks the SOQL limit and stores that value too. Finally, it sends an email with both SOQL values and a field value from the original queried Account back to me so I can look at the results.

Here's the Invocable Apex:

public class InvocableSOQLLimit {    
    @InvocableMethod(label='Check SOQL Limit')
    public static List<Integer> checkSOQLLimit() {
        return new List<Integer>{Limits.getQueries()};
    }
}

And here's what I get in my email afterwards:

Account Name: ACME Industries
SOQL Before: 1 
SOQL After: 0

This shows that the transaction limits were reset (we burned 1 SOQL on the original query, and none after the Wait element), but we preserved the original Account field values queries before the Wait. (They may now, of course, be stale).

Of course, you must contrive some way to have your Flow restarted. I just used a sample Platform Event, Test__e, that I fired via Anonymous Apex:

Test__e event = new Test__e();
EventBus.publish(event);

But that's not going to facilitate a production Flow. Instead, you can configure your Wait element to go off "more or less now", zero hours after the current date and time:

Flow Wait configuration

As far as I can tell, the docs (and two) are not explicit on the exact semantics of this time trigger when it's in the past, but it seems to work like Process Builder (as one would expect, since they're the same under the hood and the rest of the mechanics are similar): setting it to zero results in a resume within a few minutes, subject to server load.

  • 3
    That's one hell of an explanation. Thanks David, the 0 hours is such a blessing that I don't have to make async invocable methods to split the transaction. I was looking for alter ate answers on how people innovatively break their flows. I will leave this open for a bit to gather more answwrs. – Rao May 14 '19 at 4:34
  • 1
    This is pretty clever – cropredy May 14 '19 at 6:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.