Invocable Methods and Flow Integration

Invocable Methods and Flow Integration – Salesforce Platform Developer 1 Exam Guide

Why Invocable Methods and Flow Integration Matter

Salesforce Flows are one of the most powerful declarative automation tools on the platform. However, there are situations where business logic is too complex for purely declarative solutions — complex calculations, callouts to external systems, advanced data manipulation, or reuse of existing Apex logic. This is where Invocable Methods come in. They serve as the bridge between declarative automation (Flows, Process Builder) and programmatic logic (Apex). For the Platform Developer 1 exam, understanding this integration is critical because it tests your ability to combine declarative and programmatic approaches — a core competency Salesforce expects from developers.

What Are Invocable Methods?

An Invocable Method is an Apex method annotated with @InvocableMethod that can be called from Flows, Process Builder, REST API, and other automation tools. It allows admins and developers to extend declarative tools with custom Apex logic without exposing the full complexity of the code.

Key characteristics:
- The method must be public or global and static.
- Only one @InvocableMethod is allowed per Apex class.
- The method accepts a List of inputs (to support bulkification) and returns a List of outputs.
- The annotation supports a label and description attribute so the method appears with a friendly name in the Flow Builder UI.

What Are Invocable Variables?

The @InvocableVariable annotation is used on properties of an inner class (or a standalone class) to define structured input and output parameters for the invocable method. This lets you pass multiple values into and out of the Apex action from a Flow.

Key characteristics:
- The variable must be public.
- Supports attributes like label, description, and required.
- The data types supported include primitives (String, Integer, Boolean, etc.), sObjects, and collections (List).

How It Works — Step by Step

1. Create an Apex class with an inner class for inputs/outputs:

public class AccountProcessor {
  public class InputWrapper {
    @InvocableVariable(label='Account Id' required=true)
    public String accountId;
    @InvocableVariable(label='New Rating')
    public String newRating;
  }

  public class OutputWrapper {
    @InvocableVariable(label='Success')
    public Boolean isSuccess;
    @InvocableVariable(label='Error Message')
    public String errorMessage;
  }

  @InvocableMethod(label='Update Account Rating' description='Updates the rating of an account')
  public static List<OutputWrapper> updateRating(List<InputWrapper> inputs) {
    List<OutputWrapper> results = new List<OutputWrapper>();
    for (InputWrapper input : inputs) {
      OutputWrapper output = new OutputWrapper();
      try {
        Account acc = [SELECT Id, Rating FROM Account WHERE Id = :input.accountId LIMIT 1];
        acc.Rating = input.newRating;
        update acc;
        output.isSuccess = true;
      } catch(Exception e) {
        output.isSuccess = false;
        output.errorMessage = e.getMessage();
      }
      results.add(output);
    }
    return results;
  }
}

2. Use it in Flow Builder: In a Flow, add an Action element. Under the Apex category, the invocable method appears with the label you defined (e.g., "Update Account Rating"). Map Flow variables to the input and output parameters.

3. The Flow engine handles bulkification: When a Flow runs in a bulk context (e.g., triggered by a record-triggered flow on bulk DML), the platform collects all the interviews and passes them as a single list to the invocable method. This is why the method signature uses List<Input> and returns List<Output>.

Important Rules and Constraints

- One @InvocableMethod per class: You cannot define multiple invocable methods in the same class. If you need multiple actions, create separate classes.
- Method signature: The method must accept either zero parameters or exactly one parameter of type List<T>, where T can be a primitive, sObject, or a user-defined class with @InvocableVariable members.
- Return type: The method can return void or List<T>.
- Bulkification: The List input corresponds to multiple Flow interviews being batched. Each element in the input list corresponds to one Flow interview, and each element in the output list corresponds to the result for that interview. The order must match.
- Supported data types for @InvocableVariable: String, Integer, Long, Double, Decimal, Boolean, Date, DateTime, Id, sObject, and Lists of these types.
- Callout support: If your invocable method makes a callout, annotate it with callout=true in the @InvocableMethod annotation: @InvocableMethod(callout=true).
- Invocable methods run in system context by default but respect sharing rules if the class is declared with with sharing.

Flow Integration Patterns

1. Screen Flows: Use invocable methods to perform complex server-side logic after user input (e.g., validate data against external systems).
2. Record-Triggered Flows: Call invocable methods when declarative logic alone is insufficient (e.g., complex field calculations, cross-object updates with business rules).
3. Autolaunched Flows: Combine multiple invocable actions for orchestration-style processing.
4. Scheduled Flows: Use invocable methods for batch-like operations triggered on a schedule.

Invocable Methods vs. Other Apex Integration Points

- @InvocableMethod vs Apex Triggers: Triggers fire automatically on DML events; invocable methods are explicitly called from Flows. They serve different purposes but can coexist.
- @InvocableMethod vs @AuraEnabled: @AuraEnabled methods are called from Lightning components (LWC/Aura). @InvocableMethod methods are called from Flows and Process Builder. A method cannot have both annotations simultaneously.
- @InvocableMethod vs @Future / Queueable: Invocable methods run synchronously within the Flow transaction unless you explicitly enqueue asynchronous work inside them.

Testing Invocable Methods

Invocable methods are tested like any other Apex static method. In your test class, you:
- Create test data.
- Instantiate the input wrapper, populate its fields.
- Add the wrapper to a list and call the static method directly.
- Assert on the returned output list.

You do not need to launch a Flow in a test to test the invocable method — just call it directly.

Exam Tips: Answering Questions on Invocable Methods and Flow Integration

1. Remember the one-method-per-class rule: This is a commonly tested constraint. If a question asks what happens when you put two @InvocableMethod annotations in one class, the answer is a compile-time error.

2. Know the method signature: The method must be public static (or global static). The input parameter must be a List. The return type must be a List or void. Questions often present incorrect signatures as distractors.

3. Understand bulkification: The List parameter is not for passing multiple items from a single Flow interview — it represents multiple Flow interviews batched together. Each list element = one interview. The output list must be in the same order as the input list.

4. Distinguish @InvocableMethod from @InvocableVariable: @InvocableMethod goes on the method. @InvocableVariable goes on properties of a class used as input/output. Questions may try to trick you by swapping these.

5. Callout annotation: If the question involves making HTTP callouts from an invocable method called by a Flow, remember you need @InvocableMethod(callout=true). Without it, the callout will fail at runtime.

6. Where can invocable methods be called from? They can be called from Flows, Process Builder, the REST API (via /actions/custom/apex), and Einstein Bots. They are not directly callable from Lightning components (that requires @AuraEnabled).

7. Access modifiers matter: If the question involves a managed package scenario, the method must be global to be accessible outside the package. For same-namespace usage, public is sufficient.

8. Watch for transaction context questions: Invocable methods called from record-triggered flows share the same transaction as the triggering DML. Governor limits are shared. If a question asks about governor limits in this context, treat the invocable method as running in the same transaction.

9. Supported types for @InvocableVariable: Know that you can use sObjects, primitives, and Lists. You cannot use Maps or Sets as invocable variable types.

10. Scenario-based questions: When a question describes a requirement where an admin needs to call complex Apex logic from a Flow, the answer is almost always @InvocableMethod. If the question asks about calling Apex from a Lightning component, the answer is @AuraEnabled. Don't confuse the two.

11. Process Builder vs Flow: While Process Builder also supports invocable methods, Salesforce is retiring Process Builder in favor of Flows. Exam questions are increasingly Flow-focused, but be aware that both tools can call invocable methods.

12. Error handling: If an unhandled exception occurs in an invocable method called from a Flow, the entire transaction is rolled back. For graceful error handling, use try-catch blocks and return error information through output variables, allowing the Flow to handle the error declaratively.

Summary

Invocable methods are the essential link between declarative automation and programmatic logic in Salesforce. They allow developers to expose reusable Apex functionality to admins through Flows. For the Platform Developer 1 exam, focus on the annotation rules, method signatures, bulkification behavior, and the distinction between @InvocableMethod and other Apex annotations. Practice writing and testing invocable methods to solidify your understanding, and always think about transaction context and governor limits when these concepts appear in exam scenarios.