The attributes in Product Configurator form are case sensitive. This is very annoying and dangerous.

Steps to reproduce:

a. Open any D365FO Contoso environment

b. Go to [Product information management / Products / Product configuration models]

c. Select model 'Car Audio System'

d. Click button [Test]

e. Enter value 'coupe'

f. You will get the following warning: 'The value coupe is not included in the type for attribute Car type'

The vast majority of D365FO application is case insensitive. For example, it's allowed to enter customer/vendor/items/etc numbers where upper/lower cases will not matter. The Product Configurator form seems to be an exception. This is NOT consistent with the rest of the application.

Furthermore, this is NOT consistent with the behavior of AX 2012. In this version, modifying an attribute if causing the x++ code to go through PCRuntimeInputController.modifiedHandler and getValueAsString methods. Then eventually PCRuntimeEnumDomain.getSolverValue will be responsible to grad the value with correct casing and send it back to form control.

We have some customers (planning to migrate from AX 2012 R3 to D365FO in a near future like 2026) where the Product Configurator module is currently being heavily used. In one of them, they have a team of about 27 employees each one of them using the configurator more than 100 times a day. In bigger models, users needs to feed almost 60 attributes. The current average number of configured lines is 7 per hour for quotations and 12 per hour for sales orders. It's longer for sales because more attributes could be required to manage product options and specifications. Or on-the-fly custom engineering could cause higher complexity.

If users are forced to enter values using lookup list ; or if they need to fix casing for values with incorrect upper/lower characters, then this is going to have a SIGNIFIANT NEGATIVE impact over data entry performances. There is a risk to add delay (many hours or even days) to production schedule if entry time increases during configuration process.

There is something worse and very dangerous (as tested in application version 10.0.44). When an attribute value is rejected because of wrong casing, it's possible to close the configurator form anyway. In this situation, the previous/last good know value for this attribute will be considered. Leading to the creation of a product variant with UNEXPECTED or INCORRECT bom and/or route. This is so easy to made a mistake that we are expecting a SIGNIFIANT INCREASE in complains because of finished products being NOT exactly what was ordered.

The PCRuntimeControl class (or corresponding JS resource) should be able to auto-correct upper/lower casing issues.

If this is not possible, then the failed attribute should have a little yellow warning icon ; and it should NOT be allowed to click OK to close the configurator form.