Some actions and screen components have input attributes of type SObject or SObject[].  When configuring an instance of one of these, you need to provide a concrete type in order to save the flow successfully.

The standard property editor does this by providing automatically generated mapping UI:

As the developer of a custom property editor, you have more flexibility. You can choose to provide a UI identical to the UI shown above. But you can also choose to handle the concrete mapping behind the scenes. For example, you might choose to ask the user a friendlier question like “What type of object do you want to use with this action?” and provide an object picker. Once the user has picked the object, you can fill in the dynamic type mappings via a normal CPE event dispatch.

When setting a type mapping, use this event:

const event = new CustomEvent('configuration_editor_type_mapping_changed', {
    composed: true,
    cancelable: false,
    bubbles: true,
    detail: {
        name, // name of the dynamic type. For actions, include the param name:  'Typename__param1'. For screens, just use the type name e.g "T"
        value, // concrete value type of the dynamic type, e.g 'Account'
    }
});

// for Screens the name attribute for event is just the dynamic type e.g “T”
// for Actions it’s the type followed by the param name e.g “T__paramName”

Retrieving Existing Generic Type Mappings

The CPE interface supports a new attribute genericTypeMappings:

* array of complex object containing type name-value of the dynamic data types
   * in Action or Screen
   * eg: [{
   *       typeName: 'T', // the type name
   *       typeValue: 'Account' // or any other sObject
   *     }]
   */

Here’s an example of a CPE that supports generic type mapping:

import { LightningElement, api, track } from "lwc";

export default class DynamicTypeCpe extends LightningElement {
  _inputVariables = [];
  _builderContext = {};
  _elementInfo = {};
  _genericTypeMappings = [];

  _flowVariables;
  _elementType;
  _elementName;
  /* array of complex object containing name-value of a input parameter.
   * eg: [{
   *       name: 'prop1_name',
   *       value: 'value',
   *       valueDataType: 'string'
   *     }]
   */
  @api
  get inputVariables() {
    return this._inputVariables;
  }

  set inputVariables(variables) {
    this._inputVariables = variables || [];
    this.initializeValues();
  }

  
  @api
  get builderContext() {
    return this._builderContext;
  }

  set builderContext(context) {
    this._builderContext = context || {};
    if (this._builderContext) {
      const { variables } = this._builderContext;
      this._flowVariables = [...variables];
    }
  }

  /* contains the information about the LWC or Action in which
   * the configurationEditor is defined.
   * eg: {
   *       apiName: 'CreateCase', // dev name of the action or screen
   *       type: 'Action' // or 'Screen'
   *     }
   */
  @api
  get elementInfo() {
    return this._elementInfo;
  }

  set elementInfo(info) {
    this._elementInfo = info || {};
    if (this._elementInfo) {
      this._elementName = this._elementInfo.apiName;
      this._elementType = this._elementInfo.type;
    }
  }
  
  /* array of complex object containing type name-value of the dynamic data types
   * in Action or Screen
   * eg: [{
   *       typeName: 'T', // the type name
   *       typeValue: 'Account' // or any other sObject
   *     }]
   */
  @api
  get genericTypeMappings() {
    return this._genericTypeMappings;
  }

  set genericTypeMappings(mappings) {
    this._typeMappings = mappings || {};
    this.initializeTypeMappings();
  }

  /* Return a promise that resolve and return errors if any
   *    [{
   *      key: 'key1',
   *      errorString: 'Error message'
   *    }]
   */
  @api
  validate() {
    const validity = [];
    return validity;
  }
  
  get options() {
    return [
      { label: "Account", value: "Account" },
      { label: "Case", value: "Case" },
      { label: "Contact", value: "Contact" }
    ];
  }

  get recordVariableOptions() {
    if (this.typeValue) {
      return this.updateRecordVariablesComboboxOptions(this.typeValue);
    }
    return [];
  }

  @track
  inputValue = "";

  @track
  typeValue = "";

  @track
  record;

  initializeTypeMappings() {
    this._genericTypeMappings.forEach((typeMapping) => {
      if (typeMapping.name && typeMapping.value) {
        this.typeValue = typeMapping.value;
      }
    });
  }

  initializeValues() {
    this._inputVariables.forEach((variable) => {
      if (variable.name && variable.value) {
        if (variable.valueDataType === "reference") {
          this.inputValue = "{!" + variable.value + "}";
        } else {
          this.inputValue = variable.value;
        }
      }
    });
  }

  handleComboboxChange(event) {
    if (event && event.detail) {
      const newValue = event.detail.value;
      this.comboboxvalue = newValue;
      // for Screens the name atrribute for event is just the generic type e.g "T"
      // for Actions it's the type followed by the param name e.g "T__paramName"
      const name = this._elementType === "Screen" ? "T" : "T__record";
      const dynamicTypeChangeEvent = new CustomEvent(
        "configuration_editor_type_mapping_changed",
        {
          bubbles: true,
          cancelable: false,
          composed: true,
          detail: {
            name,
            value: newValue
          }
        }
      );
      this.dispatchEvent(dynamicTypeChangeEvent);
      this.updateRecordVariablesComboboxOptions(newValue);
    }
  }

  updateRecordVariablesComboboxOptions(objectType) {
    const variables = this._flowVariables.filter(
      (variable) => variable.objectType === objectType
    );
    let comboboxOptions = [];
    variables.forEach((variable) => {
      comboboxOptions.push({
        label: variable.name,
        value: "{!" + variable.name + "}"
      });
    });
    return comboboxOptions;
  }

  handleRecordChange(event) {
    if (event && event.detail) {
      const newValue = event.detail.value;
      this.inputValue = newValue;
      const valueChangedEvent = new CustomEvent(
        "configuration_editor_input_value_changed",
        {
          bubbles: true,
          cancelable: false,
          composed: true,
          detail: {
            name: "record",
            newValue,
            newValueDataType: "reference"
          }
        }
      );
      this.dispatchEvent(valueChangedEvent);
    }
  }
}

For more info, see https://unofficialsf.com/custom-property-editors-developers-guide/

The lightning:flow component is commonly inserted into aura components to enable screen flows to run when those components are rendered. What if you want to insert a flow into your own LWC component?If you’re building an LWC, you can’t currently just invoke lightning:flow because it has not yet become available in an LWC version (and LWC doesn’t allow Aura components to be inserted).

To address, that, the ScreenFlow LWC installable from this page provides a way to insert a flow into your own LWC container. Simply invoke it in your LWC like this:

<template>
   <c-screen-flow width='100%' height='100' flow-name='testFlow' name="uniqueName" flow-params={flowParamsJSON}></c-screen-flow>
</template>

When your component instantiates, it will load the named flow into an iframe created with the specified height and width, and pass in any input params you provide.

How It Works

Getting this to work required a bit of bricolage. When ScreenFlow initializes, it sets up some message-passing infrastructure and determines the org URL. It then renders an iframe and passes to that iframe the name of a visualforce page called screenFlow that’s provided in this package. The URL that loads the screenFlow page also contains query parameters with any input parameters.

The visualforce page has script on it that creates a lightning:flow aura component and then sends it a start flow command. More event infrastructure is put in place so that when the lightning:flow generates some sort of status change, the event it fires gets passed up to the visualforce page, where it’s converted into a message that get passed across the iFrame boundary to the parent screenFlow lwc, which will dispatch an event (“flowstatuschange”) with any output data. Your container can register to receive flowstatuschange events so it can receive the output values of the flow.

Install

Version 1.0 Unlocked 8/23/20

Source Code

View source

Keywords

Add Flows to LWC’s

I’m very pleased to again be able to share information about imminent new Flow functionality! This is a particularly strong release, possibly a match for the already-legendary Winter ’20 release. Preview Orgs can be obtained to try out this functionality.

Flow Canvas ‘Autolayout Mode’

Flow Builder now provides a canvas option called Autolayout that automatically connects elements to each other and handles layout. This simplifies the user experience and makes flow construction more consistent. 

Use the new Autolayout toggle on the Flow Builder header to switch between Autolayout and the traditional Open Canvas mode:

Autolayout mode does not currently support flows where a single non-Loop element has more than one inbound connector or where a single Loop element has more than 2 inbound connectors. 

When changing to Autolayout mode, if the current was created in Open Canvas mode, its positions will be lost, even if the user immediately changes back. We therefore recommend that users save before activating autolayout mode if changes are intended. However, if the flow is changed to autolayout mode and then closed without any saves, the original positions will still be present in the latest version.

We’re going to be very interested in feedback on the Autolayout experience because we don’t want to indefinitely maintain both modes and we think Autolayout is the future.

Trigger on Delete

Needs no explanation.

---

Universal ‘OR’ and ‘Custom Condition Logic’

You can now use actual OR logic. Oh, and Custom Condition Logic too. Everywhere in Flow. The ‘smart money’ on the Automation teams thinks this might be this release’s most popular new feature, despite the tough competition.

Multi-Column Screens (Open Pilot)

Enable this pilot to see a new component in Screen Builder: Section. Each section can be divided into up to 4 columns. Customers can use Sections to create multi-column layouts on their screens, and then embed whatever screen components they like in those components. 

Information will be posted in the Automation Trailblazer community (and here) when the pilot becomes available.

Debug-As-User

This enables you to do a debug run as a specified user. Great for testing.

This can be controlled at the org level:

Note:

• Not available in production.  Test your Flows in sandbox, please!
  
• Does not affect API calls made from client-side components, such as Flow screen components.

Visual Debugging for Autolaunched Flows

A number of debugging improvements have been rolled out for autolaunched flows:

Note the reorganized Debug Log, the improved header, and, most prominently, the visual path indicators.

Pills

Some parts of Flow Builder have been enhanced to feature pills, which allow friendly labels to be used in place of merge field syntax. 

Click on a pill to reveal its underlying value. Pills do not change existing values in any way. They simply add a label.

For example $GlobalConstant.True will appear as ‘True’

We’ll be expanding the range of pills support in the next release.

Directed Error Messages

Error messages now provide, when available, links to the element that caused the error, allowing the property editor to be quickly opened.

Insider tip: one of the reasons we did this was to pave the way for the conversion of modal property editors into panel property editors that allow you to create an element and leave it partly unconfigured without triggering error messages. The validation moves to Save-time, which makes it important to help users ‘get back’ to the source of errors. This in turn is a prerequisite for true Draft Mode.

Record Update Trigger Improvements: Query Filters

A number of Process Builder capabilities comes to Flow in this release. Now, when you create a record-update triggered flow, you have the option to select entry criteria to narrow down which records you’re automating in the first place. The Process Builder choice to only run when the criteria has just changed to meet the requirements is also now available:

---

Record Update Trigger Improvements: ‘Only When Record Has Just Changed’

As seen above, the ‘When to Run the Flow for Updated Records allows for tighter control of execution.

---

Record Update Trigger Improvements: Traversal to Related Records

It’s hard to write something catchy about field traversal. It’s just one of those things that you don’t think about until you absolutely must have it. Now available in Record-Change Triggers.

---

Import Flow Actions for Public Web Services Like Jira, Trello and eBay with External Services (PILOT)

External Services, which I think of as ‘API Action Builder’, has been enhanced to support OAS 3.0 and schemas up to 1 million characters in size. The biggest impact of this is that, for the first time, it’s possible to use External Services to bulk import the ‘schemas’ (basically a big text file describing APIs that you can call) of public web services, generating dozens of Flow Actions that directly access those web services’ APIS.

Not all web service schemas can be imported in Winter ’21. Some are longer than the current 1 million character limit. Others produce errors when you try to ingest them because of functional gaps that still need to be addressed. However, as you can see from the image above, the list of services that you can successfully ingest includes Jira, Dropbox, Instagram, Twitter, Mailchimp, eBay, and Walmart, GoToMeeting, Trello, and Medium. Here are some examples of the actions that become available for use in flows:

Note that this currently planned as a closed pilot, meaning you need to request access via your company’s Account Executive.

Expanded Access to Global Variables

Global variables, previously only available in Flow via Formulas, are now accessible anywhere you want to reference a field.

---

Flow API Versioning

For enterprises, this is the sleeper feature with the big impact.

Traditionally, changes that can cause breaking disruption have been deployed as CRUC’s that have to be carefully regression tested:

For a variety of reasons, this is burdensome, so starting with this release, the Flow engine will be versioned with the API version. Features that are deemed to have disruptive impact get versioned, which means they only are applied automatically to new flows. (Importantly, we expect that most flow enhancements will not have any breaking impact and will not need to be versioned.)

For your existing flows, you can decide on a flow-by-flow basis when to upgrade to a new version with a new version setting:

So essentially, you will no longer need to apply CRUC’s to your mature flows.

This release contains 4 versioned improvements:

• Remove unintended Next navigation from flow screens at the end of a Flow that shouldn’t be showing a Next button
  Eliminates a scenario where the Next button displays even though the ‘Next or Finish’ checkbox in a Screen element’s property editor is unchecked
• Record Variables no longer cause an error if they are used in a merge field and have a ‘null’ value
• The ISBLANK function returns true for empty strings and not just for null values.
• Enforce the running user’s data access rights when evaluating Flow formulas

So, to reiterate, the above four bug fix/improvements will only automatically apply to Flows that use version 50 or higher. All flows that were last saved on a Summer ’20 or earlier org will be assigned version 49.

Now GA: Screen Components can use Generic SObject attributes

This capability is used to deliver screen components like this Datatable extension:

Invocable Actions (aka Flow Actions) already have this functionality at GA level.

Custom Property Editor Enhancements

• Custom Property Editors for Flow Screen Components is now Generally available.
  Custom Property Editors for Flow Actions (Invocable Actions) remains at Beta, but the only work remaining is some minor packaging enhancement.

• You can now use Custom Property Editors with Actions and Screen Components that use inputs of type SObject or SObject[].
  This opens up the use of Custom Property Editors to screen components like the Datatable shown above and actions like the Collection Actions. This is called Dynamic Type Mapping and you can learn about it here.

• For developers of Custom Property Editors, a new Flow Base Components library is available that can be referenced as a dependency in your CPE.
  It provides a rich set of tools to accelerate your CPE development.
  
• Read the new Custom Property Editors Developers Guide

Next Best Action Enhancements

Support for Service Cloud Voice

Agents are now empowered with contextual, event-based recommendations in the Next Best Action and the Actions & Recommendation components based on information in Voice Call records and call transcripts. Events for call state changes, such as start call, end call, mute, hold, etc.,can be used to build event-driven solutions. 

APIs in the Service Cloud Voice Toolkit can be used to push context-sensitive recommendations based on field values in the call record and keywords in the call transcript. 

Next Best Action is invoked with key:value pairs in the Lightning Message Service message payload. The value given to a particular key can be retrieved in the Recommendation Strategy using $Request.key in the filter element as follows
$Request.key != ” && CONTAINS(Name, $Request.key)

References: 

Voice ToolKit API Pilot Guide (226): 

Voice ToolKit API Upgrade Guide (228):

HIPAA Compliance

Next Best Action has been certified compliant with HIPAA (the Health Insurance Portability and Accountability Act of 1996), certifies that NBA meets the strict standards for protection of sensitive customer information.

Einstein Recommendation Builder

Einstein Recommendation Builder (ERB) allows admins to recommend or match records from one Force.com object to another, using an AI-powered recommendation engine. It offers a point-and-click interface to support standard and custom matching problems using CRM data

Next Best Action (NBA) Integration

ERB is natively integrated with Einstein Next Best Action to surface these AI-driven recommendations as next best actions. 

Other Winter ’21 Changes

• Text Template resources now remember whether you’re viewing in Plain Text or HTML mode. This helps avoid situations where users were inadvertently entering HTML markup into their text.
• The Flow home page list view now shows the Trigger Type of each flow.
• Labels show up in Flow Interview Logs.
• Newly enforced security restrictions on guest user access mean you need to activate the recently implemented permission elevation to ‘System Context without Sharing’ if you want Guest Users to have access to flows that use the Next Best Action Recommendation object.
• When a user changes the owner of a record via Salesforce Classic, that record change can now launch a record-triggered flow

Have questions? Since these are official features, we suggest you post questions to the Automation Trailblazer community.

Moved to here.