Winter ’20 Flow Preview!

I’m pleased to report on the great things the Flow team has built over the Summer. These Flow Previews have become my favorite blogs to write because there are so many goodies to disclose. If you want to try these out immediately, get a free preview org.

Scheduled Flows

It’s now possible to schedule Flows to run on a schedule. This applies to “Autolaunched” flows (i.e. flows without screens). Double-click on the Start element to set the schedule:

Notice that you can also add a record query. At the scheduled time, Flow will run the query and then run the Flow for each returned record, providing a powerful new batch mode capability.

Conditional Field Visibility

Fields can now appear and disappear on the screen as a result of some other field or value.

This is controlled via this new section in the field property editors:

Operator Note: If you’ve just created a field, you have to close the screen and reopen it before that field can be used as a ‘parent’ field. Yes, we think this is annoying too and we’ll fix it next version (this is one of those ‘harder than it looks’ caching yadda state storage yadda yadda problems).

Automatic Output Handling

The Automation group at Salesforce is in the early stages of a multi-release campaign to simplify the process of creating Flows. This will touch nearly every part of the product. One of the first benefits harvested from this can be seen in a change to the Get Records element. As you’ll recall, when you query for a record or a collection of records, Flow requires you to define a variable of the same type to temporarily store the information. That is done here:

You then use the storage variable when you refer to the queried records in a downstream element, like this:

In Winter ’20, you no longer have to do this. The streamlined Get Records looks like this:

Automatically generated references for Get Records queries look like this:

and automatically generated references for Screen Components look like this:

Operator Notes

  • To access the ‘old way’ of doing things, click the new Manually assign variables checkbox at the bottom of the property editor.
  • Existing flows are not converted. For them, the “Manual” checkbox is checked and your existing variables and mappings remain unchanged.
  • You can convert an existing Flow to use automatic output handling by unchecking the “Manual” checkbox, but we’ll put a big warning message up, because you’ll have to fixup any downstream references that use your old variables.
  • In Winter ’20, we implemented support for this in two places: Get Records (as shown above) and Flow Screen Components. We’re working on extending this support to the remaining parts of Flow Builder that currently require manual variables.
  • In a future release, we’re going to continue to improve on this by eliminating the entire “Select Account Fields to Store in Variable” section as well.

Flow Screen Components Built with Lightning Web Components

Lightning Web Components is Salesforce’s new framework for creating fast, reusable components. Flow already has a growing set of custom screen components built using the previous Aura technology, and those will continue to work. We’re advocating that all new development of components be done in the new Lightning Web Component technology, though, and you’re going to start to see new functionality that is only available to Lightning Web Components and not to ones built in Aura.

We’ve published a blog post here that consolidates all of the important information about creating and using LWC-based Flow Screen Components.

Lookup Screen Component

It’s now easy to add a Lookup field to flow screens:

This component includes type-ahead search, and a list of recently chosen records. Here are the input parameters that you can pass in to it:

You configure it by pointing it at an existing Lookup field using the Object API Name and Field API Name fields. If you want to set its initial value, you can pass in a recordId, and you can make the field required.

Canvas Usability Enhancements

Enhancements to the canvas include:

  • Changes to Panning Behavior – Panning is now done by simply clicking and dragging the canvas around. You no longer need to enter a “Panning Mode”.
  • We’ve added the ability to drag-select multiple elements. Toggling the Drag-Select button switches from panning to selection mode. See below for an example:
  • Finally, you’ll notice in the above image, that each element has up to 2 lines of space for its name text.

Per-Profile Flow Permissions

You can optionally secure flow definitions on a per-profile basis.

New Flow List Page

We’ve refreshed the main list view in Setup.

Process Builder Enhancements

We made a couple of enhancements to Process Builder:

  • Process Builder can now trigger on Account Team Member changes. (Account Teams must be enabled in your org)
  • Some Process Builder actions can now use platform event payload data as inputs.
  • Use Process Builder with the new FlowExecutionErrorEvent platform event to generate custom notification schemes when Flow errors occur (see below).

Custom Error Message Notification Schemes

When an error occurs in Flow, a platform event called FlowExecutionErrorEvent is now fired, and you can subscribe to that event with a Process Builder trigger. This lets you use the power of Process Builder and Flow to generate custom error handling. For example, you could set things up so:

  1. If the flow error is coming from one of the Flows that start with “Europe”, send an email to Genevieve and Post to the EuroAdmins chatter group, else
  2. Generate one of those new custom notifications to my desktop, send me an SMS via a Send SMS Flow Action, and create a Case.

There are a few gotchas to keep in mind, and they’re discussed in detail here.

Fiddly Builder Things That Will Make Some People Very Happy

  • You can now activate flows directly from the canvas.
  • When you create a New Resource from a property editor or dialog box, the resulting resource is autopopulated into the text field from where you started.
  • Text Templates now again properly support rich text, although you can now toggle to plain text if you are using the template as an input to something that requires plain text (like the current Send Email action)
  • There’s a new Send Custom Notification action. It’s fun. Try it.

Hope you enjoy! At HQ, we’re now digging into the next wave of enhancements for Spring ’20. See you at Dreamforce!

Adding Lightning Web Components to Flow Screens

Note! This is a preview of Winter ’20 Functionality

For the last two years, Flow creators have been able to add lightning component to Flow Screens. This has powerfully extended the capability of screens. We’ve had a great time creating reusable components as a community, and many of those components are available for use to all comers.

The underlying web technology enabling these components, known as Aura, has served Salesforce well, but it’s more than 5 years old, and that’s a long time when it comes to changes in web technology. Salesforce recently released a major upgrade to its web technology called Lightning Web Components, and the Flow team has been working on making it possible to embed this new generation of components into Flow screens. With the Winter ’20 release, that will be now be possible, so let’s take a look at how it’s done.

In this demonstration, we create an LWC that allows the user to manually add and manage sharing settings on a record. This allows a Sharing button to be placed on Lightning record pages. The guts of this component consist of code written by resident Salesforce evangelist Shane McLaughlin.

To get an LWC to appear in Flow’s Screen Builder, you add a ‘lightning_FlowScreen’ target to the component’s meta file:

To expose attributes from the LWC, you first use @api in the LWC’s javascript, as is standard for any property you want to make accessible outside of the component:

Then you additionally specify which of these public properties should be additionally made visible in Flow by adding a targetConfig section:

The type field supports the same types that Flow supports with aura components. That includes specific Sobjects like “Contact” and specific SObject collections like “Account[]”.

Note the following syntax for specifying SObjects and Apex Classes:

  • @salesforce/schema/<name of sObject>
  • apex://<name of Apex class>
  • add array notation if it is a collection []

with a namespaced org you have to include the namespace in the type string using the namespace prefix. So, for SObjects it would look like type=”@salesforce/schema/myNs__CoolCustomObject__c” and similarly for apex type=”apex://myNs__MyApexClass”

The ‘role’ parameter can be added to property elements inside of targetConfigs. It has been created specifically to provide support for Flow’s ability to limit access to inputOnly or outputOnly. If no role is specified, the property is available in both directions.

Validation

To tie an LWC into Flow’s validation capabilities, create a function called “validate” in your js file like this:

validate() {
    if(/* true conditions */) { 
         return { isValid: true }; 
        } 
    else { 
    //If the component is invalid, return the isValid parameter as false and return an error message. 
         return { 
               isValid: false, 
               errorMessage: '/*A message that helps your user enter a valid value or explains what went wrong.*/' 
                }; 
     }}) 
}

Navigation

To programmatically transition a Flow with an LWC component, you dispatch an event using this syntax:

import { LightningElement, api } from 'lwc';
import { FlowNavigationNextEvent } from 'lightning/flowSupport';

export default class NameOfYourComponent extends LightningElement {

   @api
   handleGoNext() {
       const nextNavigationEvent = new FlowNavigationNextEvent("dummy");
       this.dispatchEvent(nextNavigationEvent);
   }
}

The supported events are:

  • FlowNavigationNextEvent
  • FlowNavigationBackEvent
  • FlowNavigationFinishEvent
  • FlowNavigationPauseEvent

These events currently require a string to be passed into them, but the actual value of the string is irrelevant, so the example above just uses “dummy”.

Sample Gists

https://gist.github.com/alexed1/e3e580103375120ca2dc1374bb4f73ff

Flow Actions for Strings: URL Encoding and Number Formatting

Arnab Bose contacted me this morning and wanted a couple of Flow Actions for transforming strings. He’s building some cool Flow and Quip integrations and needed a way to easily take a string with spaces and URL Encode it so he could put it in a URL (for example: ‘my cat’ becomes ‘my+cat’). He also had some numbers in string form that he wanted to add commas to (i.e convert 2348934 to 2,348,934).

In Apex, these are super simple because of the large library of available functions. To URL encode a string, you just write:

String encoded = EncodingUtil.urlEncode(myString, 'UTF-8');

and to format a string, you can just write:

response.outputStr = Integer.valueOf(inputStr).format()

But the fun part of Flow is not having to write code. So I created a couple of Apex Actions that carry these out:

You can install these from here.

The source code is available here and is a great template to convert other Apex string functions.

Easy “IN” Filters in Flow with the FilterCollection Flow Action

Intro Video

SOQL provides a useful IN operator that filters the query on a specific set of values:

credit: https://www.salesforcetutorial.com/soql-in-operator/

You currently can’t do this directly in the Flow Builder Get Records element, but you can install this FilterCollection Flow Action to provide the capability.

Out of the box, this action is set up to support standard objects: Contact, Account, Opportunity, Lead, Product, Case. You can easily modify it in Apex to support additional objects of your choice (see customization, below).

Installation

Instructions

For our example, we want to query for all accounts that have an Industry that’s IN Banking or Chemicals. We expect to get back three of these four accounts:

Configure this Action by passing three pieces of information:

  1. A collection of SObjects. You can pick from the supported list. At this moment, 5 standard objects are supported. You can only pass in a single collection of SObjects. Leave the other inputs blank.
  2. ‘filterField’: The name of the field on your SObject that you want to filter on. In our example we’ll set this to Industry.
  3. The target values. These are equivalent to ‘Rose’ and ‘Sean’ in the above example image. In our example, we’ll pass in Banking and Chemicals. You can pass the values in either as a single comma-separated list in the targetValuesCSVString input, or as a collection of strings in the targetValuesStringCollection (don’t use both at the same time).

Here’s an example of a properly configured set of inputs:

This action will return a corresponding collection of filtered objects. Make sure you create a collection variable of the appropriate Record type and map it in the Store Output Values tab.

Optional: Customization

The following information is for advanced Flow users and discusses how this action can be modified to support additional types of objects. A current limitation in Flow makes it so that Apex Actions have to add specific code for each specific sObject they want to support (it’s on the roadmap to eliminate this limitation). So the bad news is that only 5 common standard objects are currently supported in FilterCollection.

The good news, though, is that it’s easy to add support for additional standard objects and custom objects.

To add support for an additional object, you have to add code in four places. First, add an input variable to the Requests inner class and an output variable to the Results inner class:

To process the input collection, add a code block based on the five lines immediately below. This has the effect of casting (transforming) your specific SObject collection to a general SObject collection. Then at the end, add a when clause to the switch statement to cast the general filtered-down collection back to the specific SObject type that Flow needs:


If you do add more standard objects, please consider making a pull request to the source code so everyone can benefit from your work!

Source Code

TDX Session Video:Building Advanced Flows with Choices, Loops, and New Apex-defined Types

Here’s a broadcast of one of the two Advanced Flow sessions from TDX.

Flow Action: Get Picklist Values

In my spare time I’m experimentally rebuilding Approval Processes on top of Flow and I recently had a need for a way in Flow to retrieve a set of picklist values that I could then work with. So I built a simple Flow Action to enable all flow designers to do this without code.

It’s a little like the Picklist Choice Set resource in that you hand it the name of an Object and a Field, but it returns a collection of strings that you can then work with directly.

You can iterate through the values but one of the most useful things to do with this is to pass them into the new multiselect dual listbox screen component to let the user pick from among them.

Documentation

Provide this action with the api names of your target Object and Field. Field must be a picklist.

Install (Unmanaged Package)

Source Code

Scaling to Thousands of Screens with Lightning Flow

In the common diagnostic use case, you have a tree structure of information and you work your way through the tree, gathering information and using it to determine the next diagnostic question. This is useful for important and distinctive use cases like troubleshooting and coming up with a good offer. Here’s an example:

Now, you can see four screens in this flow, and creating four screens isn’t too hard, especially with Flow Builder’s Duplicate tool. However, what if you have 500 of these screens? And what if this content is constantly changing and you want to make it possible for non-Admins to maintain it?

There’s a great way to address this use case, and I call it the Troubleshooter pattern. In this pattern, you don’t insert the content into screen elements. Instead you insert it into records of a custom object. Then you use a single Screen to load the appropriate custom object’s content for display. Part of the content includes a set of choices that the user can use to signal where they want to go next. Each choice points to a target set of content.

Here’s the entire flow used to show the above content:

Two custom objects have been created here:

DiagnosticNode represent a screenful of information. It includes a rich text content field to display to the agent or user or technician. It also contains a radio button group that gets loaded with all of the node’s child DiagnosticOutcomes.

DiagnosticOutcome represents a single choice/answer that might come out of a particular DiagnosticNode. It will render as a radio button choice and has two important properties: the Label and a lookup to a different “Target” DiagnosticNode.

The beautiful thing about this approach is that the creation, editing, reporting, analytics of the content nodes themselves is all done with regular Salesforce records. For example, if I want to build out my tree of decisions, I first create a new target DiagnosticNode:

And then add as many different destination outcomes as I want:

Sources of Content

The flow can display content either from the rich text “Node Content” field on the DiagnosticNode custom object or from a Knowledge article. To use Knowledge, check the box on a DiagnosticNode and select the desired article.

Editing Content

A button at the bottom of the page provides easy access to the record containing the content being looked at. This makes use of a custom Flow Screen Component called Navigation Button.

git source for the full project (including Knowledge support)

Install the Sample Flow Shown Above. (NOTE: The sample does not have the Knowledge support because of a packaging problem, but it’s easy to add).

  1. To install, you may need to:Create Custom Tabs for Diagnostic Node and Diagnostic Outcome in Setup –> Tabs
  2. Turn on visibility for each of the fields in Diagnostic Node and Diagnostic Outcome (to do this, use Object Manager, select each field, and then click on Set Field-Level Security
  3. Manually create at least one Diagnostic Node to serve as your initial node. The sample flow currently asks for the ID of that initial node. Get it from the URL.

Hosting Components on UnofficialSF

When we learn about a good component, we seek to:

  1. create a page for it on unofficialsf. This can either be a Post or a Page.
  2. make sure the install instructions on that page provide links to unmanaged and managed packages.

Managed packages can be important if there are collisions between support files. For example, many components use Andy Fawcett’s metadata service. You can install a new component that has this apex class via an unmanaged package if you already have that class on your org. The Managed Package process puts each component into its own namespace.

Each dev edition org can only host a single managed package. Fortunately they’re free. If you’re trying to create a managed package for your component, do the following:

  1. Create a new free Developer Edition at https://developer.salesforce.com/signup
  2. Deploy your component to this edition and create an Unmanaged Package in the Package Manager
  3. Create a Managed Package of that component. For namespace, use usf_mycomponent, where mycomponent is similar to the name of your component. So if you’re publishing a Lookup component you might pick usf_lookup as your namespace. Use “Release” and not “Beta” in your settings
  4. Test that your packages work and then publish the links