Lightning Flow Local Actions — Summer Update

The Local Actions feature in Lightning Flow becomes generally available in the Summer ’18 release of Salesforce. This feature extends the range of things you can do with flow by allowing lightning component-based flow extensions.

Flow has long had the ability to incorporate extensions that leverage Apex classes and recently gained the ability to leverage arbitrary REST endpoints via the Open API specification (aka Swagger) via Salesforce’s External Services feature. However, both of those technologies execute in the Salesforce cloud, while Local Actions execute, like all lightning components, on your device in the browser.

The first thing this allows you to do is Browser Integration. The browser provides many useful features that websites use extensively, such as popping up alerts and playing sound. Available Local Actions that can be installed into your Salesforce org include Load Web Page, Play Sound, and Show Toast.

Another powerful capability is Direct Data Queries. Local Actions can make RESTful calls, and these calls travel directly from your browser to the target web service without going through the Salesforce cloud (which is how RESTful calls made via Apex and External Services work). If you have on-premises data services or a private cloud, you might like this ability to avoid round-tripping through Salesforce and an external port in your firewall.

A third powerful feature enabled by Local Actions is Improved Flow Finish Behaviors. As Salesforce has improved the range of places where you can insert a flow, the need has grown for greater control over “what happens when the flow is done?” You can now insert flow elements at the end of your flow that result in the loading of a new web page, navigation to a specific salesforce record, and navigation to a related list. And definitely check out the new Navigation Buttons.

Running Local Actions in Summer ‘18

Local Actions are generally available in Summer ’18. You only have to make sure that your org is properly configured to use lightning components. To do this:

  1. you must have My Domain enabled and deployed
  2. you must have the “Enable Lightning Runtime for Flows” checkbox enabled in Setup — Process Automation Settings

You do not need to be using the lightning experience to use these flow extensions, but if you’re running in the classic experience you need to use the lightning flow component on a visualforce page. (Furthermore, some of the local actions use force events that do not run properly when you run flows from Flow Setup, which doesn’t use a standard implementation of the lightning container. Those local actions are the “navigate” actions.)

Transitioning Spring ’18 Local Actions to Summer ‘18

If you have local actions that you’ve built yourself on a Spring ’18 org, you’ll need to modify them to run on Summer ’18, because the interfaces changed.

If you installed packages from lightningflow.net, look for new Summer ’18 versions here now.

If you built your own, more information is provided here.

Flow Extensions April Update

  1. Lookup component now offers filtering

Due to huge code contributions from Eric Smith and datapharmer, the Lookup screen component has been substantially enhanced.
a) You can now filter the Lookup component based on a particular field:

b) but you can also choose to filter based on a where clause.

For example, if you wish to return only accounts of type “Vendor” or “Partner” you could enter the Object Name: “Account” and the where clause: “Type=’Vendor’ or Type=’Partner’

c) Finally, you can even create Dependent Lookup components, where the user looks something up in component 1, and then component 2 is filtered baed on the component 1 selection:

2. New NavigateToSObject Local Action

This great new action component from Salesforce Flow VP Arnab Bose provides a powerful new tool for controlling finish behavior. For example, you might have a flow that generates a work record. At the end of the flow, you can use this component to load the work record into your browser automatically.

Note that like all Local Action, this one requires that Spring ’18 orgs be enrolled in the open pilot, which you can request from support. Summer ’18 orgs will have this functionally generally available.

3. Summer ’18 versions of Local Actions Available

Summer ’18 orgs are starting to become available over the next 8 weeks. If you have one, your Spring ’18 Local Actions will stop working because of some changes made to interface names. However, Summer ’18 versions of all of the local actions at www.lightningflow.net are now available.

Flow Extensions March Update

1. Dynamic Question can have default settings

Version 1.1 of DynamicQuestion allows defaults to be set for each question, including the parent question. These default values can be a string or a Flow variable. Based on a request by JodieM. Get the new version here.

2. New MultiShim Flow Screen Component

This simple little component makes it easy to add extra padding/spacing to your Flow screens and make them line up better. Get MultiShim here.

3. Lightning Input, The super uber lightning input, by Ryan McConnell

I can’t even begin to tell you all this things this control does. It can do time. It can do sliders. It can do radio buttons. It’s basically a universal input control built by the Lightning Platform team, and now made available for Flow. Here’s a set of four lightningInput controls, set to the following types: color, slider, telephone, and week.

Get it here. Ryan McConnell, an engineer at Salesforce, built this sweet Flow component.

4. Send Email via SendGrid

This is the first Flow Extension that taps into the power of a non-Salesforce web service. Of course, Flow has a built-in Send Email element. But some users may want to use the powerful SendGrid messaging and templating services. Get it here.

5. Learn about Navigation Overrides.

Here’s an attractive new Flow you can install that demonstrates a couple of useful new tricks. It shows off the MultiShim component described above. And this flow also demonstrates how easy it is to override the Next and Previous buttons with two lines of Javascript and use attractive images as Flow Screens.

Check out the video here.

Adding Custom Images to Flow Screens and Overriding the “Next” and “Previous” buttons

So a VP asks me to build a Flow demo for him, and I do. But he wants it to have more visual sizzle. He even gives me a nice piece of stock photography, along with a version where the wheels are highlighted.


So I built a little custom component and made a video. In the first half I’m talking about MultiShim, an installable Flow Screen Component that adds line padding. But in the second half, I demonstrate how to override the next and previous buttons, and how to wire some custom images into a simple lightning component and use it as a highly visual flow screen.

Try It In Your Own Org

This demo has been packaged up and is installable via this link*.

*If you run into an External Sharing Settings error, make sure you’ve enabled External Sharing Model in Sharing Settings.

The package includes four lightning components: MultiShim, a Datatable variant that displays Repair_Procedure__c custom objects, CustomCarPicker, which contains the images and mouse logic, and DateTimePicker. It also includes several images as Static Resources, and the core Flow, called AutomativeServiceFlow.

MultiShim, a new Flow Screen Component to let you pad your screen sizes

Was building a demo at Salesforce and the VP says, he says to me “can you do something about the black space that can be seen when you go from one flow screen to the next and the first screen is large and the next screen is really small?” And it occurred to me that I’m used to that bounce effect but it’s hardly attractive.

So I built a simple little Flow Screen Component that simply adds a specified number of blank lines. It just adds </br>’s to itself and then renders a bunch of blank space.

See it in action in this video, and install it into your org from the components section at www.lightningflow.net

Lookup, a Flow Screen Component

Watch the Video. Go get this component

I’m pleased to get to present this useful new component. Now you can add multiple Lookup controls to Flow Screens without writing code.

This component is based on the excellent Lightning Lookup control by John Pipkin and Opfocus. They did all the heavy lifting, and all I had to do was create a thin wrapper to wire up the attributes to Flow. Those four attributes are:

Object Name: Type the name of the object that you want this control to lookup. You can use custom objects but don’t forget the “__c”

Display which Field: You get to choose which field actually shows up in the combo box and gets searched on. Usually you’ll just want to type “Name” here but you can use any text field

Field Label: This is the label of the control itself

Output which value?: You can separately decide which field should be extracted from the selected object and passed to Flow. For example, you might want to display Name but output Id because Id is easier to work with for some Flow Actions.

There’s also an Output Value attribute that’s used on the Output tab to map your selected value to a Flow variable.

Hope this is useful! If you want to customize this control, the source code is available here.

A Useful SFDX Login Script

Once you have headless SFDX auth working in your development environment, you can start to leverage it by building build automation. Here’s a simple script I’m using to bootstrap my SFDX environment. I run it every time I start up a new session:

#!/bin/bash -x
echo “Starting Dev Environment”

if [[ $# -eq 0 ]] ; then
 echo ‘you need to pass in a string name for your scratch org’
 exit 1
fi

echo “authenticating to devhubtrial2”
sfdx force:auth:jwt:grant -i 3MVG9mclR62wycM2eQwLGugMMMWe5zQvP33hzD_0yCIWytEEI73gZsu8wtNti51PfxuTT_p0F6BrRyAeCVQjN -u [mydevhubusername] -f ~/dev/certificates/server.key — setdefaultdevhubusername
echo “creating a new scratch org”
sfdx force:org:create -a $1 -s -f config/project-scratch-def.json -d 2
echo “install testing environment”
sfdx force:lightning:test:install -u $1
echo “pushing project to scratch org”
sfdx force:source:push -u $1
echo “upload test fixture data”
sfdx force:data:tree:import -u $1 -f data/[my fixture objects].json
echo “get web url for manual open”
sfdx force:org:open -r -u

This takes a couple of minutes to run but doesn’t need any attention while it’s going, and at the end, I have a new scratch org fully loaded with my project and fixture data, ready to go.

The scratch orgs that this script creates are set to expire in just 2 days. That’s because, with a script like this, it’s so easy to create them that you end up bumping up against the limit on total orgs!

Dependent Picklists, a Flow Screen Component

NOTE: This component is basically obsolete. Flow now includes a dependent picklist as an official component. You should have a good reason to bother dealing with the community component, which paved the way and served nobly, but is now deservedly retired.

Watch the Video . Get the Source Code . Go get this component (not recommended)

Flow users have been asking for a one-screen dependent picklist solution for a long time. For those not familiar with this UI combination, it works like this:

Starting with a single set of choices that comes from a standard Salesforce field of type “picklist”…

Depending on the value you pick….

…you get a different set of choices in the second, dependent selection control:

DependentPicklists is an installable Flow Screen Component that works on Spring ’18 and later orgs. Each pair of picklists can be configured using the standard Cloud Flow Designer tools. This is what the control shown in the above images looks like, configured:

Let’s walk through the process of setting up a dependent picklist:

  1. Enable your org to run Lightning Components in Flow Screens. You need to have the “Enable Lightning runtime for flows” checkbox checked in Process Automation Settings, and you need to have My Domain configured.
  2. Install the DependentPicklist component. We’re working on making this component installable from AppExchange and possibly part of the included set of base screen components in the future, but for now you need to install it yourself.
  3. Add it to a Flow Screen. This is described here.
  4. Configure it. (See Configuring a DependentPicklists Component, below)

Configuring a DependentPicklists Component

The control consists of a “Parent” selection control and a “Dependent” selection control. The main job you have, when you configure this control, is to tell the control, for every possible value that can be selected in the Parent control, which dependent picklist to use to populate the Dependent control. Let’s look at the picklists we’re using in the example visible above:

For the Parent select, we’re going to use the IssueType Picklist custom field, which looks like this:

Step 1: Configure the Parent Control

For this control you need to tell the component which object and field to use to populate the Parent select control. Simply type the object and field names into the attributes Parent Object Name and Parent Field Name:

Step 2: Link each Parent Value to a Dependent Picklist

There are three possible values for this Parent control, so we need to provide the component with guidance for all three possibilities.

To do this, in Flow, you enter a pair of values:

  1. a specific possible “choice”, such as “PrivateBank”
  2. if that choice is selected, what dependent picklist should be used for the Dependent controls.

This image shows two of the three pairs of information:

The interpretation should be pretty clear, if the user selects the value International in the Parent control, the component will go and find the picklist values from that field.

Note that while the component assumes by default that all of the dependent picklists are on the same object as the Parent, you can specify a picklist on a different object, by entering it like this:

Account.MyOtherPicklist__c

3) Map your Output Values

As always you need to map your output values to Flow variables so you can do something productive with the values entered by the user.

The two output values are shown here:

Hope this is useful! If you want to customize this control, the source code is available here.

Finally, I want to give a special shoutout to Piyush Soni. I used a lot of code from his solution for using APEX to get field describes. Nice work, Piyush!

Note that this is not an official Salesforce product or release.

Watch the Video . Get the Source Code

Adding Flow Screen Components to a Screen

A growing set of powerful yet easy-to-use screen components are available to Flow users.

I wanted to provide a little documentation for how screen components are added to screens. Once your org is updated to Spring ’18 or later, you’ll find a new Lightning Components choice at the bottom of your list of screen controls in Cloud Flow Designer:

Simply drag the control over to the right and drop it where you want it to go in your screen.

When you click on a Lightning Component screen element on the right, you can give it a title and then you need to select the component you want to use:

Read the documentation for your component to determine which inputs and outputs you should hook up.

Dynamic Questions in Lightning Flow

It’s now possible to create dynamic questions, where child questions appear and disappear based on the selection made in the parent question.

Here’s a video that demonstrates just a few of the useful things you can do with dynamic questions.

The implementation of dynamic questions takes advantage of Lightning Flow’s new ability, as of Spring ’18, to insert lightning components into flow screens. Using this, we’ve built a lightning component that produces dynamic questions upon request, and packaged it so that you can use it without touching code.

For more information, see https://github.com/alexed1/LightningFlowComponents/tree/master/flow_screen_components/dynamicQuestionFSC