I’ve seen more than a few CRM systems where option sets were used in places it didn’t make sense. I’ve also seen dramatic over use of custom entities where an option set would have made perfect sense. Typically when these decisions are made early on they carry a consequence that is generally not felt until later when the solution is deployed into production. In general I prefer to go with an option set over custom entities if I can because it’s less overhead to maintain. Over time I’ve come up with some general guidelines for helping to determine if something should be an option set or a custom entity.
By asking the following questions it should be more clear as to which directly you should pursue:
- Are the values fairly static?
- i.e. They don’t change very often if ever
- Is there only one value needed for the code itself?
- Not having multiple fields related to the option
- Are there currently and will there probably always be less than 10 to 20 options?
- Is the code table autonomous?
- Meaning it doesn’t have a parent child or hierarchical relationship with another code table
- Are the codes fairly self-describing
- i.e. I can look at the code and know what it means without an extended description
The trouble with performing this analysis in real life is that you’ll find yourself in scenarios where something you are observing may pass some but not all of the above criteria. This is when you have to start looking at the pros and cons of custom entities. My general best practice is that I will look for excuses to use option sets when possible and fall back to custom entities if it’s too hard for me to justify.
There is a system and maintenance overhead to consider when creating custom entities. On the extreme side you could create everything as custom entities and then you may find yourself running into the total entity limit within CRM. For CRM online you are limited at 300 entities by default. This can be increased by creating a support ticket to have the setting changed for your organization, but it’s generally a bad thing if you are hitting this limit. In general it typically is a sign of poor system modeling. I generally call this kitchen sink CRM, as in you are trying to make CRM do everything because it can be made to do so. But I digress…
The other thing you have to consider with options set design is whether to create an entity option set or a global option set. An entity option set is only available for a specific entity whereas a global option set provides a common set of options that can be used by multiple entities. So for example, let’s say I have a car entity and a truck entity. If I want to create an option set for number of wheels, then that applies to more than one entity so I would create this as a global option set and then I can use that template for both entities. This allows for management of that option set in one place in the system. If on the other hand I have a bed length in feet option set then that may only apply to the Truck entity since cars don’t usually have a bed in the back. In that case I may decide to use an entity option set.
In general if there is a doubt about if an option set might be applicable to multiple entities then you should go ahead and create a global option set. Some people only create global option sets as a general practice, but I prefer to create entity option sets when it clearly makes sense that it only belongs to a specific object. Worst case scenario you can take steps to move an entity option set and create it as a global option set so it’s not like your decision is carved in stone.
