Use the ‘Commit Transaction’ Action to Get More From Your Screen Flow Limits

CommitTransaction is a simple Flow Action that works in Screen Flows and simply causes any open DML transaction to close. This is the same thing that happens whenever a Screen element executes or when a Flow ends. Having it in the form of this action allows you to close transactions in places where you might otherwise violate limits.

Consider this Flow:

This Flow highlights the ability of the Flow Action Generate Collection Report to create attractive output out of lists of records:

Note that in order to generate this report, the set of related Contacts has to be queries for each Account. This is done in a Loop, and if the initial set of Accounts is near or over 100, you’ll get this error:

This is happening because the 100 passes through the Loop are all being aggregated into a single transaction. This makes sense in general as a system efficiency technique, but it’s not what we want here.

If we insert a CommitTransaction action into this loop, it becomes 100 individual transactions, and the flow finishes properly:

Here’s where I inserted it:

You can see this in action in the video on this post. Keep in mind that the grouping of activities into a single transaction makes slow things run more quickly, so if you place Commit Transaction into big, busy loops, it may take a lot longer than you’re used to.

FAQ

How does this work?
If you look at the code, you’ll see that this action is actually an empty Local Action. Local Actions, by dint of their architecture, close open transactions.

How is this different from the ‘zero-duration Wait element’ approach?

Probably nothing. This is just a little more straightforward to implement, at least once you have it installed in your org.

Does this work in Autolaunched Flows?

Sadly, no. For those, use a Pause element and give it a time of 0 to get the transaction to close.

Install

Version 1.0 Unmanaged 6-13-20

Source

View source

Subscribe
Notify of
guest
16 Comments
Inline Feedbacks
View all comments
Adam White

Really cool, thanks Alex! This makes it much easier to work with limits in autolaunched flows.

Shmuel Chaikin

It does not work with autolaunched flows!

image (5).png
Darrell DeVeaux

Is this better than a 0 hr Wait element? If so why? I looked at source and it’s empty from what I see so it seems similar in functionality no?

Clifford

Does that mean, we can do a callout after a DML element, if CommitTransaction is placed between them?

Raz Gat

Game changer for roll up summaries! Amazing Alex

Eric Schubert

Can you put up a second screenshot of where the ‘CommitTransaction’ Action should be placed in the Flow above? Thanks!

Eric Schubert

Thanks for adding the screenshot! I added the component to a Flow I had which was failing due to the ‘Too many SOQL queries: 101 error’, and the error has disappeared!

Mimi Sakarett

Thanks for sharing! This seems like it would be most helpful to use after every n records, instead of for every record. What about creating an outer loop that calls the inner loop n times, then calls Close Transaction?

Mimi Sakarett

A colleague of mine suggested an alternative to an inner and outer loop:

no need for another loop if you’re building a collection, simply use an assignment to get the count of the collection, then a decision to either keep it going or reset and close transaction

Narender Singh

I have been using this approach for quite a while, but sadly local flow actions can only be used in Screen flows. And from my experience, working around the limits in Screen flows is much easier as compared to Autolaunched flows. The only option available for Autolaunched flows is Pause element which seems very hacky to use.

[…] next to send”, and it would commit your update. You can eliminate that step with the Commit Transaction action if you’re using a Screen flow, and with a Pause element set to a zero time duration if […]

Craig Woodman

I just used this one today. Great when you change a record, and then launch a subflow, and you want to make sure the changes are committed before launching a subflow WITHOUT presenting another screen! Worked like a charm!

Bruce Frager

I have what seems a perfect screen flow application for this but it is throwing the error ‘Error element Close_Open_DML_Transactions (FlowActionCall). This flow contains local actions, so this flow runs only in Lightning runtime.’ that I don’t quite understand why it is failing. I am processing 1000+ source records creating several child records and each loop consumes 4-5 DML statements so I have to run batches of 20 to avoid a rollback before I hit the gov limit of 100, requiring 50+ batches ! In the loop, after 19 records, I added the ‘Commit Transaction’ hoping to reset the DML… Read more »

Last edited 1 day ago by Bruce Frager