SOQL LIKE Operator on Picklists: Why It Breaks Between API Versions

A SOQL query using the LIKE operator against a picklist field can behave completely differently depending on the API version it runs under. A query that works flawlessly on API v41.0 can silently fail or return zero rows on API v64.0, even though nothing in the query or the data has changed. This is a known, deliberate platform change, not a bug.

Root Cause

Salesforce changed how LIKE evaluates picklist fields starting with API Version 51.0 (Spring '21).

API Version	LIKE evaluates against
v41.0 and earlier	The picklist's API Name (the raw value stored in the database)
v51.0 and later (including v64.0)	The picklist's UI Label (the display text shown to users)

Before this change, WHERE Picklist_Field__c LIKE '%value%' was matched against the backend Value stored in the database. After the change, the same query is matched against the label the picklist displays in the UI, which is not necessarily the same string, especially for translated orgs or fields where labels and API names diverge.

This distinction matters most for Global Picklists (and standard picklists), since these are exactly the fields where label/API-name mismatches are common.

Why Integrations Are Affected

Integrations typically communicate using database API Names, not UI Labels. When an integration issues a LIKE query expecting to match an API Name, it runs head-first into a platform layer that, from v51.0 onward, only searches Labels. The query doesn't error out, it simply returns no matches, which makes the failure look like a data problem rather than a version-behavior problem.

How to Fix It

Approach 1: Use exact match (= or IN) instead of LIKE 

Picklists have a fixed, predefined set of values, so partial-string matching is rarely necessary in the first place. Exact-match operators evaluate against the API Name consistently across all versions.

-- Instead of:
WHERE Global_Picklist__c LIKE '%Active%'

-- Use:
WHERE Global_Picklist__c = 'Active'
-- or
WHERE Global_Picklist__c IN ('Active', 'Pending')

This is the safest, most future-proof fix, since = and IN are unaffected by the label/API-name change.

Approach 2: Match the UI Label text

If the integration must keep using LIKE, the search string needs to match the partial Label text, not the API Name. This works but is fragile: it breaks if labels are renamed, translated, or vary by locale.

Approach 3: Add a formula field to expose the API value as text

If substring matching against the true backend value is unavoidable:

1. Create a custom formula field on the object, e.g. Picklist_Text_Copy__c, with the formula:

   TEXT(Global_Picklist__c)

1. Point the integration's query at that field instead:

   WHERE Picklist_Text_Copy__c LIKE '%value%'

Formula fields return plain text and bypass the picklist label-translation logic entirely, restoring the old v41.0-style matching behavior.