Hi,
Since you already confirmed that:
the enum value exists in the returned B list,
the object is refreshed in client,
and it works when the data source is Static,
then this points much more to a widget behavior/refresh limitation with the microflow data source than to your nanoflow logic.
What is likely happening is that the Combo Box loads the microflow-based options once, keeps its internal selected state, and does not fully re-sync the displayed selection when A.status is changed externally afterward. In other words, the attribute changes, but the widget UI does not rebind correctly to the new value.
A few things are worth trying:
First, if possible, do the update in a microflow instead of a nanoflow and keep Refresh in client = Yes there as well. Sometimes widgets react more reliably after a server roundtrip than after a purely client-side nanoflow update.
Second, force the Combo Box to be rebuilt. The usual way is to place it inside a container or data view that gets refreshed/reloaded after the button click. If the widget is recreated, it has to read A.status again and re-match it against the datasource result.
Third, check whether this is simply a Combo Box widget bug/limitation in v2.7.2 with enum values coming from a microflow datasource. Since Static mode works and your data itself is correct, that is a realistic possibility. In that case, upgrading the widget to a newer version would be worth testing first.
So based on your extra details, I would not focus anymore on whether the enum exists in the list. You already validated that. I would focus on the fact that the widget is not visually re-rendering/rebinding when the value is changed programmatically while using a microflow datasource.
My conclusion would be:
If you want to keep this datasource mode, I would test these in order:
If this resolves your issue, please mark the answer as accepted so it can help others facing the same problem.
Hi,
This behavior is related to how the Combo Box widget handles data when the data source is a microflow.
When the Combo Box uses Data source → Microflow, the widget internally builds a list of selectable options based on the objects returned by that microflow. The selected value is matched against the Value attribute of those returned objects. If the value of the bound attribute (A.status) changes later through another action (for example a button microflow), the Combo Box does not automatically re-evaluate its data source or rebind the selection unless the widget is refreshed.
That is why your Text widget correctly shows the updated enum value, but the Combo Box does not visually update.
To resolve this, you need to refresh the context object in the client after updating the attribute.
In the microflow triggered by the button:
Astatus = <desired enum value>This forces Mendix to re-render the page widgets that depend on the object, including the Combo Box. When the widget rebinds, it matches the enum value with the value field from the objects returned by the microflow and the correct option becomes selected.
Also verify one important condition:
The microflow used as the Combo Box data source must return an object B whose status value matches the enum you are assigning. If that value is not present in the returned list, the Combo Box will not display it even though the attribute changed.
So the correct pattern is:
A.statusThis approach allows you to keep the microflow data source while ensuring the Combo Box UI updates correctly when the value is changed programmatically.
After several tests, I found the following results:
Both Static and Context/Assocition modes worked correctly; only the DataSource mode had an issue.
Ultimately, I decided to change the display method of the combo box to Context/Assocition mode (using non-persistent object).