Now I will let you in on a finding I did the other day. It is all about a very tiny detail but still, it might be good to be aware of this fact. As usual when you find something suspect in Dynamics 365 CE you cannot really be sure if the behaviour is classified as a bug or by design. I registered a Microsoft case this time just to find out.
Microsoft was able to reproduce the behaviour in their environment, without a session where I went through it all, yay! Now I am waiting for the product team to investigate whether it should be classified as a bug or by design. I will do an update here when I have the answer.
Update 8th of September 2019:
Microsoft classified this behaviour as a bug and earlier this week they confirmed that a fix has been deployed in version 1710 (18.104.22.16828) online. I have verified this and ValueRules now work for both UCI and the Classic UI if you use the keywords “true” and “false”. According to Microsoft “1” and “0” still works on UCI but not in the Classic UI. That is ok with me, we are all moving to the UCI anyway.
When designing solutions using Dynamics 365 CE sometimes you need to modify commands or the Ribbon, e.g. to modify the logic behind commands/buttons, hide commands/buttons depending on some logic, create new commands/buttons etc. To our help we can use the handy tool Ribbon Work Bench, which can be used from the excellent XRMToolBox. Or we update the RibbonDiffXml area of the customization.xml manually.
For instance, you might want to hide a button until the user has filled in certain information or done certain actions. Then you can have a checkbox which is checked automatically when all necessary information is filled in or the actions, whatever it might be, have been made. You can configure the command/ribbon button to be displayed only when your checkbox is checked, by using a ValueRule.
The not wanted behaviour of ValueRule
Now what was it with ValueRule that was so suspect? Well, I found that the configuration for using a Two Option field (which on a form can be configured as a checkbox) in a ValueRule differs in the Classic UI compared to the Unified Interface. I noticed this after some research trying to figure out why our button did not show up in the Unified Interface but it was displayed in the Classic UI using the same record.
The below two pictures illustrates what works in the Classic UI vs. in the Unified Interface. The Two Options field has the name prefix_my_checkbox. Pay attention to what is specified as Value.
For those of you who are used to working in the Ribbon Workbench, the Enable Rule which works in the Classic UI looks like below. As for now you will need to change Value to 1 instead of true in order for the EnableRule to work in the Unified Interface.
It also causes that you need to change the customer modification in order for it to function properly when moving from the Classic UI to the Unified Interface. Time consuming and not the ideal behaviour with other words.
Classic UI expects true/false as Value in a ValueRule for Two Option fields and the Unified Interface expects 1/0. Not ideal as already pointed out. Let us hope that Microsoft will consider this as something that should be fixed.
To me it seams like a good idea to let the Unified Interface be OK with either true/false or 1/0. Then the customer modifications made for the Classic UI would work properly also in the Unified Interface and the customer modifications made directly in the Unified Interface (not updated from Classic UI I mean) would work as well.
Will we get a fix from Microsoft? Fingers crossed!
3 thoughts on “ValueRule in Classic UI vs. Unified Interface”
What if try to use orrule combining 2 rules you mentioned?
LikeLiked by 1 person
Looks like ORRule breaks in App(Unified Interface).
Tested this on following version of D365.
2020 release wave 1 enabled
Server version: 9.1.0000.15048
Client version: 1.4.299-2003.1
LikeLiked by 1 person
Good to know! Well done with your tests. Did you report it to Microsoft? I am sure they want to know. 🙂