Flow on Uwe Braig

How to Build a Complex Validation Rule for Multi-Select Picklist in Salesforce Flow

Mon, 14 Jul 2025 00:00:00 +0000

Multi-Select Picklists can be tricky to handle when it comes to validations. In this article I will show how a Flow with the “Custom Error Message” element can be used for a validation logic that can be way more complex than with the “classic” validation rules.

The example requirement is to create a validation message upon record save for a multi-select picklist field “Product Interest” as follows:

We want to allow users to choose additional values, e.g. add “Dairy Products — Butter” to the “chosen” list.
But we want to prevent users from un-selecting values, e.g. remove “Fruits — Apples” from the “chosen” list.

Multi-select picklist field “Product Interest”.

The Data Model

The example will be shown with a multi-select picklist custom field on the Lead object:

1
2
3
4


API Name: ProductInterest__c
Label: Product Interest
Data Type: Picklist (Multi-Select)
Global Value Set: Product Groups

The global value set “Product Groups”:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


 Values API Name
------------------------- ---------------
 Dairy Products - Butter Dairy.03
 Dairy Products - Cheese Dairy.04
 Dairy Products - Milk Dairy.01
 Dairy Products - Yogurt Dairy.02
 Fruits - Apples Fruits.01
 Fruits - Bananas Fruits.02
 Fruits - Oranges Fruits.04
 Fruits - Strawberries Fruits.03
 Sweets - Chocolate bars Sweets.01
 Sweets - Cookies Sweets.02
 Vegetables - Broccoli Vegetables.02
 Vegetables - Carrots Vegetables.01
 Vegetables - Spinach Vegetables.03

The Flow

See below the preview of the flow we are about to build:

The Validation Flow

Start Element

Create a “Record-Triggered Flow” that runs before the record is saved. (Will also work with an after-save flow if this better fits your use case.)

Object: Lead (or any other standard or custom object)
Trigger the Flow When: “A record is updated”
Condition Requirements: Field “Product Interest” Is Changed = True

Start Element configuration

Helper Constant

Define a Constant as follows for clearer reference inside the Flow:

Section “Constants”

Define the semicolon “;” as a constant PicklistValueDelimiter

Helper Variables

We will need two helper text variables:

Section “Variables”

defined as follows:

Text Variable: CurrentPicklistValues

Text Variable: PriorPicklistValues

Get the Object Definition

A Get Records element to get the object “Entity Definition” with the definition of the object we are working on, here: Lead.

getObjectDefinition

If you want to do this with a custom object, don’t forget to add “__c” to the API Name, e.g. “MyCustomObject__c”.

Get the Field Definition

A Get Records element to query the object “Field Definition” for our multi-select picklist field “ProductInterest__c” using the “Durable Id” we’ve got in the previous step:

getFieldDefinition

Get the Active Picklist Values

A Get Records element to query the object “Picklist Value Info” for all currently active picklist values for this field:

getActivePicklistValues

Notes:

Make sure the setting under “How Many Records to Store” reads “All records” (unlike the other Get Records elements before).
This will only return active picklist values. There is no way to query for inactive values with this method.
In case you are using Record Types, also be aware: This will only return picklist values for the current record type of the current record.

Convert the Picklist Field Values to Delimiter-separated Text Variables

An Assignment Element as follows:

convertPicklistToText

En detail, this reads:

1
2
3
4


{!CurrentPicklistValues} Equals {!$Record.ProductInterest__c}
{!PriorPicklistValues} Equals {!$Record__Prior.ProductInterest__c}
{!CurrentPicklistValues} Add {!PicklistValueDelimiter}
{!PriorPicklistValues} Add {!PicklistValueDelimiter}

Loop Through the Active Picklist Values

Now we loop through all the values as per record collection returned by getActivePicklistValues:

loopPicklistValues

For each known picklist value, we check whether it was present in the PRIOR value but is missing in the CURRENT value. If such case occurs, we know that we need to raise the validation error message towards the user:

Check_Has_it_been_removed

The condition logic reads “1 AND NOT 2” with the following conditions:

1
2


{!PriorPicklistValues} Contains {!LoopPicklistValueWithTrailingDelimiter}
{!CurrentPicklistValues} Contains {!LoopPicklistValueWithTrailingDelimiter}

where “LoopPicklistValueWithTrailingDelimiter” is a helper text formula defined as follows:

1

{!loopPicklistValues.Value} + {!PicklistValueDelimiter}

Validation Error Message

Upon the first occurrence of such case, we use the “Custom Error Message” element to raise the validation error to the user and stop the flow:

ValidationMessage

Show Case

Now let’s run a test: Go to the example Lead, click “Edit” and play around with the multi-select picklist fields. Once you try to save the record after un-choosing a picklist value, the validation error message will be shown:

Test Run

Conclusion and Considerations

The “Custom Error Message” flow element has the same effect as a traditional validation rule: Once fired, the save transaction will fail and the user (in case of a UI transaction) or the caller of the interface (in case of an API/Dataloader transaction) will get the custom error message.
Record-triggered flows are way more flexible for implementing complex validation logic compared to the formula field-style “classic” validation rules.
Always be aware of the “order of execution”: In our example, we’ve used a before-save flow as this gives best performance in such scenario and we know that, by our design, no other logic will touch the picklist values on our record. But you need to assess whether other parts of other flows might update the picklist fields and you need to put the validation elsewhere in the order of execution, e.g. by setting “Trigger Order” in the flow properties and/or switching to an after-save flow.
The “Get Records” on “Picklist Value Info” only ever will see and return active picklist values for the given record type. Hence, we cannot identify the (very special) case where the user decides to un-choose a value that is a now-inactive picklist value: We don’t know about it, hence we won’t check for it in our loop.

This article has been written as per Summer ‘25 release.

For more information about handling picklist values in Flow also see the article “How to get Picklist Labels in Salesforce Flow”.

How to Concatenate a Collection of Strings to a Comma-Delimited String in Salesforce Flow

Mon, 23 Sep 2024 00:00:00 +0000

Salesforce Flow has come a long way and there have been vast improvements over the years and still there are interesting challenges when it comes to working with collections. But sometimes Flow is way more powerful than expected if you are willing to dig out a not-so-obvious solution.

The challenge here is: How to get from a list/collection of strings/records to a single comma-separated (.csv) formatted string?

The .csv Challenge

In this post I will present various options and discuss the pros and cons:

The Basic Approach: a very simple one with just one flow formula needed to convert a text collection into a comma-separated string.
The Basic Approach with custom delimiters: an extended version of the first approach that is a bit more flexible, but still fits into a single flow formula.
The Full Approach — with a text collection as the source: a fully featured approach that covers all special cases w.r.t. escape sequences and delimiter configuration, but requires more steps than just a single flow formula.
The Full Approach — with a record collection as the source: same approach, slightly different steps to use the Transform element instead of a Loop.

All options shown are contained in a sample demo Screen Flow that can be found here: CSV_Concatenation_Screen_Flow.flow-meta.xml

Now let’s see, what we can get out of example data as shown below:

1
2
3
4
5


Payload #1
Payload #2
Payload #3 with "1","2","3" commas
Payload #4 with "string" delims
Payload #5 with ";" semicolon delim

The Basic Approach

We take a flow variable of type string collection as starting point and populate it with some test values.

MyTextCollection flow variable.

Populate text collection with the demo values.

To convert this string collection to a comma-separated string, we just have to use it in a flow formula and do some simple post-processing to remove the [ at the beginning and the ] at the end that the formula puts there by default. See flow text formula toCsvBasicApproach:

1
2


/* Cut off leading/trailing [ and ] */
MID({!MyTextCollection}, 2, LEN({!MyTextCollection}) - 2)

What we get is:

1

Payload #1,Payload #2,Payload #3 with "1","2","3" commas,Payload #4 with "string" delims,Payload #5 with ";" semicolon delim

Considerations

This is quick and simple and works very well, if, and only if, the following constraints are ok for your use case:

Payload SHOULD NOT contain " because this might or might not confuse the parser of the consumer, depending on its exact implementation. However, we should generally consider this as .csv non-best practice. Hence, do not use if the payload may contain " characters.
Payload MUST NOT contain any comma , because with this approach the formulas cannot distinguish payload comma from field delimiting comma, so the whole result string will be broken once any payload string contains even a single comma.
Field delimiter is fixed to comma ,
Generally no string delimiter.

Or, to put it simple, this will work great for converting e.g.

1
2
3


Text 1
Text 2
Text 3

into Text 1,Text 2,Text 3

The Basic Approach with Custom Delimiters

For this improved approach, we want to have control over field delimiter and string delimiter. So we define two text variables, FieldDelimiter and StringDelimiter and initialize accordingly:

Assign desired field delimiter and string delimiters.

And we now use an enhanced formula toCsvBasicWithDelimitersApproach to convert our text collection:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


{!StringDelimiter}
/* leading string delimiter */
+ SUBSTITUTE(
/* outer replace: comma field delimiter to target field delimiter plus string delimiter */
 SUBSTITUTE(
 /* inner replace: pre-processing to escape string delimiters by duplicating it */
 {!ToCsvBasicApproach},
 {!StringDelimiter},
 {!StringDelimiter} + {!StringDelimiter}
 ),
 ",",
 {!StringDelimiter} + {!FieldDelimiter} + {!StringDelimiter}
)
+ {!StringDelimiter}
/* trailing string delimiter */

What we get:

1

"Payload #1";"Payload #2";"Payload #3 with ""1"",""2"",""3"" commas";"Payload #4 with ""string"" delims";"Payload #5 with "";"" semicolon delim"

Considerations

This delivers some minor improvements:

We can configure field delimiter and string delimiter.
We get the string delimiter properly escaped if contained in payload.

However, we still cannot deal with , comma as part of the payload: The replace operation still cannot distinguish between the comma created by concatenation and the comma that comes as part of the payload.

Again, to put it simple, works well for

1
2
3


Text 1
Text 2
Text "Special Case" 3

to be converted into "Text 1";"Text 2";"Text ""Special Case"" 3"

The Full Approach

To further improve, we need to pre-process the payload strings first before doing the concatenation. The pre-processing allows to handle literally all combinations of string delimiter and field delimiter also being part of the payload.

There are two options, depending on where the string collection originates from:

Case A: To pre-process a text collection, we put a Loop around our text collection with a single assignment element inside the loop. The actual work is done within a formula field again.
Case B: If the payload data happens to originate from the text field of a record collection, it is easier to combine two Transform elements to do the trick without the need for a loop. (N.B.: This will use an enhancement of the Transform element available in Winter ‘25.)

Case A: Text Collection as the Source

In total, the steps in the flow are:

Put together the text collection as in the previous examples.
Loop through the text collection with one assignment element inside the loop for a formula to do the pre-processing.
Access the resulting text collection via Formula that does the post-processing into a single .csv formatted string.

The Loop will take the initial text collection…

Loop through text collection

… and access each source text item via the formula toCsvPreprocessedLoopItem that does the pre-processing…

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


{!StringDelimiter}
/* each payload to start with string delimiter... */
+ SUBSTITUTE(SUBSTITUTE(
 SUBSTITUTE({!toCsvPreprocessorLoop},
 {!StringDelimiter}, {!StringDelimiter} + {!StringDelimiter}
 /* escape StringDelimiter inside payload by duplicating it everywhere */
 ),
 "%", URLENCODE("%")),
 /* first urlencode % sign inside payload */
 ",", URLENCODE(","))
 /* then urlencode standard comma field delimiter inside payload */
+ {!StringDelimiter}
/* ...and also end with string delimiter */

…and collects it into a new text collection named PreprocessedTextCollection:

Assignment element inside the loop

All items in the text collection now are pre-processed as follows:

All string delimiters are escaped by duplicating them, e.g. " to ""
All % characters inside the payload are URL-encoded to %25
All comma , characters are URL-encoded to %2C
Whole payload enclosed in string delimiters, e.g. "payload"

Now we can access this pre-processed text collection via the formula toCsvPreprocessorApproach…

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


SUBSTITUTE(SUBSTITUTE(
 SUBSTITUTE(
 MID({!PreprocessedTextCollection}, 2, LEN({!PreprocessedTextCollection}) - 2)
 /* strip off starting/leading [/] */
 ,
 {!StringDelimiter} + "," + {!StringDelimiter},
 /* replace default field delimiter... */
 {!StringDelimiter} + {!FieldDelimiter} + {!StringDelimiter}
 /* ...by our own one. Note: field delimiter inside payload is URLencoded */
 ),
 URLENCODE(","), ","),
 /* revert urlencoding of comma inside payload */
 URLENCODE("%"), "%")
/* revert urlencoding of % character */

…to get this built-to-order and properly escaped .csv string:

1

"Payload #1";"Payload #2";"Payload #3 with ""1"",""2"",""3"" commas";"Payload #4 with ""string"" delims";"Payload #5 with "";"" semicolon delim"

Case B: Record Collection as the Source

If the source data comes from record collection anyway, we can avoid the loop by having the Transform element do the tricks.

In total, the steps in the flow are:

Get Records element to retrieve the Source Data, here: Accounts
Transform element #1 to pre-process the desired field, here: Account.Name
Transform element #2 to put all Account.Name fields into a simple text collection.
Access the resulting text collection via Formula that does the post-processing into a single .csv formatted string.

We start with getting the Account records in question via a Get Records element. For this example we assume, that it returns 4 Accounts with Account names as given in our example data above.

Get Records Element

Then we use a Transform element that will take the Accounts collection from the previous step and will return another Accounts collection for temporary use. This Target Data collection will have the pre-processed version of Account name.

Transform Element #1

It will map Account.Name from Source Data to Account.Name in Target Data with the following formula for the pre-processing:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


{!StringDelimiter}
/* each payload to start with string delimiter... */
+ SUBSTITUTE(SUBSTITUTE(
 SUBSTITUTE({!getAccounts[$EachItem].Name},
 {!StringDelimiter}, {!StringDelimiter} + {!StringDelimiter}
 /* escape StringDelimiter inside payload by duplicating it everywhere */
 ),
 "%", URLENCODE("%")),
 /* first urlencode % sign inside payload */
 ",", URLENCODE(","))
 /* then urlencode standard comma field delimiter inside payload */
+ {!StringDelimiter}
/* ...and also end with string delimiter */

We get our Account names pre-processed as follows:

All string delimiters are escaped by duplicating them, e.g. " to ""
All % characters inside the payload are URL-encoded to %25
All comma , characters are URL-encoded to %2C
Whole payload enclosed in string delimiters, e.g. "payload"

With the next Transform element, we will take this temporary Accounts collection as Source Data and transform all Account.Name to a simple text collection:

Transform Element #2

Similar to the Basic Approach at the very beginning, we take this text collection as input for a formula field that does all the post-processing to deliver the final .csv formatted string:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


SUBSTITUTE(SUBSTITUTE(
 SUBSTITUTE(
 MID({!PreprocessedTextCollection}, 2, LEN({!PreprocessedTextCollection}) - 2)
 /* strip off starting/leading [/] */
 ,
 {!StringDelimiter} + "," + {!StringDelimiter},
 /* replace default field delimiter... */
 {!StringDelimiter} + {!FieldDelimiter} + {!StringDelimiter}
 /* ...by our own one. Note: field delimiter inside payload is URLencoded */
 ),
 URLENCODE(","), ","),
 /* revert urlencoding of comma inside payload */
 URLENCODE("%"), "%")
/* revert urlencoding of % character */

Here we go — from this selection of Account names…

Accounts Collection

…we get this built-to-order and properly escaped .csv string:

1

"Payload #1";"Payload #2";"Payload #3 with ""1"",""2"",""3"" commas";"Payload #4 with ""string"" delims";"Payload #5 with "";"" semicolon delim"

Considerations

The “full” approach properly handles all potential field delimiters and string delimiters that might occur inside the payload. So it is supposed to be suitable irrespective of actual content of the payload.

String delimiter and field delimiter are configurable.
New Transform element as of Winter ‘25 simplifies pre-processing without the need for a Loop element in certain cases.
In cases where we still rely on a Loop, we benefit from the fact, that the former limit “execution of maximum number of elements per flow interview = 2000” has been removed in Spring ‘23.

How to get Picklist Labels in Salesforce Flow

Fri, 16 Aug 2024 00:00:00 +0000

When working with picklist fields in Salesforce Flows, e.g. in a formula or a text template, the flow can only “see” the picklist API value and not the picklist label as shown in the GUI. This might not be an issue in your org if API value and label are configured to be always same and translation workbench is not in use. In all other cases, this can create usability constraints, e.g. when it comes to showing picklist values in Screen Flows or sending e-mails from within the Flow.

I will discuss the following solutions:

Use the Picklist screen component to extract the label.
Use a set of Get Record elements to query the PicklistValueInfo standard object in order to find the label for a given picklist value.
Use an invocable action in Flow to have an APEX class return the information from metadata.

All options in this article focus on handling single records and getting labels to display information on the screen or use text templates, for example to put together e-mails to be sent by the flow.

There are additional challenges when it comes to working with record collections, for example, to be used in the Data Table screen component. There might be a future article about this.

The Basic Scenario

A Salesforce org with the translation workbench enabled.
Active languages are English, German and Spanish.
Translations are in place for English and German only.
A custom object MyCustomObject__c and its corresponding custom tab.
A custom picklist field MyPicklist__c using the global value set MyPicklistValueSet.
This global value set and its translations are shown in the table below.

MyPicklistValueSet

Our example record looks like this:

Example Record

We do a simple flow that gets the example record by its record ID and puts its fields on a screen component:

Basic Scenario Flow

The screen component will show:

The Field component for the custom field MyPicklist__c of our example record.
A Display Text component that outputs the content of
a) the picklist field directly,
b) a text formula field referencing the picklist field,
c) a text template referencing the picklist field.

Field Component

Display Text Component

Text Formula

Text Template

And here comes what is wrong with it when we run this flow: Although the field component properly renders the picklist field with its (translated) label as we would expect it, all further references to the picklist only show the API value.

Flow Output

Solution #1: Picklist Choice Set

There is a difference between putting the Field Component of the picklist custom field on a screen and putting a Picklist Choice Set on a screen. As opposed to the basic scenario, here we use the Picklist Choice Set:

Add a new ressource of type Picklist Choice Set.
Set Object to the custom object where our picklist field is located.
Set the picklist field.

MyPicklistChoiceSet

Now the first component in our screen will be a picklist component that will refer to above Picklist Choice Set:

Multiple Options = No
Component Type = Picklist
Choice = link to Picklist Choice Set as created above
Default Value = The picklist field value from our example record.

Plus: Add the Picklist Component in the Display Text section.

Picklist Component

Our debug run will now look like this:

Flow Output

The text output of the Picklist Component will also work in formulas and text templates.

Considerations for this approach:

Obviously it will only work in screen flows, i.e. not suitable for record-triggered flows nor scheduled flows.
The Picklist Component must be rendered and visited during the screen flow, i.e. it MUST be shown to the user. It could be set to read-only (Disabled = {!$GlobalConstant.True}), but not to hidden. Otherwise it won’t be initialized with its default value and will be empty on accessing it. This might or might not be compatible with your specific use case.
Not suitable for record collections, especially for showing picklist labels in the Data Table component.
Per-Transaction Flow Limits: Does not count towards “Total number of SOQL queries issued”.
It will always deliver the label for the language of the running user, i.e. either the Master Label or the label as per translation workbench.

Solution #2: „Get Record" to Query PicklistValueInfo

In this approach, we will query the standard objects EntityDefinition, FieldDefinition and PicklistValueInfo with the “Get Record” element in order to get the picklist label:

Query for the object definition of our object MyCustomObject__c
Query for the field definition of our custom field MyPicklist__c
Query for the picklist value info (including the label) for the value in our example record.

Flow with PicklistValueInfo

Here the details for getObjectDefinition:

getObjectDefinition

With the DurableId from there, we can query the field definition:

getFieldDefinition

And with the DurableId of the field definition we can finally query for the Picklist Value Info:

getPicklistValueInfo

Now we are able to reference the picklist label from the result of getPicklistValueInfo and use it in the screen display text or formula fields or text templates:

Display Text Screen Component

Our debug run will now look like this:

Flow Output

Considerations for this approach:

Independent of any screen components, i.e. suitable for screen flows, record-triggered flows and scheduled flows.
Per-Transaction Flow Limits: Each Get Record element counts as a SOQL query towards the “Total number of SOQL queries issued” limit. So be aware when it comes to getting labels for multiple picklist fields and/or with looping, for example, when working for record collections and the Data Table screen component.
It will always deliver the label for the language of the running user, i.e. either the Master Label or the label as per translation workbench.

Solution #3: Invocable Apex Methods

For this approach, we need APEX code that can access the Schema objects and return labels for API values. Such APEX class can provide its methods as an “Invocable Method” which in turn can be accessed in a flow action.

A good summary explanation for invocable actions can be found under https://www.salesforceben.com/salesforce-invocable-apex-methods-a-complete-breakdown/ and an example implementation for such approach can be found under https://unofficialsf.com/flow-action-get-picklist-values/.

Considerations:

All pros and cons of APEX coding, e.g. the need for developer capability and capacity and having proper test classes and code coverage in place.
Per-Transaction Flow Limits: Does not consume SOQL queries within the “Total number of SOQL queries issued” limit.
Suitable for screen flows, scheduled flows and record-triggered after-save flows.
Not suitable for record-triggered before-save flows as those do not allow sub flows and actions.

Conclusion

These approaches are basically just workarounds for a, from my view, major lack of feature in Salesforce flow. It definitely should be a standard feature to be able to chose whether we want to see the API value or the label in the flow. I suggest to vote the following ideas on the IdeaExchange: