function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Iceman123Iceman123 

Sharing dependent picklists across different objects

Hi there,

 

I am trying to figure out the right design for a business requirement.

 

Requirement:

- To be able to maintain/configure a dependent picklists to be used/shared across different objects (standard or custom). 

 

Use Case:

- We are using Salesforce to track product bugs (custom object) and customer cases (standard Case object).  We currently have product and version picklists defined for both Product Bug and Case objects, where the version picklist is dependent on the product selected.  These picklists in the Product Bug and Case objects have identical values and dependency.  So we are essentially duplicating the same functionality in both.

- We would like to be able to have a single place to maintain the values of these picklists so that an admin will not have to make the same change to both objects.

 

What are the different options available to implement this?  

- Is it better to use Custom Settings to store mappings for each selection and then handle the dependency effect using Visualforce's rendering capability (ie. without actually using the dependent picklist feature)?

- Or do we create inputFields on the Product Bug page bringing back the dependent picklists for the Case object, but in the get/set methods, set the values selected against the Case object inputFields to the corresponding/identical fields in the Product Bug object (ie. just use the Case object to populate the values (no save) for the UI but update the identical Product Bug fields in the backend)?

 

Any guidance is appreciated :)

 

thanks!

~P

sfdcfoxsfdcfox

If you go the custom settings route, you'll have to roll your own dependency logic. It's not terribly bad, actually, but I hate duplicating effort that should already be available. Take a look at one of my prior posts on dynamic lists to see the relative effort involved:

 

http://forums.sforce.com/t5/forums/forumtopicprintpage/board-id/Visualforce/message-id/34206/print-single-message/true/page/1

 

Of course, you'll query the Custom Setting instead of an object, but that's the precise same logic. You'll probably want to write a custom VF page to manage the dependencies, though; I would hate to see someone do this by hand via imports or manual edits... although once inputted, it wouldn't be so bad to maintain necessarily. The custom settings route avoids the 300 item limit for controlling fields, if that's a potential future concern, although Custom Settings can only hold 10mb worth of data, so that might also be a concern.

 

Personally, I'd probably some sort of small Java applet or script to automatically copy one set of metadata to the other; that would be trivially less work in terms of overriding pages and so on.