In Microsoft Dynamics CRM 2011 and above, you have two options when creating an Optionset field (also referred to a dropdown box or picklist). You can create a “local” field, which is only available to one entity, or you can create a “global” field, which can be reused on any entity. Here’s how to decide if you should work with Local or Global Optionsets.

When to Use a Global Optionset

It’s hard to argue against the use of a Global Optionset! When creating a custom dropdown field, there’s virtually no extra overhead required to create it globally. If there’s any possibility at all it might be reused on another entity, you’re covered if and when the need arises. When creating an Optionset, ask yourself: “Is there any reason this might ever possibly be reused on another entity?” Unless that answer is a resounding “Definitely not,” you might as well create a Global Optionset. You can still control the all the field properties per each entity form, such as making it required/recommended/optional or applying business rules in CRM 2013. Most of the time, there’s no downside to global creation.

But read on for the few, specific situations to go local!

When to Use a Local Optionset

When you’re modifying an out-of-the-box Optionset, odds are it’s already a Local Optionset. In these cases, you should probably keep it local. It’s more trouble than it’s worth to forgo the OOB Local Optionset and create a new Global Optionset from scratch, especially when cross-entity mappings are involved. I do not recommend drastically modifying the nature of any OOB field, Optionsets included… If you find yourself doing that, create a custom field instead, please! Avoid the headache that comes with all the OOB field dependencies.

Another time to use a Local Optionset is when you want some different values to be options on one entity, but not another. If you create a single Global Optionset for this, you might end up using JScript to restrict the list appropriately, which adds overhead and maintenance. You’re better off creating two Local Optionsets and mapping the fields appropriately (if necessary). You could create two Global Optionsets, but the field names can get confusing if you have a bunch of similar ones intended for different entities–so again you’re probably better off going local in that case.

Finally, if you’re customizing as a part of a portable Solution, you may want to consider sticking to Local Optionsets. If you create Global Optionsets, they can be reused on other forms after the solution is installed, and cause dependency issues preventing your solution from being truly portable. This especially applies if you’re creating a Managed Solution, since users won’t be able to mess with your Global Optionsets, anyway. If you’ve upgraded from CRM 2011 to 2013, you may have run into this issue in one of your Solutions, requiring you to reinstall a Solution instead of directly upgrading. Prevent this frustration by going all local in your Managed Solutions.

Any suggestions or tips I missed? Comment on this post and weigh in!

Like this post? Share it!