Mismatching Option Set Values on Imported Views in Dynamics CRM

Miguel Nepomuceno, 30 September 2017

When deploying customisations from a development environment to a testing environment in Microsoft Dynamics CRM 2016, I encountered an issue with imported views in my solution components. The view was on the Connections entity for a custom entity called Portal User. This custom entity is just something which other entities can connect to. The view for the Connections entity contains the filter field “Type (To) Equals Portal User”. Type (To) is an out-of-the-box option set field on a Connection record that states what the entity type of the ‘Connected To’ record is.

 
The error indicates that the option list value no longer exists in the imported test system. Checking the FetchXML for this custom view in the test environment indicates that the condition value does not contain anything.

I’ve inspected the working custom view in the development environment. The ‘Equals’ condition with the Type (To) option set field requires a specific option set value to filter the records.

I’ve made a quick test on choosing the same filter conditions on a new blank Advanced Find view in the Connections entity (this is in the test environment where my imported custom view failed). Inspecting the FetchXML below, it appears that the option set value of Portal User for the environment is different to what I was expecting from the custom view.

This error could be a nuisance especially when a lot of customization components depend on this custom view e.g. sub-grids, dashboards. This error can either happen where option value does not exist in the system being imported to or the wrong option set record gets inputted (e.g. CRM has already assigned a different entity to that option set value). This can commonly occur during imports to different environments or in data migrations where entity GUIDs are maintained or changed throughout the different environments.

It all depends on how each environment is set up. In our case, the test environment setup has the Portal User option set with a different option set value compared to the development environment. Since the ‘Equals’ condition requires option set values to match, it would trigger an error into the custom view as the condition with the given option set value does not exist.

You can obviously manually change the custom view filter every time in the new environment. But it would be a hassle as it would need to be redone every time we deploy the solution. This could also mean inconsistencies between two different environments which we do not want.

A work around to this could be changing the filter attribute to ‘Contains’ or ‘Begins With’. This way we can avoid this issue with imported views into different environments regardless of what option set values are set in the different environments. Here is an example of using ‘Begins With’ in the custom view. The custom view filter now looks for a string in the option set display name as opposed to an exact matching option set value.