Best practice for triggering microflows based on input selection changes (On Change vs context constraints) Description

0
Hi everyone, I’m working on a Mendix app where user selections in input widgets (such as reference selectors or dropdowns) need to trigger microflows and update related data dynamically. I understand that On Change events can be used to trigger microflows when a value changes, and that context objects (Data view / associations) can also be used to constrain and refresh data automatically. My questions are: In which scenarios is it better to rely on On Change microflows versus using context + associations to drive behavior? Are there performance or maintainability considerations when triggering microflows frequently from input widgets? What are the recommended best practices to avoid unnecessary microflow executions while keeping the UI responsive? I’d appreciate insights from real-world projects or Mendix-recommended patterns. Thanks in advance!
asked
2 answers
0

The first question depends more on how you build your page up. I can not come up with scenario's which might be better. 

The second question: try to use nanoflows as much as possible. And on change flows are often not that big so you would not have performance problems unless multiple thousends of users are all on a same page and trigger that microflow. 

Third question I do not understand. On change flows will only trigger when there is an actual change so imho then necessary otherwise you would not have build them. 

Regards,

Ronald

 

answered
0

On Change microflows are useful when something needs to happen immediately after a value changes. Typical examples are setting default values, doing simple validations, or running logic that cannot be handled with associations alone. If one change should affect multiple fields, keeping that logic in an On Change microflow can be clear and straightforward.

 

Using context and associations works better for more data-driven behavior. For example, showing related records based on a selected value, filtering lists, or refreshing data automatically when the context object changes. In these cases, relying on the page structure instead of custom logic usually keeps things simpler and easier to maintain.

 

From a performance point of view, triggering On Change microflows too often can cause issues. If a microflow runs database queries, commits, or other heavy logic on every change, the page can feel slow. Having many On Change microflows on a page can also make it harder to understand where certain behavior is coming from.

 

A good approach is to use On Change only when it really adds value. For text inputs, it’s often better to trigger logic when the user leaves the field or clicks an explicit “Apply” or “Search” button. Whenever possible, try to solve things with context and associations first, and add microflows only when you truly need extra logic. This keeps the UI responsive and the overall design easier to follow.

answered