Hey Diego ;)

Yes, this is a classic concurrency issue, and the silent failure is a tell-tale sign of database locking. Your microflows are likely competing for the same resources.

Here’s what's probably happening and how you can debug and fix it.

When a microflow performs a Commit action, it tells the database, "I'm changing this data, so lock these rows until I'm done to prevent anyone else from making a mess."

If your two microflows run at the same time and one of them tries to read or change data that the other one has already locked, the second microflow is forced to wait. If it waits for too long (exceeding a timeout), it may simply give up and terminate. This often happens silently because it's not a "crash" or an "error" in the traditional sense; the process is just aborted by the system.

Think of it like two people trying to edit the same file in a shared folder. The first person to open it locks it. The second person gets a "file in use" message and has to wait. If they get tired of waiting, they just close the dialog and walk away.

Hope it helps ;)

Thank you for the detailed answer.

I have a follow-up question regarding parallel scheduled events: since these processes run in the background without a user interface, we cannot use traditional dialog boxes for delays.

What would be the recommended approach to intentionally delay one scheduled event when we detect that another is already running? Specifically, are there best practices for implementing a programmatic wait or retry mechanism in this scenario?

I know we have an option below but I mean when we have two different scheduled events.

Your guidance would be greatly appreciated.