If you read my last post, you know all the reason why I dislike using the checkbox. And after that whole rant, you may be thinking what could be worse than the checkbox? If you’re a seasoned admin, you already know the answer. The dreaded multi-select picklist.
Now I’ll be honest, at first, I thought these were the greatest fields. They can hold a lot of data, reducing the number of fields on a page. Logically, they make sense to use when categorizing information such as the modules a customer purchases or languages spoken by a contact. The problems come when you start wanting to do more.
To start with, reporting on a multi-select picklist is a nightmare. Trying to write a filter that includes a multi-select picklist is frustrating at best, and more often much worse. Good luck trying to sort by them, or heaven forbid you want to make a chart plotting counts of each of the values. Instead of splitting the count, you end up with variations of every possible combination and your chart is completely meaningless.
It only gets worse when you try to use a multi-select picklist in a formula field. Unlike a standard picklist, you can’t use the magic of TEXT() to convert the value in the field to a text string, so you are severely limited by the functions that you can use. One of my favorite tricks is copying values from parent records & displaying them on a child record. This is almost impossible with a multi-select picklist field. I say almost, because you can actually do it, it just isn’t glamorous. (Check out SteveMo’s answer here to see how.)
Unlike checkboxes though, I don’t have an elegant solution for the problem of multi-select picklists. Instead, I try to limit their use as much as possible. I also try to limit the number of values in the field to reduce the number of permutations that would appear on a report.
How do you deal with issues presented by the various field types? Do you have fields types that you try to avoid?