The visual lanague of microflows is ubiquitous in a Mendix project, but all microflows are not created equal.
In particular, although it is techncially possible to implement a given microflow in many areas of the app, in practice that sometimes does not make sense. For example, there is probably no case where a microflow that handles a REST service call can reasonably be reused as an event handler, even though both of those features are configured with a microflow.
My suggestion here is to extend “flow differentiation” that currently exists as the trifecta of microflows, nanoflows, and rules. The additional flow types would be the different microflow use cases that never “cross over”; an approximate list follows:
Like microflows, nanoflows, and rules, these additional flow types would share a common visual modeling language. Unlike microflows, nanoflow, and rules, these additional flow types may not result in or justify differentiated execution mechanisms – the runtime will still execute these new items like a microflow. On the other hand, this explicit differentiation may create opportunities for optimization.
This extended differentiation would promote a better understanding of the development features of the application, and the organization of projects as they grow larger. In particular, explicilty different flow types would simplify naming conventions, as you’d no longer need prefixes like ACo, ASU, etc.
Of course, you’d need a new icon for each new flow type.