Process builder: multiple actions in a single schedule container considered a single transaction?

Question

In process builder, I have to use a Scheduled Action container in order delete some permission set assignments (mixed DML). There could be more than 10K assignment records, so I have use two actions in the container to delete half the assignments each. Each action calls a flow to delete the records.

However, if the system considers these two actions in the scheduled container to be a single transaction, then they will fail if the total records are more than 10K.

Does anyone know if the actions are the same transaction or separate transactions?

Answer 1

No, your scheduled actions will not each get a transaction to themselves. They are likely to be grouped together with each other, with other scheduled actions from different runs of the same process, or both.

From Transactions and Scheduled Actions:

Scheduled actions aren’t performed independently. They’re batched in one transaction with other actions that are scheduled to execute at the same time, have the same process version ID, and are executed by the same user ID. This behavior can cause you to exceed your Apex governor limits if the batch’s actions execute DML operations or SOQL queries.

Emphasis mine. You'll have to break out of the shared transaction in another way, perhaps by moving into Apex to take advantage of Queueables.

Alternately, it's possible that you may be able to use a single scheduled action calling a Flow that uses multiple Wait elements to break the DML of the entire >10k record set into multiple transactions. Flow resumes are also batched, like scheduled actions, but because you can store state and resume, you wouldn't have to run the Flows in parallel and thereby risk having them resume in the same transaction. You could break the DML operations over however many Wait elements needed to assure yourself that the risk of multiple independent Flows resuming in a shared transaction wouldn't threaten limits.

I can't say that I've ever built a Flow to deal with that data volume myself, though, and I feel going to Queueable where you have complete transaction control is a much safer approach.

Answer 2

A transaction starts when an action starts, be it a top-level Apex method is called, an API endpoint is called, an asynchronous code block starts, etc, and does not end until the top-level request is completed, either rolled back or committed, and a debug log is generated. This means that your idea won't work, as any number of actions that may fire in process builder are all in a single transaction. As mentioned above, though, if you call a Scheduled Action, that will be in a separate transaction, since it does not execute within the current transaction. By the way, you can always test to see if something is one transaction or several by using the Developer Console. If you only see one debug log, your action was a single transaction, and if you see multiple logs, then multiple transactions occurred.