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:
- supports typing and auto complete
- perfect usage of screen real estate
- comfortable handling
- quite common and intuitive
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.
As Keith C and HomerJ said you can write something like this. Hope this helps.
trigger UpdateOpportunity on Opportunity (before insert, before update){
for(Opportunity opp :Trigger.new){
// MultiSelect Fields are a single String with values delimited by a semi-colon
// DeliveryInstallationStatus__c is a Picklist (Multi-Select)
String[] deliveryArray = opp.DeliveryInstallationStatus__c.split(';');
if(deliveryArray.size()>0){
// Write your logic here
}
}
}
Best Answer
The following picklist limits can not be changed. Why do you need this?
I guess it is possible to create such multipicklist in custom VF page and keep its values in Rich text on object.