ReadyXRM

Recently a customer emailed me and wondered why the “Language” field was missing from the Lead forms in Dynamics 365 (CRM).

As we all know, a “Language” field does not come out of the box with D365.

Note: A language option (lookup) does appear with the recent Portals 8.2 update.

It turned out that a previous employee had added a custom language field on the Account entity, but not Lead (or Contact).

My customer then asked me to add the fields to Lead and Contact and make them mandatory, and if a Lead was converted to a Contact/Account to make sure the Language value copied over as well.

It would be pretty easy to go into the Dynamics 365 customizations and create a language option set field in lead, contact and account entities.  A few clicks, a spinning icon and boom, done.

Not so fast.

This is a pretty simple request, but it’s one of those situations where a little extra thought and planning should be considered to make sure the solution works well but is also a bit “future proof”.

• The customer needed English and French as options.  However, in the future they may want to add more.
• There might be a possibility that we want to incorporate the language to in some sort of future integration or code.
• We might need the language field added to other entities.
• The language field data may be needed to copy to other related entities.

The first step is to create a Global language option set.  This will make the option set available across all the entities and allow us in the future to add new values in one spot only.  This will also make the mapping between entities much cleaner and accurate.  This may seem like a no-brainer but I still see a lot of entity-specific option sets created where a global option set would make much more sense.

Option sets have both a label and a value.  The value defaults to number to corresponds to the solution.  However, in situations like these I prefer to align option sets to standard values or enumurated types.  The benefit is that when writing plug-in code, we don’t necessarily have to have a mapping between an option set and an enumurated type.  I found the Technet article on language ids and used those values instead for my option set.

https://technet.microsoft.com/en-us/library/cc287874(v=office.12).aspx

Not to say we are going to use this option set in a plug-in, but if we ever did, it might save some development time and the programmer might thank us for it!  Note that Dyn365 will pop up a message about deviating from the solution numbering.  I think aligning to the enumerated or other standard values is a better approach.

A side note, this is a situation where you might be tempted to create an “Other” option for those edge cases.  DON’T DO IT!  I have seen many cases where an option set is created with various options only to result in 98% of all the records end up with the “Other” option.  If you have a record where an “other” would apply, then either leave it blank or find out what that “Other” should be an add it to the option set.

Once the global option set is created, we can then added to the appropriate entities and place on forms, views, etc.

We want to make sure that when a Lead is converted to an Account or Contact, that the value in the Lead language is copied over as well.  This is where we make sure that we setup our mappings in our relationships.  I wrote a blog posting outling entity field mappings that explains how and why mappings work.

Now the language field is added to the Dynamics 365 system.  When the Lead is converted to an Account or Contact, the appropriate language field is updated.  If we need to write some code and need to determine or set a language code, that is available to us.  If we need to add a new language to the list, that can be added in one spot.

Summary

Dynamics 365/CRM is a powerful platform where you can quickly add fields and attributes to enhance your business.  Its actually almost too easy.  That being said, no matter how simple the configuration, its always good practice to make a plan and consider the options.  Personally, there have been a few times that I had to back track a bit some “easy” configurations because of lack of thinking things through.

Hope this advice helps!

Cheers
Nick