We’ve received lots of questions about an impending change related to how merge field syntax is rendered when it comes from record data in screen flows in Summer ‘22. I thought it would be a good idea to talk a bit more about it using some scenarios to help clarify what is changing.

From the release notes:

Merge Fields Evaluate Based on Context

If data coming into a flow includes text that resembles a merge field, the merge field now shows the merge field notation instead of the merge field’s evaluated value. This change helps prevent unintentional data exposure and improves flow stability. In API version 54.0 and earlier, merge fields showed the evaluated value.

For example, your org has a flow that includes an account record’s description in the text input of a display text component. The account record’s description uses merge fields. The description is “{!Account.Industry} company from {!Account.BillingCity}”. In API version 54.0 and earlier, the two merge fields are evaluated, so the description would render as “Education company from San Francisco”. From API version 55.0 onward, the two merge fields aren’t evaluated, so the description renders as “{!Account.Industry} company from {!Account.BillingCity}”.

Likewise, in API version 55.0 onward, if an end user enters the merge field {!Account.Name} in an input for a screen flow, it renders as {!Account.Name} and isn’t evaluated. In API version 54 and earlier, the account name is rendered. Essentially, if a merge field is used in an input in a way that surfaces data, the merge field isn’t evaluated.

If you have flows that rely on using the evaluated merge field values, a workaround is required. Create a custom Apex action that performs an equivalent merge field substitution and then call it in a flow with the Apex Action element.

Scenario 1: Merge Syntax and Record Data

tl;dr – If you try to display record data that has merge field syntax within it, we won’t try to resolve it to Flow data for any flow running on API Version 55 or greater. Note this does not affect all merge field syntax. If you have syntax specified as the input of an action, for example, you will not see any change in behavior. You also won’t see any change in behavior if you use merge syntax in display text on screens.

Let’s take a scenario and run through the before and after. 

Say you have a field on the Case object called ‘Case Greeting Template’, and whenever a case is made, it gets some boilerplate standard text set as the value. Let’s say it’s something like the following

Thanks {!CaseVariable.FirstName} for reaching out! We’ll reach out to you in {!CaseVariable.SLA_DueDate__c}

If you look at the case in a standard record page, you’ll see the merge syntax exactly as worded above.

Let’s say you then add {!CaseVariable.Case_Greeting_Template__c} to a flow screen in some Display Text.

Before Summer ‘22 (API Version 55.0)

If you displayed {!CaseVariable.Case_Greeting_Template__c} in a Screen Flow, we would try to resolve the merge syntax and display the values on screen:

Thanks Jon for reaching out! We’ll reach out to you in 5 Days

After Summer ’22 (API Version 55.0)

Now in API Version 55 and later, we will no longer try to resolve runtime-entered merge field syntax or syntax coming from record data:

Thanks {!CaseVariable.FirstName} for reaching out! We’ll reach out to you in {!CaseVariable.SLA_DueDate__c}

What’s Not Changing

We’re not making any changes to direct merge fields in Display Text. If you used the following in Display Text, it would continue to pull in Case fields as it does today at runtime:

Display Text Value: Thanks {!CaseVariable.FirstName} for reaching out! We’ll reach out to you in {!CaseVariable.SLA_DueDate__c}

At Runtime: Thanks Jon for reaching out! We’ll reach out to you in 5 Days

Scenario 2: User-entered Merge Syntax Not Evaluated

Similar to record data, if a user is running a Flow and enters in correct merge field syntax into a text input, the Flow engine will no longer try to resolve it. I’ve seen some people get creative here in building ‘on the fly’ formulas at runtime – this will no longer work.

Example:

Before Summer ‘22 (API Version 55.0)

After Summer ‘22 (API Version 55.0)

What else will this affect – Get Records + EmailTemplate

One nice positive of this is a fix related to querying the EmailTemplate object’s Body field which stores the contents of an email template. Ever tried to do a Get Records on EmailTemplate and reference the template body in some Display Text? You’ll notice some unfortunate results if you have. You’d get the following error:

Hmm, that didn’t work. Check your internet connection and try again, or refresh the page. If the problem continues, ask your Salesforce admin to contact Salesforce Customer Support.

Now in API Version 55 and above, you’d see the following:

Dear {!Contact.FirstName},

I really enjoyed speaking with you today. I think that {!Organization.Name} has a lot to offer {!Account.Name} and I look forward to our next meeting.

Regards, {!User.FirstName}

Why the Change?

Simply put, this will make your flows more secure. If you need the functionality back, you can hold off on upgrading your Flow version to API version 55 or use Apex to resolve the merge fields for you. You could pass in the data you want to parse and have Apex look for the merge fields, resolve and query those values for you, then pass in those values (or all of the data) back into the Flow. Perhaps this could be a great action for an adventurous person in the community to tackle!