Currently you can not call a nanoflow from a microflow. And when calling a microflow from a nanoflow, 1: you cause a roundtrip and 2: this is not possible in OfflineFirst.
The current only solution is to duplicate the microflow so you have one microflow and one nanoflow, but that is bad for maintainability.
Solution would be to have a type of flows in MendixStudio that can run both on front-end and on server.
Technical implementation would be to have Studio add a microflow-property "is also nanoflow" that the developer can set, when needed. And that Studio, upon creating the runtime, will generate a nanoflow too for that particular microflow. (That generated nanoflow need to be not visible in Studio)
Setting this property has to be limited to microflows that do not perform actions that the nanoflow can not do.
Just keep it simple.
Design a “anyflow”, it can only be a subflow. If it’s called from a nanoflow, it behaves like a nanoflow. If it’s called from a microflow, it behaves like a microflow.
I like this idea to avoid duplication of microflows and nanoflows. In addition to offline-first apps, validation microflows would also benefit (often you want to do this both client and server-side, e.g. when both a user and an API can change the same objects)
I guess the microflow in question would be forced to enable entity access as well, to prevent security issues when it is run client-side...
Actually I think it should go a step further.
Instead of the developer having to choose nanoflow or microflow, we should just have "flows" which can run on either client or server as required. Mendix should determine where to run the flow itself, based on what is more efficient and which types of activities are present in the flow