I built, some time ago, a very simple scheduled flow that only called an invocable method, calling itself an external virtualization system, to retrieve accounts from it, and to copy them back in Salesforce.
When I ran it, in debug mode (Debug > Run), the flow was failing with a strange « Callout exception » due to pending in-progress work ! (cf picture below)
But when I call (in anonymous action) directly the method called by the action, it works fine !
What happens is that there were some DML operations in progress, when the scheduled flow was fired, meaning that some accounts records were not in a stable saved state.
In this case, you can naturally try to reorganize your code and flows to make sure there will be no element interfering with your DML. But, in case of a refactoring complexity, or short timing, if you ever face this case, to commit the in-progress transactions, you could use :
- a Screen element (on a screen flow)
- or a Pause element (on a scheduled flow) : reaching a Pause element ends the current transaction. When the flow resumes after the pause, the Get Records does not face anymore the « pending uncommitted work » exception.
Eventually, since then, you also now have the possibility to catch errors in flows with error-sensitive Fault Paths. To do so, select the DML-related element, and create the Fault Path from it. You can delete the Fault Path from the same place.
For information, in a screen flow, you could also have a look and decide to leverage a dedicated custom CommitTransaction element (from UnofficialSF : https://unofficialsf.com/use-the-committransaction-action-to-get-more-from-your-flow-limits/)
To read more on the subject :
- Salesforce Help article to set it up the right way : https://help.salesforce.com/s/articleView?id=000385708&type=1
- Trailhead unit on Fault Paths : https://trailhead.salesforce.com/content/learn/modules/flow-implementation-2/handle-flow-errors-with-fault-paths
