7

Is there any strategy for implementing global lookup lists (universal pick lists) ?

There is a long standing request (for 7 years) for this, and it is something that I am used to having in Dynamics CRM.

Is there some other way it can be done? i.e. through a web service call?

3

The best I can think of is using a custom object to hold all of the picklist values. Your other objects would use filtered lookups, but you are limited to how many active lookup filters you can use, on a per-object basis.

| improve this answer | |
  • Yes, this is also something that can be done with Dynamics CRM. The main issue with this approach is that if you have a lot of global picklists then you will need a new custom object with relations for each one. If it is just a few picklists then it is workable. – user12646 Dec 15 '14 at 21:10
  • You can do one custom object for all of them, as long as you can filter them by a type field. – Mike Chale Dec 15 '14 at 23:34
  • 1
    But this will complicate some tasks, such as default values and record type filters, but also relaxes other limits, such as the maximum number of pick list values pretty field. – sfdcfox Dec 16 '14 at 2:15
1

In case you are still looking for something, it appears this is now in pilot in the winter 16 release!

Share Picklists Across Objects and Fields with Global Picklists (Pilot)

Efficiently reuse a single list of values for multiple custom picklist fields. Global picklists make it easy to share picklists across objects by letting you create picklist fields based on a master list of values. And, they keep your picklist data clean by preventing users from adding erroneous or redundant values through the API. This feature is available in both Lightning Experience and Salesforce Classic.

Update: still pilot but now also available in dev orgs and sandboxes by default in Spring 16.

| improve this answer | |
0

Create a custom setting with all your pick list values n use a lookup from wherever u need.

| improve this answer | |
  • Creating as a custom setting has limited use in the standard UI usual best practise is to use a custom object which can be accessible in code as well as in the standard UI. – Francis Dec 15 '14 at 15:08
  • @Francis A list custom setting seems like an obvious choice here and can certainly be accessed in code. What exactly makes using a custom object better? – Keith C Dec 15 '14 at 22:43
  • @francis would like to understand further from you. – human Dec 17 '14 at 14:34
  • Yes custom settings can be used if they are exclusively going to be used in code but the question was "universal picklists". IE How would an admin then create a field on an object that has the picklist values stored "centrally" in a custom setting? The only way to achieve a centralised list that could support both the declarative and code worlds would be to hold it as an object and use lookup relationship fields. Ok multi-select picklists are different kettle of fish. But even objects are not ideal but better, even siebel has something similar to MSDynamics but looks like SF is working on it. – Francis Dec 17 '14 at 16:24
-2

@andrew there is a new app called Universal Picklists that might help solve your problem. You can manage picklists across multiple objects from one location. Hope this helps.

https://appexchange.salesforce.com/listingDetail?listingId=a0N30000000pvmXEAQ

| improve this answer | |
  • Hi, without sharing some personal experiences or explaining how this app solves the issue this is purely seen by advertising, which may be cause for deletion or downvotes. You can still update your answer to include more info if you'd like. – Samuel De Rycke Apr 21 '15 at 17:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy