Feature Request: Add ability to raise exception in flow action

[isidle]

When a record triggered flow runs an fault path, the execution continues instead of raising an exception & rolling back database changes.

This is particularly problematic for record triggered flows, as everything could end up in an incomplete state.

Add an optional boolean to the attributes and when true, call an exception passing the value of faultmessage.
Otherwise would need to create a separate invokable action in order to raise the exception and unwind the transaction.

[jongpie]

@isidle thanks for adding this idea! I think it'd be fairly easy to add this functionality into the Flow invocable methods - I'll do some additional analysis this week to see if there are any issues, but I'm hopeful that this will be a fairly easy enhancement to make.

[JeroenSfdc]

That would be a nice addition, as today I always configure an 'Exception Thrower' invocable class in my fault branch for that purpose. It the fault could be thrown by the Nebula invocable that would be less clutter.

[JMercie]

@jongpie I was investigating how to implement this, and I have a rough idea of how to make it available for the log methods in flow, but I think there's a challenge setting the Savepoint to do a rollback from Apex.

Rollback the entire set of transactions in Flow is also difficult with the standard rollback records flow component because this one will only roll back the latest pending transactions, not the ones already executed.

If you know how to do the rollback in the DB, I can help implement this!

[isidle]

Calling an exception throw new exception('something failed'); is all you need to have database unwind changes in synchronous transactions.

The only time you'd need a savepoint is if they were running both synchronous and asynchronous logic and wanting to unwind to the very start of everything but at that point the onus is on the dev to handle that as there is no way for nebula to know which transaction they wanted to roll back to.
IMO this is a very rare edge case, while 99% of the time stuff is being done in just one or the other.

[jongpie]

@JMercie sorry for the late response! If you're still interested in contributing, I'd be happy to review any code changes you make. If not, no worries, I can work on this sometime in the coming weeks.

And I agree with @isidle - just throwing an exception (after saving any pending log entries, using Logger.saveLog(Logger.SaveMethod.EVENT_BUS) should work - the exception will rollback the current transaction, without needing to use SavePoint.

[jongpie]

@isidle and @JeroenSfdc, I've just finished publishing the new release that includes this functionality - it's now available in v4.11.1. Thanks again to @JMercie for implementing this!