Why you should use CRM recommended values for optionsets

Sometimes when I'm on a project I encounter CRM consultants determined to use less obscure values for their optionsets than the CRM recommended for your publisher. I.e. 1, 2, 3, 4... You might think this won't cause massive headaches, but I will give you 3 pretty big reasons why I recommend you shouldn't do this.

Conflicting solutions

The most obvious reason is another company also wants to use the same values as you. This will go unnoticed in custom fields, but as soon as you both customise the values of an out of the box optionset, like accountcategorycode, you'll quickly run into problems. Let me show you what happens. In the following example I set up a couple of new options on accountcategorycode and changed the value of "New Option 1" to 3. I have left "New Option 2" as it's recommended value for the purpose of this sample:



Another publisher is also using these same values rather than the recommended in a managed solution. What you end up with is an overwrite on the options with the shared values:



As you might notice our option "New Option 1" has been renamed to "Other 1". This might not seem detrimental in this particular example, but what if the change was from "Bad Debt Customer" to "Most Awesome Customer" or something to that effect. This should be enough to prevent people from doing this, but unfortunately it's usually swept under the carpet as a really unlikely scenario.

Status Codes

The next issue is inconsistent usage introduced due to fields like status code. You may not realise this when you embark on your adventure to ignore the CRM recommended values, but you cannot apply this standard to all option sets, in particular status codes:



CRM disables the value field so you're stuck with what it recommends and you've got an inconsistent standard. So should you just make an exception to use recommended values for status codes, but continue on your own standard for other fields? Or do you extend this exception to all out of the box fields? There are few things I hate more than inconsistency in naming and value conventions so I say just stick with the CRM recommended for all fields.

Annoying message boxes

The next big reason you shouldn't do this is it becomes incredibly frustrating to add new options to an optionset if you want to maintain this standard. Even more so when you're adding a lot of new options. You will get bombarded with a message like the following every time you change the number for an option:



Ultimately why not just stick with the CRM recommended. I know the values are sometimes unreadable and a pain to copy & paste in javascript / code, but these values are not visible to end users, only to us developers/technical consultants. So the impact of leaving them as the recommended values is relatively minimal.

CRM 2016 - Synchronous Workflow bug

Today I spent quite some time working on a bug in one of our workflows which ended up being a bug within CRM. The error I was getting was

The given key was not present in the dictionary.

Let me show you how to recreate and how to spot that this is infact an issue within CRM as opposed to your code.

In our CRM we have a concept of an Attendee which is how we link people to a meeting. We also have the concept of a Target entity which is a parent of an Attendee. The lookup to Target on Attendee is not mandatory as some attendees are just regular people (i.e. not linked to a "Target"). When an Attendee is linked to a meeting I want to check a target has been set and and if it is do some "stuff" based on Target information. So I create a workflow with just this check in it:



For now I am not going to add anything else as this is all I need to highlight the bug. Next, as with a lot of systems, we have bad data and not all Targets have a name. For example:



I run my workflow in its current state against this record and I get an error

:

Downloading the log file gives you a trace like this:

[Microsoft.Crm.ObjectModel: Microsoft.Crm.Extensibility.InternalOperationPlugin]
[46f6cf4c-14ae-4f1e-98a1-eae99a37e95c: ExecuteWorkflowWithInputArguments]
Starting sync workflow 'CG - workflow with bug', Id: e717769d-8c1e-e611-80f4-5065f38aa981
Entering ConditionStep1_step: Check Attendee.Target contains data
Sync workflow 'CG - workflow with bug' terminated with error 'The given key was not present in the dictionary.'

I'm not sure what the CRM workflows code is doing under the hood here, but it must be trying to reference the name field in code. If you set a value for Name on the Target the problem goes away.

Pro tip: Put comments in your workflows! They are included as part of the trace

Automapper, Dynamics CRM and excluding fields - Part 2

In my previous post, Automapper, Dynamics CRM and excluding fields, I introduced a concept of an "Excludable property". This is just 1 side of the call - POSTing/PUTtting records using a REST API. What about a GET? If you are using something like excludables you'll notice that the JSON returned does not look like the proposed JSON you POST or PUT. In fact, it looks something like this:

{
    Id:
    {
        Include: true,
        Value: "aef7b4c1-98f6-4f53-9be3-2fa72d1e319d"
    },
    Name:
    {
        Include: true,
        Value: "Hello"
    },
    Address1_Line1:
    {
        Include: true,
        Value: "Home!"
    }
}

Which is how our Excludables map to JSON. Here do we stop this?

Extend the IExcludable interface

To convert our excludables correctly we need to intercept the conversion and handle these properties manually. The first problem we hit is although we know it's an Excludable<> we don't know what the raw type is. The best way around this is to expand the IExcludable interface to allow exposing of a raw value, like this:

    public interface IExcludable

    {

        bool Include { get; set; }

        object RawValue { get; set; }

    }

The Excludable<> class just implements it on top of the existing value field, like this:

        public object RawValue

        {

            get

            {

                return value;

            }

            set { this.value = (T) value; }

        }

View Model Json Converter

Now that we can find the raw value without needing to know the underlying generic type we can intercept any excludable and convert it. This is the full converter class that results:

public class ViewModelJsonConverter : JsonConverter

    {

        public override bool CanRead => false;

        public override void WriteJson(JsonWriter writer, object value, JsonSerializer serializer)

        {

            JObject o = JObject.Parse(JsonConvert.SerializeObject(value, Formatting.Indented,

                new JsonSerializerSettings {ReferenceLoopHandling = ReferenceLoopHandling.Ignore}));

            foreach (var propertyInfo in value.GetType().GetProperties())

            {

                if (propertyInfo.CanRead)

                {

                    var currentValue = propertyInfo.GetValue(value);

                    IExcludable excludable = currentValue as IExcludable;

                    if (excludable != null)

                    {

                        if (excludable.Include)

                        {

                            if (excludable.RawValue == null || excludable.RawValue.GetType().IsValueType || excludable.RawValue.GetType().Name == "String")

                            {

                                o.Property(propertyInfo.Name).Value = new JValue(excludable.RawValue);

                            }

                            else

                            {

                                o.Property(propertyInfo.Name).Value = JObject.FromObject(excludable.RawValue);

                            }

                        }

                        else

                        {

                            o.Remove(propertyInfo.Name);

                        }

                    }

                }

            }

            o.WriteTo(writer);

        }

        public override bool CanConvert(Type objectType)

        {

            if (objectType.BaseType == typeof (ViewModel))

            {

                return true;

            }

            return false;

        }

        public override object ReadJson(JsonReader reader, Type objectType, object existingValue, JsonSerializer serializer)

        {

            throw new System.NotImplementedException();

        }

    }

In the above code our view models code had inherited a ViewModel class. Also worth pointing out is how you handle the both value and object types (with strings needing an extra helping hand as they're a bit different!). For value types and strings you need to create a JValue where as for reference types you need to expose them as a JObject.

Now, just add this converter like so in your global.asax exactly how you added your excludable converter from the previous post:

GlobalConfiguration.Configuration.AddJsonConverter(new ViewModelJsonConverter());

This code effectively flattens the excludable class into the generic types and outside of the world of your REST api nobody is any the wiser.