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.

Notify of
Inline Feedbacks
View all comments

Truly great, it allows me to finally refactor my Aura Lightning Data Table wrapper as generic LWC! Great stuff.

Eric Smith


Looking at your examples above I see that you are using value=”{U}” in a property tag. I don’t think that tag supports a ‘value’ attribute.

[…] To learn how to build screen components that support dynamic sObjects, go here. […]


Trying to figure out some nuances, is there a way to pass the user configured sObj down to the LWC? In other words, here’s a quick example:   The following design file works fine and is able to capture a record collection: <targetConfig targets="lightning__FlowScreen"> <propertyType name="sObj" extends="SObject" label="Object"/> <property name="recordCollection" label="Record Collection" type="{sObj[]}"/> </targetConfig> And the following console.log inside the LWC all produce nothing: @api objectApiName; ... // all produce undefined console.log(this.objectApiName); // a stretch, maybe the LWC picks it up console.log(this.object); // doubtful that label will be passed in console.log(this.SObject); // yep, doesn't have anything here console.log(this.sObj); // surprised… Read more »

Rutger Gernandt

Is there a known issue when you want to push a flow using a component with a dynamic type to another scratch org? When you create a flow in a scratch org, utilizing a LWC that has a dynamic type implemented, it is possible to get this working flawlessly. However when you pull the flow to your source and then try to push it to another scratch org you will get an error stating: ‘Screen component ‘ComponentName’ is missing a type mapping ‘TypeVariableName’. Seems the propertyType variable is not yet defined in the xml defining the flow? Hope somebody knows… Read more »

Rutger Gernandt

Thanks for the quick reply and heads up! It ended up to be api versioning after all: namely the optional api setting in the config file that suddenly appeared by after a pull from the git repo and caught my by surprise.