Note: Though this is still of use in extreme cases, the limit on multi-select picklist values has been raised to 500 values in Winter '16.
Also, the Global Picklists feature, which is currently (Summer '16) in Beta, also helps with the problem as stated (though it also has the 500-value limit).
I have several fields in my org that require picklists with many values. Examples of values include countries, langauges, NAICS codes and the like.
Multiselect picklists are limited to 150 choices, but the universe of these lists is significantly higher (over 200 countries, many many languages and NAICS codes).
I want picklists because they establish the standardized values which makes searching and aggregate reporting easier. I specifically want multiselect picklists, because accounts can use many languages or have operations in many countries.
One common feature of all of these fields (aside from the massive number of options) is that the choices are universal. That is, whenever we refer to countries, we can have the same countries. Whenever we refer to languages, we can use the same set of languages.
Disclaimer: For the moment, please disregard the fact that States + Countries is a feature we can use. Although that gives us a list of countries, it does not let us easily use those values in custom fields. Also, I want a solution that will work for languages and other non-country fields, too.
My ideal answer:
- Uses standard Salesforce visual idioms.
- Doesn't require anyone to learn anything outside of the ordinary for this field.
- Allows power admins as much "normal" Salesforce power as possible (permissions, layouts, option maintenance, workflow rules, etc.).
- Allows for reporting similar to reporting on traditional multiselects.
- Is easy to maintain.
What is the best way to solve this problem?
Best Answer
Currently there will be no solution without tradeoffs. In most cases I tend to pick approaches which provides good UX and best convenience for the users.
To get something user friendly multiselect picklists doesn't come close. They give me a feeling of the year 2003, more than a few choices end up in scrolling tapestries and selecting+deselecting feels like crap. Fiddeling through 200+ fields will be a task for which the users are not likely to fall in love with you.
From the perspective of the datamodel standard (multiselect) picklists lead often to not normalized structures. Take the countries or languages for instance: it's likely you'll need them on multiple entities and you end up declaring them redundantly again and again with the challenge keeping them in sync. Dataquality r.i.p.
Actually fromthe UI perspective one of the better examples for a nice multiple picklist is the selection of tags here at SFSE:
To get this on a SF layout you need some kind of javascript. There are many to choose from. If you like jquery have a look on this
To keep the datamodel clean and normalized I strongly agree with @DanielHoechst to use custom objects. Expose an editable list page e.g. for language-choices only for admins. Reuse them everywhere. Add and maintain languages on a single place. Alternatively you can use Custom Settings instead. The overall implementation pattern will be roughly the same.
To fetch the choices you could use JS remoting
https://www.salesforce.com/us/developer/docs/pages/Content/pages_js_remoting_example.htm
To store the selected values on the object I would use a text(255) if possible (easier reporting but need for overrun protection plus limits) or you go for a longtext(128000) if necessary. Since the JavaScript is doing the aggregation, there is no need for a trigger.
Now how to get this most conveniently on the layout? And how on edit? This in the end is at the moment the hardest part. To get the custom JS integrated the solution to embed a VF page rules out: a separate save button is clearly not nice.
If you want to be a good citizen you end up in overriding the entire view and edit with vf-pages. apex:detail helps a bit to reuse layouts. But even that's quite radical, it's still best practice. From the admin perspective unfortunately not perfect.
If you're not afraid to get your hands dirty have a look at this
End of javascript sidebar workarounds? - eventually this would provide a solution to wire it nicely into the standard view and edit without VF override - but it likely won't last forever.
For the future all my hope is on Aura Components to get it done right.
Finally reporting is still an issue. But also is with standard multiple picklists. So having a text field with delimiters is not too bad either.