You could extend the idea by introducing a small helper entity that acts like a lightweight queue controller.

For example, create an entity like TaskQueueHelper with attributes such as QueueNumber, Status (Waiting, Running, Completed), and optionally timestamps like RequestedAt or StartedAt. Every time the microflow needs to run, you first create a new record in this entity with the status Waiting.

Then trigger the Task Queue that processes this record. When the task starts, the microflow first checks if there is already another record with Status = Running for the same process.

If a running record already exists, the task does not execute immediately. Instead, it can either wait for a short time and retry, or simply enqueue itself again to be executed later.

If no running record exists, the task marks its own helper record as Running and then executes the main microflow. Once the process finishes, the record can be updated to Completed (or Failed if something goes wrong).

This way you create a simple application-level queue, where only one execution runs at a time while the others remain in the waiting state until the current execution is finished.

There is no built-in widget or standard Mendix option for this in 9.24.29.

If this could be asynchronous, I would suggest using a Task Queue with a single thread. But since you specifically want one execution at a time, I assume there is a reason you need that behavior in a more controlled or synchronous way.

So in that case, there is no real built-in alternative for a synchronized microflow call.

Instead of maintaining your own custom Java action, you could have a look at the Java actions already available in Community Commons, especially the microflow execution ones. Those are commonly used and generally work well.

If this helps resolve the issue, please close the topic.

Ajay,

If you want to ensure that a microflow can not be executed multiple times concurrently, there is a setting for this in Microflow properties:

Documentation can be found here: https://docs.mendix.com/refguide/microflow/#disallow

Hope that helps,

Mike

Hi,

In Mendix, microflows themselves are not designed to be thread-safe constructs, because the Mendix runtime already manages execution and transaction handling per request/session. There is currently no built-in widget or configuration option in Mendix (including 9.24.x) that allows you to mark a microflow as “thread safe” or automatically execute it within a synchronized block.

If you need strict synchronization across threads (for example when multiple scheduled events, task queue workers, or custom threads could modify the same shared resource), the typical approaches are:

1. Use database-level consistency instead of synchronization
   
2. Often the safest pattern is to rely on database transactions or constraints (unique indexes, version attributes, etc.). Mendix handles transactions per microflow execution, which usually avoids concurrency issues.
3. Use Task Queue configuration
   
4. If the logic runs in background processing, configuring the Task Queue concurrency (for example limiting workers to 1) is a common Mendix-native way to serialize execution without custom synchronization.
5. Use custom Java synchronization when necessary
   
6. If you truly need JVM-level locking (for example protecting a shared in-memory resource), using a Java action with a synchronized block—as you are doing—is the correct and supported approach.

In short, Mendix does not provide a native thread-safety option for microflows. When strict synchronization is required, it must be handled either through database consistency patterns, task queue configuration, or a custom Java action.