Configuration, Picklist

[ART-007] Picklist Implementation Pattern


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.

ValueCodification example
Hot, ColdHOT, COLD
3 months, 12 months3M, 12M or 3_MONTHS, 12_MONTHS
France, PortugalFR, PT
I’m a developer, I’m a teacherDEV, 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
1The list is exhaustive and restricted
2Each value can trigger specific actions
3Value has to be created and deployed by developer
4The 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
1The list is exhaustive and restricted
2Multi selection is allowed
3Value has to be created and deployed by developer
4Automation 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
1The picklist values is the same between Opportunity and Opportunity Products
2Sync and automation is needed between both field
3The field usage is the same
4The opportunity picklist can be promoted as global picklist
5The 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
1Huge number of inconsistent values
2External system codes
3Not used in processes, not displayed to users
4Historical 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
1The pricing category will be updated at the start of each season
2It will not be possible to select an outdated pricing category for new opportunity product
3Data will be loaded by external system, admin
4Old pricing category will remain as they are linked to old opportunity product
5Pricing 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
1Binary choice
2Yes/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 ...

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.