Local  Actions are now generally available.

Introduction Presentation

Flow Action Components Documentation

Flow Action Components

Sample Action Components source

Learn more about Direct Data Queries

FAQ

I can already do these things in Lightning code, so why should I use Flow Actions?

Flow Actions are intended primarily for non-developers. Things like notifications can be done without writing any code. If you have the skill to build a Flow Action, we encourage you to publish it and make it available for others to install!

Lightning components support CORS calls today as long as the target site is configured in CSP Trusted Sites. So if Flow is using Lightning component  is there a use case or need to use Local Actions to make cross domain calls?

The benefit of using a local Flow Action for web service requests is mainly that you won’t have to write any code yourself.

Since External Services can handle authentication as well is there much need to use Local Actions?

External Services are powerful but have a few limitations. For one thing, they go through the Salesforce Cloud and require a firewall entry point to access a company’s on-premises servers. Local Flow Actions can be set up to make Direct Data Queries to on-premises servers. Also, External Services don’t provide access to Browser features like page creation and toast display.

However, the authentication used by External Services is handy. You can create a Named Credential and use it to get access to a web service.  We anticipate that may  Flow Actions will also use Named Credentials to establish OAuth connectivity to web services.

Getting Started

Enabling your org for local Flow Actions

In the Spring ’18 release, you can request that your org be enabled to use local Flow Actions, also known as Local Actions. Make this request through customer support.

Note that your org must be able to run Lightning Components. That means that it must

1)  have My Domain setup, and

2)  The “Enable Lightning runtime for flows” checkbox must be checked in the Process Automation Settings part of Setup.

Considerations for using local Flow Actions

Each local Flow Action works in concert with a Lightning Component,  and Lightning Components require a computer to run on. As a result, flows with local Flow Actions  can only be used in Screen-Based Flows.  The same technology that ensures that your local machine can render a screen on your computer ensures that the javascript inside the Lightning Component will be able to run.  Autolaunched Flows, which do not have Screen elements, execute on the server and cannot be used with Local Actions.

We recommend that you not use html markup in the Lightning Components that you use with local Flow Actions. In this respect, local Flow Actions are different from their cousins, the Flow Screen Components,  The reason for this is that local Flow Actions tend to execute very quickly, and any markup you add to them will likely flash on the screen and disappear before the user can make sense of it. Local Flow Actions are best used for work that takes place in the background. If you want to take advantage of Lightning Component markup and display UI to users, you should use  Lightning Components as Flow Screen Fields.

Which Method of Integrating Lightning Components into Flow Should You Use?

Introduction

A local Flow Action is basically a Lightning Component optimized for use as a standalone node in a flow definition.

Preparing your Lightning Component for Use With Flow

1) Add the Local Action interface to your component

The component must include the following marker:

 implements=”flowruntime:availableForLocalInvocableActions”

Note that this will be changing in the Summer ’18 release to:

implements=”lightning:availableForFlowActions”

2) Add an Invoke method that calls the “callback” function passed from Flow

Flow will attempt to call an Invoke method in your component, so you need to have one there in your controller. It will pass a parameter called “arguments” that contains a callback function called “callback”. Here’s an example of code that extracts the callback and then uses it:

 invoke : function(component, event, helper) {
 .
 .
 .
    component.get("v.scriptLoaded").then($A.getCallback(function() {
           
             //do some stuff using the loaded external script
            
            callback("SUCCESS");
            }
            
   }

If you return “ERROR”, then the Fault path of the Node will be executed, giving you the opportunity to specify a recovery path. (Summer ’18: If you fail to call the callback function during your processing, it will time out after 2 minutes.)

When the status is ‘ERROR’, the callback function takes a second parameter for the error message.

Working with External Scripts

If you want to require additional javascript, you need to add it as a static resources to your org and then require it using the

mechanism as shown here: 
 .

Timing can be tricky with this, so you should  use onScriptsLoaded to make sure the scripts are loaded before you try to use them. Here’s an example of this:

In the cmp file:

In the controller file:

init : function(component, event, helper) {
        component.set("v.scriptLoaded", helper.defer());
    },
scriptsLoaded : function(component, event, helper) {
        component.get("v.scriptLoaded").resolve(true);
    },
    
 invoke : function(component, event, helper) {
 .
 .
 .
    component.get("v.scriptLoaded").then($A.getCallback(function() {
           
             //do some stuff using the loaded external script
            
            callback("SUCCESS");
            }
            
   }

In the helper file:

 defer : function() {
            var res, rej;
            var promise = new Promise(function(resolve, reject) {
                res = resolve;
                rej = reject;
            });
            promise.resolve = res;
            promise.reject = rej;
            return promise;

Whitelisting External Targets (CORS)

If you’re doing callouts to some external server, you need to do the following:

  1. Add an entry to your org’s global whitelist. It can be found in setup -> CSP Trusted sites. Just add an entry for the server you wish to connect to, eg “www.google.com” and give it a name.
  2. Enable CORS on the external server. This generally involves adding a special header that responds to the OPTIONS http call. Here, for example, is the documentation AWS uses to explain how to enable CORS on the Api-Gateway service. Here is a good general purpose resources.

Local Actions are a new kind of Lightning Flow node type. They appear in the Cloud Flow Designer and can be added to Flows.

Local  Actions execute like regular flow elements, but they do so on your computer, leveraging Lightning Components. Like Lightning Components, Local Actions can interact with your computer and make flexible connections to the web.

Local  Actions is a open pilot feature. That means that the feature is likely to change and may not become a Generally Available feature. To get access to this pilot, contact customer support and request that they enable you for the Local Actions pilot.

Installing Flow Local Actions

The library of available  Local Actions is here.

To install a Local Actions, follow these install instructions.