Introducing Flow Orchestrator

At the online Dreamforce Keynote on December 2, Marc Benioff and Sarah Franklin introduced Einstein Automate, a new message that describes the full range of the Salesforce automation solution. Sarah’s area of ownership includes the Automation Services team that includes Flow, Next Best Action, Process Builder, Workflow Rules, and Approval Processes.

As part of this announcement, Salesforce debuted Orchestrator, which I believe will be one of the most impactful products that Salesforce has produced in years. Orchestrator takes a wide range of rich, sophisticated, and complex business process use cases that require code today and makes them easy to create with clicks.

To get an introduction, start with this part of the Dreamforce Keynote:

Orchestrator’s key message slides:

We’ll publish more preview information on Orchestrator in the months to come.

Custom Property Editors Now Have Access to ‘Upstream’ Automatic Outputs

Until now, if you built a Custom Property Editor and wanted to enable users to map upstream mergefields to various inputs of your CPE’s underlying action or screen component, you could only get access to manual variables. Salesforce in general is encouraging flow builders to move away from manual variables and let Flow handle things automatically. So it has been important to enable CPE developers to have access to automatic references.

That’s possible starting in Spring ’21. Here’s the release note with the syntax:

We intend to upgrade the Flow Combo Box that can be found in Flow Screen Components Base Pack to incorporate this new data access so that all upstream values will be visible and we can always use help from the community. If you’re an LWC developer and interested in helping out, please post a comment.

Datatable Now Includes a Custom Property Editor

See this in action during DreamTX!

Flow Builder Demos 12/17 (1PM, 2PM, 3PM Eastern Time)

The Datatable Flow Screen Component has come a long ways from the original Aura component that included separate attributes for 10 different Salesforce objects in a single component. Once Salesforce supported the ability to pick the desired Object in the Flow Builder, at the time of configuration, it was rebuilt from scratch as a Lightning Web Component. Now Datatable has been reimagined again with the addition of a Custom Property Editor that’s used by the Flow Builder whenever a Datatable is added to a Flow Screen.

This image has an empty alt attribute; its file name is image-18-894x1030.png

Custom Property Editors allow a developer to bypass the standard basic list of all component attributes in the Flow Builder and replace it with a Lightning Web Component that can present a logical and formatted interface for the user to configure the component. The CPE developed for the Datatable component takes this even further by including a button that launches a separate Flow that displays a special Datatable the user can interact with to configure their Datatable. I like to refer to this as my Custom Column Configuration Wizard.

Once installed, this component will appear as Datatable in the Flow Builder. DatatableV2 will still work with your existing Flows and can coexist with the new Datatable.

Here are a few examples showing how to build a Flow with a Datatable, how to configure the Datatable using the Custom Property Editor and how a user can interact with a Datatable. For complete documentation, visit the Datatable page.

Build a Flow with a Datatable

Configure a Datatable with the Custom Property Editor

Interact with a Datatable

2 New Posts on Processing JSON for Use in Flow

Munawirrahman has posted a useful new Flow Action package that takes a different, looser, more dynamic approach to getting data out of JSON for use in Flow. His action invites the user to simply list out the interesting keys, and he returns the extracted values. His approach allows for full penetration of nested data.

UPDATE: Also see this additional post.

He points to a blog post we missed, from Rafael Cunha, that discusses the use of Apex-Defined Types to handle incoming JSON….

in the style of the original Apex-Defined Type article here:

The use of Apex-Defined Types is great when you’re building your own Flow Action. It allows you to permanently provide a conversion bridge from the JSON to Flow data structures in a way that your users running your flow will never have to think about. But if you instead are dealing with different kind of JSON, a dynamic extractor like the one Munawirrahman provides is an excellent tool.

Check it out!

Check out these Flow Use Cases and Scenarios

Vibhor Goel has been publishing some great blog posts for quite some time on Accidental Coder. Recently he published a list recapping some wonderful flow use cases and scenarios he has written about in the past. Check out the complete list here: Salesforce Flows : Flow Use Cases and Scenarios

Lookup now supports multi-level dependencies

A Salesforce team in Great Britain reached out to me recently with an interesting use case for the Lookup component.

Back in 2018, I enhanced the original Lookup component to support Parent/Child lookups.  This type of dependent lookup allowed admins to create Flows that could request related information on a single screen rather than having to always go to a new screen in order to reference a value entered on a previous screen.

These Parent/Child lookups made it very easy to do something like lookup an Account and then have a lookup for Contacts that would only present a list of Contacts related to the previously selected Account.

What Kehzar Mohammed and Mahadevan Venkata wanted to do was to extend the Parent/Child relationship to include another level (Grandchild).  Their use case was to have the user select the Make of a Car, then based on the Make, select a Model of the Car, then based on the Model, select a Derivative of the Model.  This would be similar to my Account – Contact example above with the addition of then selecting a Case related to the selected Contact.

I updated the Lookup component to support a lookup that could be identified as Both a Parent and a Child lookup.  Now an Admin can configure the component to nest as many dependent lookups as they need.

Watch this video for a quick example of how this works for Kehzar’s and Mahadevan’s use case.

Salesforce Announces ‘Einstein Automate’!

Salesforce today announced Einstein Automate, which unifies Salesforce’s existing automation technologies and announces several new products, including Flow Orchestrator, which will be the most significant thing the Automation group has done since it shipped the new Flow Builder. Check it out here in print, and tune in Wednesday morning to see it in Marc Benioff’s Dreamforce Keynote address.

From Frank Caron: Pre-fill the Fields of Embedded Flows

Flows are among the Salesforce Customer 360 Platform’s most powerful declarative tools, and yet there are still many admins out there who haven’t taken advantage of one of the tool’s coolest features: the ability to embed flows in external, non-Salesforce web sites.

The Embedded Service Deployment feature allows you to, with the help of a flow and a community, embed a flow in an external website by generating a simple HTML and JavaScript snippet that an admin can copy and paste.

Unfortunately, by default, this external deployment of Flows lacks certain conveniences that go along with using a Flow in Experience Cloud, like easily pre-populating input fields in the Flow. Say, for example, the end-user is already logged into your external site, and you want to pass their basic first name, last name, and email into the Flow. You won’t find an obvious way to achieve that type of pre-fill with the feature alone. 

But wait! Embedded Flows can actually be pre-filled by the external website, and that’s what this Embedded Pre-Filled Flows extension is all about. With the unmanaged package and code repository we’ve provided, you can easily extend your Flows to external websites while still pre-filling fields.

How It Works

Getting a Flow embedded into an external site is actually very easy and requires no code. The Embedded Service Deployment feature lets you do this; it uses Salesforce Experience Cloud (Communities) and the concept of a guest user to allow the Flow to run in an external context.

In order to actually pass values into that external flow, though, we need some kind of mechanism. URL query parameters to the rescue! Like many great web applications, Salesforce can easily read arbitrary data from the current URL in the end user’s browser. The external application that embeds a Flow, then, can actually be made to pass values to the Flow through the URL. 

Once the flow starts, action needs to be taken to retrieve those parameters from the URL and pull them into the flow. This is done with Flow Local Actions. By using a Flow Local Action component to grab some query params from the URL, we can allow the external website to send attributes into the Flow neatly. This is very similar in principle to Flow internal URL variables.

The installable extension below includes a local action that grabs URL parameters for use in a Flow that is distributed via an External Service Deployment.

In this example, the Flow uses the Custom Local Action that’s designed to look for a URL parameter called “userName”. When the Flow runs, it looks to the URL in the end-user’s browser for the query param — e.g., — and grabs it, passing it into the flow for use.

The Flow can then use this value to fill any field, grab records, and more: any and all of the typical work you would do in a Flow.

You can see a working example here:

Reviewing The Code

Let’s dig into the composition of the GrabQueryParams Local Action in a little more detail:

Usable InFlows as a Local Action
Attributesparameter1NameThe String attribute name for a query parameter that will be identified in the URL

parameter1ValueThe String value retrieved from the attribute of parameter1Name in the URL for use in the Flow
parameter2NameThe String attribute name for a query parameter that will be identified in the URL

parameter2ValueThe String value retrieved from the attribute of parameter2Name in the URL for use in the Flow
parameter3NameThe String attribute name for a query parameter that will be identified in the URL

parameter3ValueThe String value retrieved from the attribute of parameter3Name in the URL for use in the Flow
ControllerThe JavaScript controller has a function that, on component load, does the following:

Read the current URLLook for query parameters in the style of “name=value”Set the value of a given URL query param to the matching parameter value in the component (e.g., if varName=Frank in the URL, set param1Name to “varName” and catch param1Value to get “Frank” in the Flow).
ExtendingTo extend the component…Add additional attributes to the component to represent the specific variables you want to expose to the flow Update the controller to parse the according values from the URL and map them to the attributes in the component.

How To Set It Up

To make things easy, we’ve included both an unmanaged package and an SFDX-friendly source code repo at the bottom of this post.

Once you’ve cloned the repo and pushed the source to your org, or you’ve installed the package, here’s what you’ll need to do: 

  1. Set up a Community
  2. Set up the Embedded Service Deploy, and use the included Flow
  3. Update the code snippet in the included test page (test.html) with the one generated by your Embedded Service Deploy.
  4. Deploy the HTML page somewhere (e.g., AWS S3)
  5. Update your CORS settings in the Org to whitelist the web page URL you’ve deployed
  6. Visit the deployed HTML page and add ?userName=ABC to the URL to see it work.

With that, you’ll be able to hit the external site and begin to experiment. 

Modifying The Attribute Pre-Fill Mapping

Out of the box, we’ve set up three query params (parameter1, parameter2, parameter3) that you can work with. All three are optional. This allows you to use up to three unique URL parameters from your external site with no-code configuration. 

To specify a particular URL parameter name, create a text variable in the Flow that has the desired  attribute name as its value (e.g., “userName”) and set it as an input value for the “parameter1Name” field in the Action config screen. In this example, which is included in the package, QueryParamToFind is set to “userName”.

Then create a text variable to store the value that will be retrieved from the URL for that parameter1 attribute. Set it as the output value for the “parameter1Value” field.

Now, when the Flow is run on a page with a URL that includes “?userName=Frank”, the code will check for parameter1Name (“userName”) and capture its value (“Frank”) in the parameter1Value variable (“varName”) for use in the Flow. 

You can use the same approach for the other two parameters, which allows you to capture up to three URL query parameters with the out-of-the-box Flow and Local Action.

Oh, And One Quick Security Tip

The ability for external Flows to work with query attributes from the URL can be very powerful. However, it’s important to note that this method of sharing data with a flow is not well suited to situations where you need to pass very sensitive data to the Flow. 

Query parameters are visible to the client (e.g., the end-user’s browser) and can be accessed by other JavaScript (including rogue scripts), so use this pattern wisely and only for non-sensitive data.

If you need to pass very sensitive information between an external website and Salesforce for use in a Flow, you may want to consider other patterns (e.g., a direct API integration between your external application and Salesforce).


Unmanaged package with:

  • A custom Aura component with the Local Action
  • A sample Flow that uses the Local Action


SFDX-friendly code repo


Thanks to Henry Hai for his assist on this one!

Banner Component for Custom Property Editors

Created by Eric Smith – November 2020

This Post was most recently updated on: 11/28/20


The fsc_flowBanner component is designed to be used in a Custom Property Editor. It provides a way to create sections and add separation between different functional areas of a Custom Property Editor LWC.

The component also supports a link to informational or help text for the section.

Using Flow Banner

The component is added to the HTML file of the Custom Property Editor. The developer can specify the Colors for the Banner and Modal Header, the Label and the contents of the information modal.



bannerColor – Color of the banner (default: #4C6E96)

modalHeaderColor – Color of the information modal header (default: #657B96)

bannerLabel – Text to appear in the banner

bannerInfo – Contents for the information modal body. It needs to be passed to the component as an array of objects consisting of a label and helpText

    @api bannerInfo = 
            {label: 'Attribute #1 Label', helpText: 'Attribute #1 Helptext'},
            {label: 'Attribute #2 Label', helpText: 'Attribute #2 Helptext'},

bannerClass – Formatting of the banner text (default: slds-text-color_inverse slds-text-heading_medium)

bannerMargin – Spacing around the banner (default: slds-m-top_small slds-m-bottom_xx-small)

bannerPadding – Determines the thickness of the banner (default: 0.3rem)

Icon Attributes – These default values can also be overridden by the calling CPE

@api bannerIcon = 'utility:info'; 
@api bannerIconSize = 'medium';
@api bannerVariant = 'bare-inverse';
@api bannerTitle = 'Info';
@api bannerAltText = 'Help Text Info';


This component is part of the Flow Base Packs package libraries.

View Source

The source code can be found as part of the Flow Screen Components Base Pack.