A core use of any CRM, including Salesforce, is to improve the way data is inputted, structured, and presented to users – picklists are definitely the simplest way to check these boxes. Even in the most simple Salesforce org, there will be at least one custom field that you, as an admin, created to support a particular business or even a technical need.
In this post, we’ll explain exactly what Salesforce picklists are, while providing some helpful tips for making use of them in your company’s instance.
What is a Salesforce Picklist?
Simply put, picklists represent a predefined list of values for users to choose from when inputting data into a field. Reminiscent of the way data in a cell can be validated from an array of values in Excel, picklists will please reporting teams, users, and admins alike.
To adapt the example above, what if I like both cats and dogs? Regardless of whether the user should choose one or multiple values, this type of field is going to ensure that data is consistent. It may also be used in future automations developed later to sustain existing processes.
Bad Value for Restricted Picklist Field
I’m sure that I’m not the only one who has encountered, on more than one occasion, numerous import errors with this title. This may be the result of an extra letter for a value, or mistakenly pasting some other value.
Standard Picklists
When it comes to out-of-the-box functionality, Salesforce provides a few standard objects, such as Accounts, Opportunities, or Leads. Naturally, these objects come with some fields that are deemed to be useful for most organizations. These fields include picklists.
A perfect example is the Lead Status. As a standard field, values cannot be restricted to a certain list. While you can define your own list of values according to the qualification process your Sales Development team is following, any user with API access (as well as edit permissions on the field) can push new values – intentionally or by mistake.
These extra values will not be available to choose from in the user interface unless they are activated. In fact, they will only be found under “Inactive Values”, or when running reports and noticing them on records.
Another notable example of a widely used standard picklist is the Lead Source, which is carried over to Account, Contacts, and Opportunities upon lead conversion. As this may be considered an important field for revenue attribution, some organizations might opt for more granular control of their custom fields, rather than using the out-of-the-box options.
An alternative could be enforcing a validation rule – however, when there are a lot of values available, this can prove hard to maintain.
Note: Make sure that access to such standard fields is well controlled, especially when it comes to third-party integrations.
Custom Picklists
Picklist fields created by admins for use cases specific to a particular Salesforce instance, represent a better way to control the values and ultimately, data quality on the records too.
These fields allow admins to restrict the possible values to predefined ones. This is where the “bad value for restricted picklist field” error comes into play if a value is not on the list. One little checkbox can make a huge difference!
Even more so, if the same values are to be used on fields from multiple objects, there is always the option to create a global value set. This will ensure all picklists (this is used on) will be permanently in sync. How cool is that?
Picklists and Record Types
I’m sure this has happened to all of us more than once; we have all forgotten about this dependency, especially when creating new values.
While they are an extra component to deploy when making changes to picklist values, Record Types have proved to be a useful asset when tailoring the user experience for objects that have them enabled.
The picklist we have just added values for, Level, has a different meaning for the Sales and Support teams – obviously, the drop-down options need to adapt. Also, as this is a custom field, and we like clean and controlled values, it is restricted.
Remember my favourite error mentioned above? That’s right – if the value of a restricted picklist is not added to a certain Record Type, it will not be available to be either chosen from the interface or imported. This results in our old friend, the “bad value” error. In this scenario, adding “Tertiary” as a Level for a record whose type is Sales, won’t be an option.
Controlling and Dependent Picklists
Looking back at our list of cute animals, what if there are more details we’d like to collect about the pet? Let’s say that we want to capture the breed (for dogs) and the color (for alpacas).
On top of having the extra fields available, the field dependencies need to be created accordingly, and values selected where it’s the case.
Once this part is done, along with the necessary permissions and layout changes, it will be reflected to users in the interface.
Note: Multi-select picklists can only be dependent fields.
Summary
Be it simple, multi-select, or a combination with dependencies included, the picklist is here to stay. Picklists may be used merely as report filters or they may become pillars of your processes; either way, mastering them within Salesforce will not only save both you and your users time, it will also make entering data a much more pleasant experience.
If you assimilate the information better while doing hands-on work, Trailhead is the place for you! Salesforce has provided numerous Trailhead modules, which explore various field types including picklists – Picklist Administration is a good place to start.
Furthermore, it’s worth exploring the Data Management module as well, as a refresher is always welcome!
