The road from Classic Workflows to Flows has been a long one. Microsoft has been committed to bringing parity to Flow when compared to Classic Workflows. We are almost there but this is only half the story because there is so much more you can do with Flows compared to Classic Workflows. Transaction support is one of those features that Synchronous Workflows inherently supported because they ran inside the execution pipeline, but Asynchronous Workflows left you to tidy up manually if something went wrong halfway through a run. This often led to using Actions to perform specific actions inside a transaction, but wouldn't it be cool if we didn't need to do this? Read on!
Note: Even though the product that was formally known as Microsoft Flow is now called Power Automate, Flows are still called Flows!
So what's a transaction?
At the risk of teaching you to suck eggs, Transactions simply put are a way of executing multiple operations, where if one fails, they all 'roll back' as if they never happened. The 'changeset' of operations is said to be 'atomic' which means that until the transaction is 'committed', no one else can see the records that are created/updated/deleted inside the transaction scope.
Imagine a scenario, where a system needs to transfer a booking from one flight to another where both flights are in very high demand:
- ✅ The system cancels the customers current booking
- ❌ The system books the new flight, but this fails because the flight is now full
- ❌ The system tries to re-book the previous canceled flight, but someone has already taken the seat
- 😢 The customer is left with NO flight
What about a different order of events where the system goes offline halfway through:
- ✅ The system books the new flight
- ❌ The system cancels the previous flight, but this fails because the system is unavailable
- ❌ The system tries to cancel the flight just booked in step 1 because the customer now has two flights, this fails because the system is unavailable
- 😱 The customer now has TWO flights!
In both of these situations, without transaction support, we are left having to perform complex 'manual transaction compensation'. The topic of transactions is fairly complex, and there are lots of other topics such as locking and distributed systems, but simply put, transactions make database consistency easier to manage!
How do Flows now support CDS transactions?
Transactions are called 'changesets' in a Flow. This is a feature that was announced as part of the Wave 2 changes - and it's just landed!
To use changesets, you will need to be using the CDS Current Environment Connector: