Another thing that is even more strange.
I made another field this the EXACT SAME conditions but with a new id that is not known as an input on vRO side :
And it works like it should following the exact same protocol (always failed for the cpu field) :
So having a field ID that is a vRO expected input breaks the correct update of the default value oO ?
No updates on this? We have the same issue… and still found no workaround this. :-(
In the meantime, we updated to 7.5 and discussed with VMware R&D team to get a better understanding about what could be done.
The present status is that it is a known limitation of the "legacy" Xaas solution engine that is not planned to be fixed.
Official workaround is to move on "Custom Form" instead, but that other option is *quite* bumpy on 7.5 :-)
default values are only determined at form build time and never again; this applies to XaaS and vRO presentation bindings.
My advice to you is do not use XaaS form designer; only use it when you cannot control it from vRO presentation (read only value, left/right box and checkbox display, certain bindable properties [e.g., subtenant group name]).
In your case you will want to use the Data Binding presentation field in vRO. If your case is as simple as you describe make it #environment == 'PRD' ? 8 : 4. If you will need to work with more values then create an action that has the logic you need and set the presentation to your action (e.g., GetAction('your.action.path').call(#environment)).