Learn MOAR in Winter ’20 with Lightning Flow Features

Discover Winter ’20 Release features! We are sharing release highlights for Developers (and Admins), curated and published by Salesforce product experts, as part of Learn MOAR. Complete the trailmix by October 31, 2019 to receive a special community badge and unlock a $10 contribution to FIRST®.

Ahoy, Salesforce developers! We’ve made a lot of improvements to Lightning Flow over the summer and are excited to see how you’ll leverage our work to make application design choices that increase reusability, flexibility, and development productivity while decreasing code surface area maintenance costs. Today, I’d like to draw your attention to three features in particular that I think you’ll find valuable across a broad set of use cases: support for Lightning Web Components in Flow screens, rich collection operators for Apex Type collections, and scheduled flows.

LWC Components in Flow Screens

Once Winter ’20 arrives in your org, you’ll be able to start exposing your custom Lightning web components for direct consumption in Flow screens, side-by-side with your custom Aura components.

Exposing a Lightning web component for consumption by Flow is easy. Inside the component’s js-meta.xml file:

  1. Add lightning__FlowScreen as a target to the targets list.
  2. Declare the input & output fields that you want to expose to flows as properties in a targetConfig.
    In the example below, we’ve declared three input/output fields:

    1. items, a list of CartItem objects (defined as an Apex class).
    2. isAmendable, a boolean that determines whether items in the component can be amended by the end user.
    3. cartSize, an integer that represents the number of items in the cart.

That’s it! Your LWC will start showing up in Flow Builder’s screen components list (under “Custom”), the properties you’ve chosen to expose to Flow will show up on the right, and you get all the wonderful goodness that you’ve come to expect from Flow — referential integrity, design time input validation, and packaging ensuring that all needed resources are included.


The screen above combines a standard Flow screen component (in this case, a rich text field), a custom Aura component (StageIndicator), and a custom LWC (showShoppingCart) without the need for any more code than what’s in the actual components themselves.

We hope this functionality will really help to enable the low-cost composition of, and iteration on, screens comprising elements backed by different technologies. For example, suppose you’ve deployed your Flow application to UAT, and preliminary user testing has exposed that:

  • Some text on Screen 1 doesn’t read quite as smoothly as intended.
  • Form A presents an input field ordering that creates a choppy end-user experience.
  • There’s a data table element that needs to have certain columns editable in the earlier stages of the business process, and locked in the later stages of the business process.

As long as you design for reusability and flexibility, you can implement all the necessary improvements without having to change, test, and deploy any lines of code!

Data types

Avast! A wide array of data types are supported for use as properties in a lightning__FlowScreen targetConfig:

  • Boolean
  • Integer (the min and max attributes are not supported if the target is lightning__FlowScreen)
  • String
  • apex://namespace.Classname — An Apex class used for an Apex-defined data type, supported only if the target is lightning__FlowScreen.
  • Date — A date in ISO 8601 format, supported only if the target is lightning__FlowScreen.
  • DateTime — A datetime in ISO 8601 format, supported only if the target is lightning__FlowScreen.
  • @salesforce/schema/namespace.Objectname — An object, supported only if the target is lightning__FlowScreen.

Classname — The name of the Apex class.
Namespace — The namespace of the Salesforce organization, specify a namespace unless the organization uses the default namespace (c), in which case don’t specify it.
Objectname — The name of the object.
Add array notation [] to the end of a data type declaration for a list.

Apex Type collection operators

This work is part of our ongoing investments in making integration easier. To refresh your memory, an Apex Type is an object, defined in Apex as a class, which can be instantiated and used as a variable in Flow.

For example, here’s an Apex representation of a shopping cart item. It’s got six fields and a custom equals method.


And here’s how that representation is reflected in Flow!

By checking the box, Allow multiple values (collection), we’ve denoted that the variable, MyShoppingCart, is actually a collection of CartItem Apex-defined objects.

This allows you to manipulate and perform array logic on the collection directly inside Flow using our new Apex Type collection operators. or example, you can send a customer down a particular path based on the contents of the collection.


Or transform the collection itself.


We hope this functionality makes it easier to practice the separation of concerns. By bringing the presentation and business logic layer into a declarative tool like Flow, you can not only iterate faster, but also enable less-technical users in your organization to learn, update, and maintain the aspects of applications that you want them to own.

Scheduled flows

Last — but certainly not least — you can now set auto-launched flows to run automatically on a schedule.


The above example illustrates a flow that is scheduled to run every day at 12:05 PM, against the subset of Applicant records where Starting_in_2_weeks__c == True.

Please keep in mind that autolaunched flows can not only execute logic & CRUD, but also call invocable Apex. We hope this gives you a handy alternative to whipping up a new Schedulable class every time a new schedule-driven work item pops up on your backlog.

Scheduled flows are subject to their own set of limits, independent of the Apex Scheduler limits, namely:

  • The maximum number of scheduled Flow executions per a 24-hour period is 250,000 or the number of user licenses in your organization multiplied by 200, whichever is greater.
  • The usual limits governing auto-launched flows:
    • Up to 50 versions per flow
    • Up to 2,000 elements executed at runtime
    • Up to 2,000 active auto-launched flows at any time
    • Up to 4,000 total auto-launched flows at any time

Conclusion

The three features we discussed today (Lightning web components in Flow, Apex Type collection operators, and scheduled flows) are just a few of the many features that the Flow team has delivered in service of making you & your teams more successful. We’re deeply grateful for the support and feedback that you’ve provided us across every channel, and remain committed to making it ever easier to develop & maintain process-driven applications here on platform.

Stay tuned for a fresh batch of Trailhead content in the coming months! If you’d like to learn more about Flow, please check out our Trail. Also, check out our unofficial blog, where members of our extended community post all sorts of nifty tips and tricks to get the most out of Flow.

About the author

Tim Peng is the PM for the Flow engine. When he’s not fussing about data models & APIs, you can find him in the snack section at Trader Joe’s or obsessively researching his next travel destination.

Leave your comments...

Learn MOAR in Winter ’20 with Lightning Flow Features