Understanding Invocable Actions

Invocable Actions are, in my opinion, one of the most underappreciated elements of Salesforce technology, up there with Platform Events and External Services. To complement the offical docs, here’s an introduction.

The Invocable Actions mechanism allows developers to package useful code functionality into declarative building blocks that can be used by admins and other non-coding users in a growing range of Salesforce tools, including the Flow Builder, the forthcoming Next Best Action Strategy Builder, and more. 
 When you build an invocable action, you define in your Apex class each of the inputs that you want to expose to declarative building tools and the REST interface, and each of the outputs that you promise to provide back when your work is done.
 Example, on the AppExchange, you can install the Send SMS via Twilio flow action. Like all installable flow actions, it is built as an invocable actions. When you install it from AppExchange, it shows up in the Flow palette:

Flow Actions can be installed as managed packages, so that you can push upgrades to customer orgs.

Creating an Invocable Action

To create an invocable action, first build an apex class that carries out a useful piece of work. It’s a recommended practice to orient this class around a single, focused activity that can be expressed as a verb-noun phrase, such as Post to Chatter or Send SMS via Twilio. 
 There are three key mechanisms that turn an ordinary apex class into an invocable action:
 1) Adding an InvocableMethod interface to one of the methods
 The InvocableMethod interface signals to Salesforce that this class should be exposed to consumers of invocable actions like the Flow Builder. You will place it on a single method in your apex class. InvocableMethod is discussed here.
 2) Defining and marking the variables that will be exposed as input and output variables
 You expose a variable as a public input or output on your action by marking it with the InvocableVariable interface, described here
 Recommended Practices
 1) Name your Apex Class For Clarity
 When your invocable action shows up in Flow and other action consumers, it will display the name of your class. Pick a class that follows the Verb-Noun Phrase pattern described above
 2) Group your Variables into Classes For Easier Manipulation
 The invocable action interface is designed to support bulk operations, and part of this manifests itself in the fact that the input type of an invocable action is always a List of some type. If you have more than one input variable the best way to handle it is to define a separate apex class that contains the definitions of all of the input variables. You then can pass back a List of this class. Here’s an example:
 a) here, we create a ‘Request’ class to hold all of the inputs to our action:

Here’s where the invocable method defines its readiness to receive a List of these sets of inputs:

global class ConvertLeadAction {
@InvocableMethod(label='Convert Leads')
global static List<ConvertLeadActionResult> convertLeads(List<ConvertLeadActionRequest> requests) {

Similarly, you can see how the above method signature defines the expected results as a List of a class called ConvertLeadActionResult class. We define this ‘Result’ class to hold all of the expected outputs:

In this example, when the action is called, the list of request sets is passed to the ConvertLeadAction method. For each request set, a corresponding results set is initialized and then populated with the results of the action’s processing:


Invocable Variable doc page

Invocable Method doc page

Action Developer Guide

Flow Actions in AppExchange

How to Build a Flow Action

Installable Flow Actions as Unofficial Flow (NOT supported by Salesforce)