Last day, I ran into a very common “create new record” scenario in Mendix. There was a New button on the page, and clicking it triggered a Create Object + Open Page action. The user would fill in the form, click Save, and everything seemed fine at first. After some time, though, I started noticing odd behavior, where certain records appeared to be created twice, almost as if the object ID was duplicated.
The tricky part was that the object was being created directly in the button action. Because of this, I couldn’t really debug what was happening. There was no microflow where I could place breakpoints and see how often the create logic was being triggered. On top of that, when I used Find Usages to check where this entity was created, these button-based create actions were easy to overlook. The create logic was basically hidden inside the UI.
My expert colleague and I then rebuilt the same flow using a microflow instead. The button simply called the microflow, and inside it I handled everything in one place: checking if a draft already existed, creating a new object only when necessary, setting default values, and finally opening the page with that object. With this setup, the issue completely disappeared. I could debug the flow properly, add logging, and clearly see that the object was created only once.
After this experience, my view on best practices became much clearer. Create Object + Open Page isn’t wrong and can be fine for very simple cases, but in real-world apps it can quickly become risky. When object creation lives in the UI, you lose visibility and debuggability, Find Usages becomes less reliable, and edge cases like double clicks or commit events can cause unexpected behavior. Moving object creation into a microflow keeps the logic centralized, visible, and much easier to control and extend later with validations, permissions, draft handling, or unique checks. For anything beyond a very basic scenario, creating objects through a microflow just feels like the safer and more scalable approach.