How to Deploy Standard Field Picklist Values in Salesforce
7 min
Robust customer data is critical to any company’s success, especially in today’s competitive market. Most use a solid Customer Relationship Management system like Salesforce to administer and automate their client information and processes. Organizations using Salesforce quickly learn that the platform comes out of the box with plenty of standard objects like Lead, Accounts, Opportunities, and Cases to get users up to speed quickly with the most common CRM applications.
These objects come with a pre-loaded set of fields to make life easy during onboarding. Fields like Phone Number, Email, and First Name come with the Contact Object, while Case Number and Subject comes with the Case Object. Standard (and Custom) fields can be in many format – text fields, phone numbers, currency, checkboxes, etc. One incredibly useful field type is the Picklist. By using a finite set of values, picklists keep the data clean and easily reportable (versus a text field that incurs the risk of spelling and pluralization issues complicating the data). Some of the standard fields provided by Salesforce come in the Picklist format, including a set of preloaded values for the field. This article will discuss Picklist fields, especially those for standard fields in Salesforce.
Picklist Field – Similarities between Standard and Custom Picklist Fields
First, it’s good to understand what you can and can’t do with a picklist in general, and how standard picklists provided by Salesforce may differ from custom picklist fields that an administrator creates. First, let’s focus on the similarities:
Labels – while the Field API and Name can’t be changed on a standard picklist, the Field Label that users will see can be customized
Validation Rules – standard and custom picklists can both use validation rules
Field Dependencies – when it comes to Field Dependencies, one picklist is the controlling picklist and the other is the dependent picklist. The value of the controlling field determines which options are available for the dependent field. Standard picklists can be the controlling picklist but not the dependent one.
Values – this is the area where standard picklists are most similar to the custom version. Admins can add new values, reorder values and select a default option for the picklist. More on the default value below. Standard picklists also have the replace function and can use chart colors.
Inactive Values – just like custom, standard picklists have the option to retain inactive picklist values. This is useful when you want to de-clutter the list of choices, but aren’t ready to fully delete it.
Admin Fields – other administrative fields like Help Text, Description, and Field Usage work in the normal manner.
Picklist Fields – Differences between Standard and Custom Picklist Fields
Field Name and API – as mentioned above standard picklist fields come with an established name and API that cannot be modified.
Required – custom fields have the option to set as Required or not on the field level. Some standard picklist fields are required (such as Opportunity’s Stage field) and admins cannot remove this requirement. For other standard picklist fields that are not required by default, admins can make them required on a page layout or through a validation rule.
Default Value – a standard picklist enables the administrator to select a value from the list as a default. However, custom picklists also have an option to use a formula to determine a Default Value. This is not available for standard picklists.
Restrict Picklist to the Values Defined in the Value Set – for custom picklists, this checkbox determines if users can select something other than a value from the list provided. By default standard picklists only allow values from the value set.
Controlling Field – as mentioned above, picklists can be used together in a way that one picklist displays values dependent on the other (controlling) picklist. A standard picklist can be the controlling of a custom (dependent) picklist, but not the other way around.
Advanced Features
Picklists can be used in used for a few additional advanced features where the standard picklist behaves differently from custom versions.
Promote to Global Value Set – when making a custom picklist, the set of values may be useful in other areas. Perhaps the same set of values could be used on another picklist within the same object, or a corresponding field on another object. For example, an admin may want to add a custom picklist to the Lead object called “Zodiac Signs” that has a picklist of the different horoscope symbols. If converted, those values should carry over to the Contact object. Fortunately, the admin can make the picklist once, promote it to a global value set, and then use it again for the field on the other object. Unfortunately the values selected in a standard picklist field cannot be promoted to a global value set.
Standard Picklist (left) with reduced option compared to Custom Picklist (right)
Change Field Type – custom picklists can be changed to other field types like multi-select picklists, checkboxes, and text fields. Standard picklists cannot be converted to any other field type.
Common Standard Picklists
There are several standard picklist values out of the box with a new org. Let’s cover a few of the most commonly used:
Account and Lead Picklist Fields
Since Leads and Accounts work closely together, with many Lead fields mapping directly to Account fields, these picklists are often the same.
Account Source (API = AccountSource) + Lead Source (API = LeadSource)– one of the most fundamental picklists for any Sales and Marketing organization. This goes hand and hand with Lead Source. In fact, Lead Source automatically maps to Account Source upon lead conversion. Use this field to segment where your business comes from.
Industry (API = Industry) – categorizes the account by industry sector. Prepackaged list is already lengthy, but can be added or reduced to fit your organizational needs. This is useful when looking at opportunity results by account industry.
Ownership (API = Ownership) – refers to whether an account is publicly owned, private, subsidiary, or other.
Rating (API = Rating) – used to designate the quality of the Account with values like Hot, Warm, and Cold.
Type (API = Type) – identifies what type of account it is, such as Customer, Partner, Prospect, etc. Since organizations differ, this is one that is very difficult to make universal. The values they provide are a great starting point, but this is a good area to customize.
Opportunity Picklist Fields
Forecast Category (API = ForecastCategoryName) – used in conjunction with Stage to categorize each opportunity for forecasting purposes.
Stage (API = StageName) – this required picklist on the Opportunity objects is critical to much of the built-in functionality surround this object. Early stages include Qualification or Needs Analysis and continue throughout the sales process with stages like Negotiation, In Progress, and Close Won or Closed Lost. This feeds into forecasts and is fundamental to reviewing the sales process to determine where things are going right and where things are going wrong. In addition to adjusting the name, this picklist also has special features like Probability (set from 0-100%) and Forecast Category (i.e. Pipeline, Commit, etc).
Type (API = Type) – not to be confused with Account Type, this refers to new or existing business.
Case Picklist Fields
Case Reason (API = Reason) – Salesforce provides a list of reasons, although this is really just a starting point. Your own customer service team will have a set of values that capture the most common case reasons.
Case Origin (API = Origin) – starting simple, we have Email, Phone, and Web as choices.
Priority (API = Priority) – very simple – High, Medium, and Low. Like any standard picklist, we can add more options. This is useful for case escalations and assignments.
Status (API = Status) – Cases can run through various stages just like Opportunities. Also like Opportunities, the various statuses also can be designated as “Closed”. If a status is not “Closed” it will be “Open” for reporting purposes.
Type (API = Type) – like Opportunity and Account, the Case object has a Type picklist. Case Type can be items like “Problem” or “Question”.
Task Picklist Fields
Priority (API = Priority) – like Cases, Tasks have Priorities like High and Normal.
Status (API = Status) – this one is simple . . . just Open and Completed.
Type (API = Type) – just like the other objects, Task has a standard picklist for Type. Standard values include Call and Meeting, for example.
There are many other standard picklists on objects like Campaigns, Products, and Work Orders, too. Understanding these standard picklist fields will help leverage the platform’s key features and maintain data in an organized and easily reportable format.
