Starting with a Salesforce Knowledge article, insert variables using the {!VariableName} convention like this:

Create a flow that has these variables as … variables

Use the recordId variable to get the KnowledgeArticle record, based on MasterVersionId:

Get the fields to show:

Set the variables with the values you need to use (I used default values for this flow)

Make a screen component that show the fields:

Add the flow component to the Article detail page in the community, pass over the recordId:

And it will magically replace all variables in the text:

Additional Resources

Salesforce Knowledge and Flow Wiki Page

The Flow Troubleshooter Pattern is useful for creating and managing large numbers of custom nodes without having to manually add a flow element for each one.

This is extended functionality of Send Rich Email.

SalesForce Orgs and Communities often require multiple language support, including the ability to generate emails in the selected language of the Community anonymous user, member or Org User.

LightningFlowComponents/flow_action_components/SendHTMLEmail/ has been extended to send the appropriate language email based on the preferred language as part of a flow action to send email. This Action uses Lightning EmailTemplates, and has not been tested on Classic Templates (yet).

For this functionality, each language localization has its own template, that shares a common EmailTemplate.Name. To differentiate the localizations, add a tag to the EmailTemplate.Description field in the format: ‘Language=”en_US”‘ (or whatever corresponding to your organization localizations).

When the sendHTML templateName and templateLanguage parameters are used, the action selects the template with the matching templateName and the ‘Language=”xxx_YY”‘ tag in the Description. (Note, no spaces, exact match only)

Template Selection criteria order is prioritized using matching EmailTemplate:Name and:

1. If templateLanguage is empty, set to Organization LanguageLocaleKey
2. If templateLanguage tag is found in EmailTemplate.Description (e.g., ‘Language={{{templateLanguage}}}’)
3. First matching template with matching templateName but no corresponding ‘Language=”‘ tag in EmailTemplate.Description

Example:

Step 1: Identify the Common EmailTemplate:Name for the Template Set you would like to use for localization and copy the name. (App Launcher–>Email Template[lightning]). (Note, in this case it would be “OAG OCP Complaint Received Email” – and there are two tagged locales identified in the Description Field, “en_US” and “es_MX”)

Step 2: Add the Apex action to your Flow and set the Parameters:

• Associated RecordId(WhatId/recordId for template and activity) (In Example, a Case Record ID {!param_Case.Id}, but only needed if you are using merge fields for this record)
• Template Language (In Example, the language chosen in the flow logic for the Contact {!param_Language})
• Template Name (In Example, “OAG OCP Complaint Received Email” )
• Template Target Record Id (In Example, {!param_ContactID} which is to whom the email will be sent, and any recipient merge fields used in the template)

Caveats

Limitation: Enhanced Letterheads are not supported in Lightning Communities at this time. A support request has been submitted and it is being worked on by SF. If you attempt to use the Enhanced Letterhead in a Community application, you will get the following error: sObject type ‘EnhancedLetterhead’ is not supported. If you are attempting to use a custom object, be sure to append the ‘__c’ after the entity name. Please reference your WSDL or the describe call for the appropriate names.: []

Kludge Acknowledgement: The elegant solution would have a localization field in EmailTemplate (e.g., EmailTemplate.LanguageLocaleKey ). At this time, no such field exists and you cannot add custom fields to EmailTemplate Object – ergo, a tag parsed from the standard “Description” is the kludged approach.

SEE ALSO

• Enable Multilingual Solutions
• EnhancedLetterhead Issue

Some input parameters requires strings in one of two forms. Send Rich Email, for example, can take a list of string email addresses but can’t (currently) take a comma-separated-list.

This package provides a set of simple actions to convert data from one form to the other.

Convert from Collection to CSV String

This takes a string collection and returns a csv string.

Convert To String Collection

ConvertToStringCollection, can use a provided character as a delimiter. For example, if you pass in the output of a multiselect picklist and set the delimiter to a semicolon, you’ll convert multiselect picklist output to a collection of strings that can be worked on later in the flow.

Install

12/14/23 – This is now included in the Collection Processors package

Old Versions

4/16/23 Version 1.2 Production Sandbox Categorized as Utilities; You can pass in an alternative delimiter to comma.

Version 1.1 Unmanaged

Version 1.0 Unmanaged

View Source

source (Collection Processor Package)

source (original)

There are several techniques that can be applied to let users pause a flow and resume it. The simplest technique is to enable the Pause button in each of the flow’s screens, and then give the user access to the Paused Flows lightning component, from where they can resume. However, this is not always workable. It doesn’t work, for example, for guest users running the Flow via Community Cloud, and there is often not a good place to put the Paused Flow component where it can be easily found without being in the way.

Another approach is to use Salesforce Surveys, which runs on the Flow engine.

A third way of dealing with this scenario is to add actions to the flow that store and retrieve the values users enter after each screen. If the user loses connectivity, or quits, they can return later and the values they had previously entered will be loaded into the appropriate screen fields.

There are a lot of ways to do this, with varying degrees of complexity, but they share in common a core concept: A custom object that represents an individual flow session. The different values that the user enters are serialized into a single big string that gets stored in a flow session record.

Example

We have a flow called Health Survey. To enable custom resume, we have defined a custom object called Flow_Session__c. This object has two important fields: SessionData, which stores all the values that the user has entered, and SessionToken, which makes it possible for the record to be matched to the user when they return.

In our Health Survey flow, the user is first shown to Screen 1, where they fill in a variety of fields and then click Next. Here we have a design decision: do we want to update the HealthSurveySession record every time the user clicks next? Or do we want the updating to only happen when the user clicks a Save or Pause button? Either way will work. Let’s assume that we’re going to autosave the user’s date each time they click Next.

That means that we’ll need to extract the form data provided by the user in Screen 1, and save it to our HealthSurveySession record.

Storing and Retrieving Answer Data

Take a look at this version of our flow, which supports a single screen of input data:

After each screen, the flow has a Serialize Health Data action that takes all of the fields that the user has been able to edit so far in the flow, serializes their values (serializing means taking an object and converting it into a string) and returning the serialized string. After each step, the Flow Session can be saved with this latest version of the session data.

Before each screen, there’s a Deserialize Health Data action that loads in the string from the current Flow Session (if one exists), and converts it into a HealthSurveySessionData object. This object is then used to map values into the screen. In this way, the values from the previous session get loaded in as defaults when the screen renders:

Where does this useful but focused object come from? It’s defined in Apex as a class and accessed in Flow using Apex-Defined Types.

Here’s what the class looks like:

As you can see, this class doesn’t do anything at all. It’s just a data structure. It’s the Apex equivalent of defining a Custom Object and adding a bunch of Custom Fields.

Let’s go back to our Flow Session. Here’s what one looks like after a user has filled in a screen:

The data that we need to reload into the screen is all there in Session Data. The deserialization process is extremely simple:

Notice how the output of this action is a HealthSurveySessionData object. That’s what gets fed to the inputs of the flow screen. The actual deserialization is carried out with a single line of Apex.

As fields are added to the Flow over time, the HealthSurveySessionData class will need to be updated. However, the two actions will not need modification.

Install Package

This package installs the classes and demo flow described above.

Unmanaged 1.0

Wiki Resources

Flow and Apex Integration