Transitioning Spring ’18 Local Actions to Summer ’18

This Pilot Update is for Salesforce customers participating in the Spring ’18 pilot for Flow Local Actions.

Local Actions that run on Spring ’18 orgs are not compatible with Summer ’18. Summer ’18 versions of the sample actions made available as part of the pilot are available on this site and will need to be installed when your org running Local Actions is upgraded to Summer ’18.

You may need to remove the old Local Action from any flows in which you’ve installed it. (If you are getting an error message Error parsing file: 'localAction' is not a valid value for the enum 'InvocableActionType' then you have a flow that still has a saved reference to the old version. See “InvocableActionType Change”, below.

For Developers of Local Actions

If you have created Local Actions using the Spring ’18 pilot, you will want to be aware of the following:

Existing Local Actions require the following changes to work with Summer ’18:

  1. The marker interface has changed from flowruntime:availableForLocalInvocableActions to lightning:availableForFlowActions. This change is made in the “cmp” file of your lightning component file set.
  2. The “callback” mechanism has been removed. Both of these lines, which will exist in Spring ’18 local actions, must be removed to work on Summer ’18. If you wish to pass success vs. failure information at the end of your local action, you can do it one of two ways:
    1. create a variable and set its value, and then have the flow subsequently decision on that value
    2. use the recommended async approach, involving Promises (see the release notes and developer guide documentation, available soon).

Other transition notes:

We encourage builders of Local Actions to use promises. An example of that is available in the release notes for Summer ’18. An example of the recommended form is shown below.

InvocableActionType Change. If you have created flows that use local actions, InvocableAction enum in the Metadata API, the enum value for a local action has changed from “localAction” to “component”. One place this manifests if if you have extracted metadata for a flow that had a local action. The file will have a section that looks like this:

<actionCalls>
 <name>Success</name>
 <label>Success</label>
 <locationX>595</locationX>
 <locationY>431</locationY>
 <actionName>c:showToast</actionName>
 <actionType>localAction</actionType> 

In cases like this change “localAction” to “component” to avoid the error message:

Error parsing file: 'localAction' is not a valid value for the enum 'InvocableActionType'

Recommended Form for Invoke Methods as of Summer ’18

 invoke : function(component, event, helper) {
           var args = event.getParam("arguments");


           return new Promise(function(resolve, reject) {
               var xhttp = new XMLHttpRequest();
               xhttp.onreadystatechange = $A.getCallback(function() {
                   if (this.readyState === 4) { // DONE
                        if (this.status >= 200 && this.status < 300) {
                            var response = JSON.parse(xhttp.responseText);
                                component.set("v.churnVal", response);
                                resolve();
                        } else {
                            var errorText = "";
                            if (this.status === 0) {
                                errorText = 'Request has been terminated\nPossible causes: the network is offline, Origin is not allowed by Access-Control-Allow-Origin, the page is being unloaded, etc.';
                            } else {
                                errorText = this.statusText;
                            }
                                reject(new Error(errorText));
                        }
                    }
               });
               var customerId = component.get("v.customerId");
               xhttp.open("GET", "https://upp57qbj5b.execute-api.us-west-1.amazonaws.com/production/customer/"+customerId+"/churn", true);
               xhttp.send(null);
           });    
        } 

Strategy Crafter: Introduction

Overview
Strategy Crafter is a lightweight graphical tool for editing and managing Recommendation Strategies for Einstein Next Best Action. It is not an official Salesforce application. It was built by some members of the community. The real Strategy Builder will be delivered as part of later releases of Einstein Next Best Action. In the meantime, though, the Crafter can simplify the work to build and maintain Strategies.


Understanding the Strategy Pipeline

The Strategy is a new Salesforce element that lies at the heart of creating great recommendations. Information about Strategies is available in the official Salesforce pilot documentation, so these tool docs will assume you know about them.

Automatic Saving
Changes to strategies are automatically saved in the background and all strategies are implicitly ‘Active’ just like all changes to Salesforce records immediately take effect. There is no automatic versioning (as there is in Lightning Flow). You may want to use the Duplicate Strategy menu items to create copies. There’s also When you click Save in the Crafter, it deploys an XML metadata version of the current strategy to your org, overwriting any version that’s there.

Export and Import
Under the covers, the main purpose of this tool is to help you generate the complex XML documents that drive Salesforce. You can export and import these easily from the menu.
 
 Strategy Crafter ONLY WORKS WITH SUMMER ’18 ORGS.

Installation

Using Strategy Crafter

After installing, you should find a Strategy Crafter tab in the App Launcher. Select it to load the Strategy Crafter.


Loading a Strategy
 When you first install, you will probably not have any saved Strategies, so you should either create a New one from scratch or use the Import from XML menu item to paste an existing one in as XML. Here are some sample xml files in 214 XML format
 
 
 Activating/Publishing a Strategy
 Saving a Strategy deploys and activates it. Once you save a Strategy you should be able to configure the Next Best Action lightning component by providing the name of the Strategy, and it should start to produce Propositions.

Learn More: Tutorial 1

Reporting Issues

  1. Email them here for now.

Strategy Crafter Home

moved here.

moved

Flow Extensions — May Update

We’re keeping busy getting ready for the Summer ’18 release and doing the planning for the work that will go into Winter’ 19. Here’s what’s new in the component world:

  1. New Navigation Buttons give your screens enhanced finish behavior.

Watch the video

2. Local Actions are about to go Generally Available, with Summer ’18.

Read the Local Action update.

3. Navigation to Related List is the latest Flow Action

Check it out here.

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