This pattern will help you decide the way to implement Picklist. It can be designed in many ways and the implementation depends on the characteristics and the level of maintainability you are looking for.

---

Implementation Considerations

Before going straight to the creation of the field, you should ask yourself some questions:

• Is the completeness of values guaranteed ?
• How many values will be in the list ?
• Is multiple values selection allowed ?
• Is there any dependency between picklist value and another field ?
• How often values are updated in the picklist ?
• Who can modify those values ?
• Is the list dedicated to one unique object or shareable between field/object ?
• Is there any picklist master data in another system ?

Implementation Criteria

Picklist	– Exhaustive list – Only one selection at a time – At least 2 values in the list – Restricted values, no dynamic add – Restrict the number of values for maintenance and visibility in layout – Dedicated to one field on one SObject and not shareable – Dependency with checkbox or picklist – Need deployment – Linked to process and automation
Multi Picklist	– Same as Picklist – Multi selection allowed
Global Picklist	– Same as Picklist – To be shared between many fields on one or many SObjects – Restricted Picklist and restricted Multi Picklist can be promoted
Text Field	– Do not match any picklist criteria – Non exhaustive list – Unknown list – The value depend on current record and not on a referential
Dedicated SObject	– Non exhaustive list – List can grow – List is criteria based (activation, date …) – Initial load & updates with external tooling, integrated system – List can be managed by a non admin or developer – Master data in external system
Checkbox	– Binary choice – true/false or yes/no

Codification

When you create a Picklist, you are asked to enter a list of values. These values are then copied into “Label” and “Api Name”. A codification pattern should be applied for API name, you must avoid phrases, special characters etc … as these values will be used in Apex, Process Builder, Validation Rules, Integration purpose … Also, the label should be in English, you can use the translation workbench to adjust what will be displayed for your users. Codification can be numeric or alpha numeric, in uppercase, words can be separated by underscore.

Value	Codification example
Hot, Cold	HOT, COLD
3 months, 12 months	3M, 12M or 3_MONTHS, 12_MONTHS
France, Portugal	FR, PT
I’m a developer, I’m a teacher	DEV, TEACHER

You get the point, more the codification is clear and mirror well the value more it will be maintainable and usable in your development. You can also use codification like 01,02 or 001, 002 or C01, B12 etc… but they are not intelligible and imply to check the correspondence. So use them if you do not have any alternatives.

Use Case 1 : Picklist

You are asked to create a field to hold 3 custom steps for your opportunity process that will be complementary to the default StageName. These 3 values will be used to fire actions from automation.

	Criteria used to evaluate the implementation
1	The list is exhaustive and restricted
2	Each value can trigger specific actions
3	Value has to be created and deployed by developer
4	The list is dedicated to this object only

More evaluation criteria can be set, but already we have enough inputs to correctly choose the picklist implementation.

Use Case 2 : Multi Picklist

You are asked to create a field to hold 3 custom categories for your opportunity products. These 3 values will be used to fire actions from automation and user is able to select many categories for one product.

	Criteria used to evaluate the implementation
1	The list is exhaustive and restricted
2	Multi selection is allowed
3	Value has to be created and deployed by developer
4	Automation can be fired based on the combination of categories

Here the main point is that we need multi select available.

Use Case 3: Global Picklist

You are asked now to create custom steps for opportunity products in order to trigger a change in opportunity custom steps when all opportunity products have moved to final steps.

	Criteria used to evaluate the implementation
1	The picklist values is the same between Opportunity and Opportunity Products
2	Sync and automation is needed between both field
3	The field usage is the same
4	The opportunity picklist can be promoted as global picklist
5	The opportunity product picklist can be created as picklist using the newly created global value set

Here the main point is that we need to sync 2 fields.

Use Case 4: Text Field

You are asked to migrate data from External System to Salesforce, to map old codes to new codes in target SObject, but we still need to keep old codes for history, sanity, cross check purpose. There can be a lot of values, not necessarily consistent, not following good patterns.

	Criteria used to evaluate the implementation
1	Huge number of inconsistent values
2	External system codes
3	Not used in processes, not displayed to users
4	Historical data

Here the main point is that we want to store historical data from an external system.

Use Case 5: Dedicated SObject

You are asked to build a pricing category for opportunity products that will be available for only few months and will change often. The category hold some information specific to the season and that will have an impact on pricing.

	Criteria used to evaluate the implementation
1	The pricing category will be updated at the start of each season
2	It will not be possible to select an outdated pricing category for new opportunity product
3	Data will be loaded by external system, admin
4	Old pricing category will remain as they are linked to old opportunity product
5	Pricing Category attributes will be used in automation

In this case, we will create a lookup attribute instead of picklist in the opportunity product. The name of the record can match a part of the value that could have been put on picklist. Additionally, a picklist can be created in this dedicated SObject to represent the unique category value even if there are many records, so that automation can be based on a known restricted value.

Use Case 6: Checkbox

You are asked to get the client consent on Contact level for some options. The only choice available for each option is yes or no.

	Criteria used to evaluate the implementation
1	Binary choice
2	Yes/No or True/False

Here we want to capture consent option by option, we could have design with picklist but checkbox is a better approach in this situation.

Conclusion

You are now able to decide or even put in place your own decision criteria to go through the right implementation pattern. Don’t forget to ask a lot of questions to your business, if you don’t have an overview of the major criteria, your implementation could reach its limits and moving to another solution is not that easy and have lot of constraints.

Hope you enjoy reading this article, see you soon for the next one ...