5

We have clients that use a lot of codes in their day to day activity.

Eg: Take a look at the UK Government Common Basic Dataset: https://www.gov.uk/government/publications/common-basic-data-set-cbds-database

In this there are "codesets" corresponding to what might initially appear to be picklist or multiselect options.

At data entry point the data might be coded (Eg 'H0038' identifies 'St. Martins College'. But in Salesforce I'd like to show the user what this code actually corresponded to. The user might also want to see the code, just for a confirmation feeling.

So what would be a good mechanism to bind code values to string descriptor values, so the user can interact with both?

Dependent picklists with one to one matching?

A brand new object (eg 'Institution__c') with records reflecting each of the possible values?

A Custom setting?

Improve this question

2 Answers 2

Reset to default
3

You can always use custom objects to form a code/friendly-name pairing. Just make a lookup field to the custom object, and configure it to allow searching/filtering by both name and a custom field, and you'll have an intuitive edit mode. Follow this up with the lookup field hover feature, and they can hover over the code in a detail view to see the related information. This might not always be useful, but this is an out-of-the-box solution where you don't need to write any code at all (configuration only!), and gives you additional reporting/viewing capabilities as well.

Improve this answer
4
  • I like this idea, and in a limit free world it would be ideal. But a rough eyeball over the excel sheet suggests about 170 custom objects would be required. Pretty sure this would be eye watering for all but the biggest Orgs.
    – powlo
    May 1, 2015 at 14:18
  • 1
    True. Anything less than EE wouldn't work, and EE would use about 85% of its limits. A shame, really, since custom objects are so handy.
    – sfdcfox
    May 1, 2015 at 15:22
  • I assume if it was all packaged as a Salesforce approved app/package then these limits (200 custom objects for EE) would not apply. Is that the case?
    – powlo
    May 1, 2015 at 16:26
  • 1
    @powlo Yes, if you're an ISV and you get the package made into an aloha app, you'd get to install it even in orgs that can't support 170 custom objects (e.g. professional edition).
    – sfdcfox
    May 1, 2015 at 16:42
1

With a data set this large and the need for it to be responsive, I would recommend using Custom Settings. you can then dynamically populate a picklist with a custom VisualForce page.

Be sure to make the Name field the code value to avoid having duplicates loaded.

Improve this answer
1
  • Ideally I'd like the values to be selectable via standard layouts.
    – powlo
    May 1, 2015 at 14:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .