Invocable actions are methods annotated with @invocableAction. This annotation accepts two named parameters: Label and Description. Label is the word or phrase the process builder will associate with your method. Description is the friendly what does this do text that appears in the Process Builder alongside the label.

In practice, this looks as follows:

Public class myInvocableAction {
@invocableAction(label='BestActionEver' description='Seriously, it's the best action ever')
  public void bestActionEver(List<Account> accountsOfDoom){
    // do stuff
  }
}

As an astute reader, you've no doubt noticed that our method accepted a list of accounts as a parameter. The good news is that invocableAction annotated methods can accept a single parameter; the bad news is that there are some constraints. Primitive Objects, such as Integer, String, and Double, concrete sObjects, such as Account, Contact, Opportunity, and custom sObjects, such as MyCustomSObject__c, can all be passed into invocableAction annotated methods. Additionally, Lists, including lists of lists can be passed in, so long as each list contains concrete sObject types. However, lists of generic sObjects (List<sObject>) tag or even the generic Object cannot be passed in.

At first glance, this can seem like an excruciating limitation. After all, if we cannot pass in a generic sObject, we have to duplicate the action for every sObject type in our system. However, there are two methods to overcome this, which should be pointed out. If at all possible, utilize a List<Id> for input. Regardless of the type of object referenced, the ID type will match the reference. This allows you to send multiple object references into the method at once. Note that even though lists are ordered, you should still be using the ID instance method getSObjectType() to verify the IDs passed in. The code looks something like this:

Map<Schema.SObjectType,List<Id>> InputObjectsByType = new Map<Schema.SObjectType,List<Id>>();
For(Id i:InputIds){
  Schema.SObjectType t = i.getSObjectType();
  If(InputObjectsByType.containsKey(t){
    InputObjectsByType.get(t).add(i);
  } else {
    InputObjectsByType.put(t, new List<Id>{i});
  }
}

Dropping the input values into a map by their sObjectType tokens allows you to grab objects by their token names, facilitating easy access to multiple kinds of input objects.

If, however, you'd like to avoid doing more SOQL queries, it is possible to construct custom objects annotated with @invocableVariable and utilize these in your InvocableMethod. Like invocableMethods, invocableVariables are created via an Apex annotation, @invocableVariable, that accepts three optional parameters: Label, Description, and Required. The first two function identically to their invocableMethod counterparts. The Required parameter allows you to force a value to be passed in. The invocableVariables object can exist in inner or child classes of a class containing invocableMethods. You can utilize these inner classes as the input type for your invocableMethod method. Consider the following example:

public class IM_EasyCalc {

  public class additionInput {
    @invocableVariable(Required = true Label = 'First Number' Description = 'First number to add')
    public Integer first;
    @invocableVariable(Required = true Label = 'Second Number' Description = 'Second number to add')
    public Integer second;
  }

  public class additionResult {
    @invocableVariable
    public Integer result;
    public AdditionResult(Integer a, Integer b) {
      this.result = a + b;
    }
  }

  @invocableMethod(Label = 'Add' Description = 'Add Two Numbers')
  public static List<AdditionResult> addTwoNumbers(List<AdditionInput> requests) {
    List<AdditionResult> results = new List<AdditionResult>();
    for (AdditionInput request : requests) {
      results.add(new AdditionResult(request.first, request.second));
    }
    return results;
  }
}

In this case, we're using an inner class AdditionInput as the list type for the invocableMethod input. In Process Builder, this allows us to dictate the input for the type that is passed in. While our invocableAction method can only accept a single parameter, parameter that can be a list of custom classes whose inputs are set by the Process Builder selected by the admin! The output of the preceding code will be as shown in the following screenshot:

Invocable actions are called via the REST API, and this is both a blessing and a curse. Because they are invoked as API calls, each Invocable action executes in its own Apex transaction, meaning that your code isn't competing for the same CPU governor limit time as other triggers or managed package code. On the other hand, it does utilize REST API calls, which are governed on a 24-hour rotating basis. Heavily executed processes may incur significant API usage; which developers must be aware of. Additionally, there are a few caveats around the actual invocableMethod annotation. Only one method in any given class can be annotated as invocableMethod. Because of this, you should utilize a consistent naming convention that clearly indicates which classes only exist to wrap the singular invocableMethod. For instance, I use IM_ActionName. Furthermore, you need to establish an architecture consisting of libraries and objects that contain small but efficient methods that can be composed together with other methods to facilitate complex logic.

Finally, Invocable actions can not only receive a singular input parameter, but they can also return a value to the process. This value must be a list, however, and cannot contain generic sObjects or its primitive cousin object. Any other user-defined sObject, standard Object, or primitive is allowed. While the action can return a value, using the returned value is not entirely intuitive. In order to utilize return values, you have to call the invocableMethod from Flow, not from process. The good news is you can trigger a UI-less flow directly from the Process Builder by selecting an action type Flows. This allows you to select any predefined autolaunched or headless flow that you've created.

Process builder allows administrators and nondevelopers to not only execute workflow style actions but also call Apex code and flows without ever developing a single line of code. Additionally, Process Builder processes can be modified without changing the code. Administrators can call Apex methods directly by choosing the Apex action type; or for more complex logic, administrators can start autolaunched or headless flows that can utilize values returned by InvocableMethod annotated methods. Developers writing InvocableMethods should keep in mind two key things. First, the process or flow calling the InvocableMethod, and not the InvocableMethod itself, is responsible for determining whether or not the action should run. Secondly, while InvocableMethods can accept only a single input parameter, that input parameter can be a list of a custom type defined by variables that are annotated as @invocableVariable, some or all of which can be defined as required.