PREVIEW: Using Dynamic Types with Flow Screen Components

NOTE: This functionality requires a Summer ’20 org. (To sign up for prerelease Summer ’20 orgs, watch here for the link that will be made available).

In Spring ’20, Flow added to its invocable action support the ability to use input and output attributes with generic types of SObject or SObject[]. This allows for the creation of powerful new types of actions that you can install and build.

In Summer ’20, Salesforce extends this capability to Flow Screen Components written using Lightning Web Components, released as a Beta. This will empower components like datatable, which provides a list view. We’ve had some great datatable implementations available on this site, but if you look into them you’ll see that they’ve suffered because of this limitation. Some implementations only support a handful of standard objects. Supporting custom objects required code modifications. If you have, for example, a custom object called QuoteRequests__c, and you wanted to display a collection of quote requests in a nice list view, you had to craft a version of datatable in code specifically ‘tuned’ to accept QuoteRequests. This isn’t a huge impediment to developers, but we really want to get great components like this published in a state where admins can use them without going anywhere near code.

So, with Summer 20, LWC’s gain the ability to expose attributes of type SObject and SObject[] and Flow gains the ability to use them.

Configuring an LWC to Expose Generic Attributes

This configuration is done in the existing component meta xml ‘design file’. Let’s take a look at an example:

<targetConfig targets="lightning__FlowScreen">
    <propertyType name="T" extends="SObject" label="Object API Name" description="Select the api name of the SObject this component is going to be looking for" />

    <property name="selectedRecord" type="{T}" label="The selected Record" role="outputOnly" description="The SObject the user has selected" />

Setting up generic attributes is a two part process. In the first process, you define a propertyType that extends the existing SObject type that’s part of Lightning Web Components framework, and you give it a name. Here’s the name of the type is a single letter “T”. It could actually be anything you want, but it’s a standard convention to use single letters to help the reader recognize that they’re looking at a type and not a variable.

The second part of the process is to define your generic properties and set their type to be the type you’ve defined. Note the use of braces in the property element. The braces signal that a replacement is needed and Flow will duly replace the {T} in the property name with the appropriate type selected by the user when they add the component to a screen and edit its property editor.

For collections, you use the same ‘extends=”SObject”‘ in the propertyType and then tack on some brackets in the property. Note that you can actually have a mix of collection and singleton records extending from the same property type:

<targetConfig targets="lightning__FlowScreen">
    <propertyType name="U" extends="SObject" label="Incoming Records" description="Which kind of records are you passing in this time?" />   
 <property name="incomingCollection" value="{U[]}" type="String" label="inputCollection" />
 <property name="someRecord" type="{U}"   label="anotherRecord" />

Once you define a propertyType, you can use it for more than one property, and you can have multiple propertyTypes, each with its own name, in the same targetConfig.

Note that all of this functionality only works with the lightning__FlowScreen target.