Here are a few guidelines to help you determine whether it is appropriate to use a picklist or custom object to capture data:
Picklist:
- Values are static or nearly static
- Values can be maintained by an administrator
- All selectable values are displayed at once (drop down menu)
- The total number of values is relatively low (I’d suggest a maximum of 100, but the actual limits are much higher)
- You want to use controlling and dependent picklists (see “Field Usage & Field Types” in Fields) — this can be done to some extent with lookup filters (see Lookup Filters) and a little bit of creativity, but the net result isn’t quite the same
- The picklist value does not have any other associated data (e.g. the lead’s favorite brand is Dell; no other information about Dell is needed)
- Values are captured in web-to-lead submissions (web-to-lead does not support custom relationship fields).
- You want to capture multiple values without creating multiple records (e.g. the lead’s favorite brands are X, Y,Z; use a multi-select picklist instead of a many to many relationship)
Values do not need to be validated via the API (there is an AppExchange workaround to this, which I have not personally used)- Now available with “Restrict picklist to the values defined in the value set.” field option
Custom Object:
- Values change frequently
- Values can be added/changed by users
- Selectable values can be searched for by users (lookup dialog box)
- The total number of values is high
- The value has associated data (e.g. the lead’s favorite brand is Dell; Dell’s address is X)
- You want to use delegated administration (see Delegated Administration) on your custom object
Values need to be validated via the API (useful for integrations)- Now available with “Strictly enforce picklist values” option
Values in this list are used in multiple references (e.g. the lead’s favorite brand is Dell; a marketing campaign is sponsored by Dell as well)- Now available with “Restrict picklist to the values defined in the value set.” field option
Examples:
Scenario 1
The marketing team wants to track the venue where certain marketing events (such as trade shows) are held. Marketing users will add and maintain the list of venues, as well as other information (such as phone, address, etc. of each venue).
Create a custom object “Venue”, with fields to track phone, address, etc. Create a lookup relationship from campaign to the Venue object.
Create a lookup relationship called “Venue” from Campaign to Account. Instruct marketing to create accounts to track venues. Add a picklist value ‘Venue’ to account type (or optionally, create a record type for a ‘Venue’ account).
A picklist is not suited to this scenario, as the values will change frequently, the values are maintained by users, and other information is captured for the venue (e.g. phone, address).
Scenario 2
The marketing team wants to track an additional layer of information related to lead source. For instance, if the lead source is ‘Web’, then the lead could have originated from one of 3 websites. Likewise, if the lead source is ‘Print’, then the lead could have originated from one of 4 print media publications. The list of websites and publications changes very infrequently.
Create a custom field ‘Lead Sub-Source’ on lead, and make this field a dependent picklist of the ‘Lead Source’ field.
This solution does not account for lead conversion, which will be discussed later in the guide.
John: I think this section would be more helpful with a refresh, incorporating many of the comments, examples, and explanations into the main. Reading through these was really valuable to me. Also, as a “nit” (but important to those like me who aren’t ‘database types’, is this fundamentally a discussion of “picklist objects” vs. “Custom Objects”, where picklist is a “special type” of custom object. If so, I would retitle the section “Picklist Object vs Custom Object…if this is not true, then please explain the actual relationship…still a bit confused here…..
A picklist is a field, where as an object is a table with a lookup field to reference that table. Yes- a lot of this is database mechanics, which is you are new to will increase the learning curve a bit.
why are we comparing a field requirement with an object requirement? A few more examples would help.
Thanks for the feedback- it could be a standard or custom object depending on the scenario. I’ll to update the examples.
Hi John,
Scenario 1
I am not able to see the records in the campaign object from the Venu lookup field. Please advise.
Thanks
If the lookup is from campaign to venue, you should see the fields on the venue object (as that is the object you are “looking up” to)
see Field Usage & Field Types – when I click link, following message is displayed: ” This page has been deprecated. Please see Fields for this material.
Updated
John, are there scenarios where you would want to create picklists on a custom object (instead of one vs. the other)?
Yes – there are two examples in the article above…
Hi John,
First of all thanks for your amazing website, really helpful!
Could you please clarify a point for me : What does it mean ” Data need to be validated trough the API”. I am not very comfortable with the API functionality and why data needs to be validated etc. Could you briefly explain me this? Thanks a lot for your help
Let’s say you’re loading data in the Color__c picklist field, with options:
Red
White
Blue
If I create a new record manually via the web, I will get the options listed above.
However, if I load data using the data loader (via the API), I can set any value I want (even though there are only 3 ‘valid’ options). So I could load data into the system with the value ‘Green’ for example.
This is a good list. In my opinion a crucially defining option to add under Custom Object would be if the data list needs to be reusable (by other objects) without having to be duplicated. Using a picklist means that the list is specific to that object and would need to be duplicated to be used elsewhere..
Yeah – that’s a really great point. I’ll add that.
we could use global picklist in this case instead of going for object, isn’t it.
Yep – I will add that in
“Create a lookup relationship from campaign to the Venue object.” Doe this mean that the Campaign is the parent and the venue the child in the lookup relationship, or vice versa? It’s easier if I understood does “lookup” infer one is looking up to the other, so your working from campaign to the Venue means the campaign is the child or does it mean, you can research it easily or look it up on the object? i.e. that’s how we end up with the related list of one on the other object?
”
‘
When you create a lookup or master/detail relationship, the field is created on one object and targets another object. The object where the field is captured is where the data is input, while the target object is where the related list is displayed.
For example, the field “Venue” is created on the campaign that references the venue object. When you create a campaign, you input which venue the campaign is related to; likewise, when you go to view that venue you will get the related list of all of the associated campaigns. Hope that helps-
Good summary answer – thanks!
Tell me if these statements are correct:
A Lookup has to be an object in Salesforce. For example, you can look up an Opportunity to relate it to an Activity.
A picklist contains a list of value. The value exist only in the picklist and are not objects in Salesforce.
Question: Is the object where the lookup field is location always/sometimes a related list on the object that you are looking up to?
Correct- although you wouldn’t lookup to an activity. You could create a lookup from a case to an opportunity (if a case is in reference to a specific deal).
Yes, the other end of the relationship can be shown through a related list (e.g. the opportunity in the example above would have a list of related cases).
what if the list of websites and publications changes frequently? Object solution would still be impossible here right?
If the list of sites changed frequently, then you might want to consider using an object to capture the list of options. E.g. a picklist for lead source “website”, then a lookup field to a custom object to capture the specific website. Add an “active” checkbox to the custom object with a filtered lookup (to only allow selection of an active website/publication) for bonus points.
and the filtered lookup object should be read only for users so that only administrators/delegated amins can enter the new records?if we allow everyone to enter new related record for list associated then users might not bother to search on existing record for lookup object.
Yup something along those lines
Hi,
What if the The list of websites and publications changes frequently ? there is no option to implement it with objects still right?
That gets trickier- primarily due to web to lead. You might end up with a hybrid solution, where the publication is captured as a text field (and code on the website performs the validation). You’d have to dig into the details a bit more in that scenario.
typo in Scenario 1: “where certain marketing event” …should be events.
thank you, updated
Hey John, the link to Delegated Salesforce Administration is now dead.
Thank you, updated!
Grammar problem with opening line for this section
Here are a few guidelines to help you determine whether to is a picklist or custom object is appropriate:
Thanks Trevor, updated.