ValueRule in Classic UI vs. Unified Interface

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 (9.1.0.8028) 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.

Background information

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.

As already mentioned, you have the possibility to put some logic for when a certain button should be displayed or not. Then you setup Enable Rules. You can create custom rules and call a function in a JavaScript library or you can use one of the built-in rules. One example of a built-in rule is ValueRule, which you can use to check the value of a specific field on the record.

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.

This behaviour causes that a customer who has this kind of modification cannot utilize it in both interfaces at the same time, i.e. the button will not function properly in one of the UIs. You could always use a custom rule instead, writing JavaScript, but since there is something called ValueRule, we should be able to utilize it properly.

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.

Conclusion

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!