Picklists: Data or Metadata


On the CRM Product Team we have had long and recurring debates about picklists; the issue that always seems to pop-up is whether picklists are data or metadata; the invariable answer after hours of talk? They are BOTH.


Why is the above relevant? Well, because it has drastic implications in the way things get stored and exposed; metadata is translatable (at least that is the way we treat metadata in CRM). As many of you know, CRM 4.0 supports multiple languages hence all the items that we consider metadata are translatable; picklist is one of the instances in which the line blurs (there are others but I won’t get to them here). The decision that was made in CRM 4.0 and that will probably stick in future versions is that picklist shall support multiple labels for the same value and depending on the users language the right label will be displayed… for example a picklist can logically be expressed as follow (e.g. this is not our storage schema):
























Value


English label


Spanish Label


French Label


1


Red


Rojo


Rouge


2


Green


Verde


Vert


3


Blue


Azul


Bleu


 


Multiple labels in different languages might be irrelevant for some companies (e.g. all their operations and employees operate on the same language) but are vital for multilingual ones.


So, if labels are so important why don’t we just enable everything and allow all entities’ attributes to have multiple labels?  That way we could even get rid of picklists completely and always use entities (which are more flexible, support multiple attributes instead of just an int value, etc)…Right?    Well… doing that would have a massive impact on storage and querying performance.  In CRM 4.0 we were extremely careful to cache metadata as much as possible to speed things up and that includes caching things like picklists (which, even on the most extreme cases that I’ve seen, they never reach more than 1500 items), imagine attempting to do the same with an entity with thousands and thousands of records…not wise and most likely unnecessary for transactional data (e.g. A person’s name is most likely the same whether the user interface is in English or French).


At the end of the day picklists are a complex data type with characteristics of both, data and metadata and hence they need their own hybrid approach (which is what we did in CRM 4.0).  Now the conundrum for developers is: When to use a picklist vs. an entity?  Well, the answer is…depends, and that by itself requires its own blog post which I’ll probably do shortly J


Comments (2)
  1. Jake Horn says:

    You are right they are both.  I tend to like the implementation that actually stores the string data in the field.  For instance, when you want to remove a picklist option, but not change the historical one.  

    I would also like to see picklist be more metadata.  A picklist is a type that could be standard across entities.

Comments are closed.

Skip to main content