While it is best practice not to perform server actions at all in a nanoflow, the reality is that some server actions are required, and indeed they are supported. It then becomes a matter of finding the right balance. This is also where the option to call a microflow comes in, as it allows you to make one call to the server, which then performs a variety of server actions. This is better then having all the individual server actions in your nanoflow because each server action in a nanoflow is a separate call to the server.
In the above answer, I've already alluded to the answer to this question but let me elaborate. Each microflow runs in something called a transaction. Any changes to your data will either be committed to the database at the end of the microflow or will be rolled back and essentially disappear if your microflow runs into errors. Since nanoflows do not run on the server, each server interaction runs in it's own transaction and is therefore committed to the database once the action completes, regardless of whether the nanoflow has completed or not.
Let me show you a simple example:
If this is executed as a microflow, you would either get an order with an orderline per product in your shoppingcart, or nothing.
If however you execute this as a nanoflow, it would depend on when your flow runs into an error. If it would be at the third product, you would have one order and two order lines.
I hope this helps you understand the difference. Feel free to ask any additional questions.
Thanks for the answer.
I understand the difference between a Microflow and Nanoflow in the way their transactions work, but my questions was really about how their transactions work when they are combined?
For instance: what would happen if the microflow in your example screenshot was executed as a SUB-Microflow from within a Nanoflow? Would this SUB-Microflow still adhere to its original transaction principles, or would this now suddenly be changed because the calling flow is a Nanoflow? :)