Salesforce picklist fields are not case-sensitive. This means that picklist values that differ only by letter case — such as "TEST", "Test", and "test" — are treated as identical by the platform. You cannot have multiple active or inactive picklist entries that differ only by case for the same picklist field on the same object.
When you insert a record in Salesforce with a value for an unrestricted picklist field that does not already have a matching PicklistEntry defined, the platform automatically creates an "inactive" picklist value for that entry. As documented in the Field Types reference: "When inserting an unrestricted picklist field that does not have a PicklistEntry, the system creates an 'inactive' picklist value. This value can be promoted to an 'active' picklist value by adding the picklist value in the Salesforce user interface." This inactive value can be promoted to an active picklist value through the Salesforce Setup interface.
If you insert one record with a picklist value of "Test", and then attempt to insert another record with "TEST" or "test", the platform compares the values case-insensitively at the object level. Because "TEST" and "test" are considered identical to the already-existing "Test" inactive value, all subsequent insertions take the value of the first entry ("Test"). You cannot create separate picklist entries for "TEST", "Test", and "test" on the same field.
This behavior occurs because picklist values in Salesforce are not unique to individual records — they are tied to the field definition at the object level. Case-insensitive comparison is enforced across the entire object, not just within a single record.
If you require record-by-record uniqueness for a field that stores values of different cases, a picklist field is not the right data type for this use case. Instead, create a read-only Text field on the object. Use an Apex trigger to populate this field with the exact case-sensitive value you want to store whenever a record is created or updated. Because text fields do not enforce case-insensitive deduplication at the object level, you can store "TEST", "Test", and "test" in different records without collision.
To manage the valid values that can be stored, use a Custom Setting or Custom Metadata Type as a lookup store for the allowed case-sensitive strings. The trigger reads the allowed values from the Custom Setting and applies the correct value to the text field based on your business logic (for example, by matching a prefix, suffix, or key indicator in the record).
This approach provides record-by-record uniqueness because each record independently holds its own text field value, unlike picklist fields which share a common set of values across all records on the object.
000386557

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.