Understanding Invocable Actions

Invocable Actions are one of the most underappreciated elements of Salesforce technology, up there with Platform Events and External Services. To complement the rather spartan official 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 start with an Apex class that does something useful with inputs and returns some useful outputs. Then you mark the specific inputs that you want to expose to admins in tools like Flow Builder, and also mark each of the outputs that you promise to provide back when your work is done.

As an example, on the AppExchange, you can install the Send SMS via Twilio flow action. Like all installable flow actions, it is built with invocable action technology.

When you install it from AppExchange, it shows up in the Flow palette:

On the Flow Builder canvas, the property editor for these Flow Actions provides a couple of tabs that allow you to specify the data you want to pass in and where you want to store the data that comes back:

This demonstrates the core value proposition of invocable actions. They allow someone to write code once, and then package it in a highly portable way that’s usable by thousands of others who will never go beyond the Flow Builder UI shown above.

Flow Actions are also great for ISV and integrator work because they can be put into managed packages and push upgraded.

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-object phrase, such as Post to Chatter or Send SMS via Twilio.

There are two 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) Choose names for your Apex Class with clarity in mind
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) Put your input and output properties in Request and Response inner classes
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 way I like 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. There’s a good example of this on the InvocableVariable doc page. Here’s another 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 convertLeads(List 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: