The answer to this question can be found here: Clustered Mendix Runtime | Mendix Documentation
It basically states that your desired option is not available for clustered deployments.
In addition, whilst the the "Disallow Concurrent Execution" toggle on microflows can be useful, I personally find them to be less reliable than queuing microflows through taskqueues due to a couple of factors:
- Queues, when specified for one process per cluster, will ensure that processing of activities always occurs sequentially directly after each other for a list of activities without needing a scheduled event that has a minimum frequency of one minute;
- Error-handling in microflows that have their "Disallow Concurrent Execution" setting activitated and are executed from a client-action is tricky, since you are limited to two options: message or microflow, with the latter being limited in its functionality and being prone to throwing generic error messages (see: https://community.mendix.com/link/space/microflows/questions/132718);
There are some disadvantages though:
- You will still need a scheduled event if you want to control the order in which event messages are added to the task queue, since you will only want to queue a new eventMessage from the scheduled event if the queue is empty;
- You will need to handle the asynchronousity of the task queue in your user interface, if showing output immediately after completion is a requirement. Consider the microflow timer widget or the new push notification support for PWA's as a possible solution for this.
Hopefully this will help you in making your decision.