Invoking Record-Triggered Flow From Apex A Comprehensive Guide

Introduction

Hey guys! Ever found yourself in a situation where you need to kick off a record-triggered flow from your Apex code? It's a common scenario, especially when you have complex business logic that spans both code and declarative tools. In this article, we're diving deep into how to invoke record-triggered flows from Apex, ensuring your processes run smoothly and efficiently. We'll explore the nuances, best practices, and even some potential pitfalls to avoid. So, buckle up and let’s get started!

Understanding Record-Triggered Flows

Before we jump into the technicalities, let’s quickly recap what record-triggered flows are. These flows are like your trusty sidekick, always ready to jump into action when a record is created, updated, or deleted. They’re incredibly powerful because they allow you to automate complex business processes without writing a single line of code (well, almost!). But sometimes, the declarative world isn't enough, and you need the raw power of Apex. That's where invoking a flow from Apex comes in handy.

Record-triggered flows can operate in two main contexts: before-save and after-save. Before-save flows are super efficient because they can make changes to the record before it’s committed to the database, saving you from extra DML operations. After-save flows, on the other hand, run after the record is saved and are perfect for actions that don’t need to happen immediately or depend on the final state of the record. Understanding this distinction is crucial when designing your solution.

Now, why would you want to invoke a flow from Apex? Imagine you have a scenario where a specific condition in your Apex trigger needs to trigger a series of actions that are best handled by a flow. Maybe you need to send out a complex email notification, create related records, or update fields based on some intricate logic. Instead of cramming all that logic into your trigger (which can quickly become a maintenance nightmare), you can delegate the task to a well-defined flow. This keeps your Apex code clean, focused, and easier to maintain. Plus, it leverages the power of flows for declarative automation, giving you the best of both worlds. Let's move onto a requirement example and how to implement it using Apex.

The Requirement: Case Record Updates and Asynchronous Processing

Let's consider a practical example. Imagine you have a requirement where, whenever a Case record is updated such that a custom field Boolean__c is set to true and the Source__c field is set to Email, you need to trigger an asynchronous process. This process might involve actions like sending a prompt, triggering an email, and performing other related tasks. Sounds familiar, right? These types of requirements are super common in real-world Salesforce implementations. Here's the thing: We need to make sure this process is handled efficiently and doesn't bog down the user experience. That’s where the asynchronous path comes in. By using an async path, we ensure that these actions are performed in the background, allowing the user to continue their work without waiting for the process to complete.

Breaking Down the Solution

To tackle this, we'll use a combination of Apex and a record-triggered flow. The Apex trigger will be responsible for detecting the specific conditions (Boolean__c = true and Source__c = Email) on the Case record. Once these conditions are met, the trigger will invoke the flow, passing in the necessary data. The flow, in turn, will handle the asynchronous processing, such as sending emails and updating related records. This separation of concerns is key to building a robust and maintainable solution.

Firstly, think about designing the flow. We want a flow that can handle the async processing efficiently. This means using the right flow type and configuring it to run asynchronously. A good choice here is an after-save record-triggered flow with an asynchronous path. This ensures that the flow runs after the Case record is saved, and the asynchronous path allows us to perform actions in the background. Secondly, think about our Apex trigger. The trigger needs to be efficient and bulkified, meaning it should be able to handle multiple record updates at once. We'll also need to make sure it doesn't exceed governor limits. So, we'll write the trigger to collect the Case records that meet our criteria and then invoke the flow in bulk. This approach minimizes the number of flow invocations and helps us stay within the limits. Let’s go through the steps to implement this solution, from setting up the flow to writing the Apex trigger. This hands-on approach will solidify your understanding and give you a clear roadmap for your own projects.

Step-by-Step Implementation

Let's walk through the process of setting this up, step by step. By the end of this section, you'll have a clear picture of how to invoke a record-triggered flow from Apex and how to configure it for asynchronous processing.

1. Create the Record-Triggered Flow

The first step is to create the record-triggered flow that will handle our asynchronous processing. Head over to Setup, search for Flows, and click New Flow. Choose Record-Triggered Flow as the flow type and select Case as the object. Configure the trigger to run when a record is updated. Now, here’s the crucial part: set the entry conditions to Boolean__c equals true and Source__c equals Email. This ensures that the flow only runs when these specific conditions are met. For optimization, choose the option “Actions and Related Records”, because we want to use an Async Path in this flow.

Next, add an asynchronous path to your flow. This is where the magic happens. The asynchronous path allows us to perform actions in the background, preventing any delays for the user. Inside the asynchronous path, you can add actions like sending an email, updating related records, or even calling another flow. For our example, let’s add a simple Send Email action. Configure the email to send a notification based on the Case details. You can use the Case record variables available in the flow to personalize the email content. Also, add some other actions as you want. The key point here is that all these actions will be performed asynchronously, thanks to the asynchronous path. Don't forget to save and activate your flow. Give it a descriptive name, like “Case Update Async Processing Flow,” so you can easily identify it later. With the flow set up, we’re ready to move on to the Apex trigger.

2. Write the Apex Trigger

Now, let's dive into the Apex code. We'll create a trigger that fires on Case updates and invokes our flow when the conditions are met. Open your Developer Console and create a new Apex trigger. Name it something like “CaseTrigger” and associate it with the Case object. Inside the trigger, we'll implement the logic to detect the specific conditions (Boolean__c = true and Source__c = Email) and invoke the flow.

Here’s a basic structure for your trigger:

trigger CaseTrigger on Case (after update) {
 List<Case> casesToProcess = new List<Case>();

 for (Case caseRecord : Trigger.new) {
 Case oldCase = Trigger.oldMap.get(caseRecord.Id);
 if (caseRecord.Boolean__c == true && caseRecord.Source__c == 'Email' && (oldCase == null || oldCase.Boolean__c != true || oldCase.Source__c != 'Email')) {
 casesToProcess.add(caseRecord);
 }
 }

 if (!casesToProcess.isEmpty()) {
 // Invoke the flow here
 CaseFlowInvocation.invokeFlow(casesToProcess);
 }
}

Notice how we’re looping through the updated Case records and checking if the conditions are met. We're also comparing the old and new values to ensure we only process records that have actually changed to meet our criteria. This optimization prevents unnecessary flow invocations. Now, let’s create the CaseFlowInvocation class to handle the flow invocation.

3. Create the Apex Class for Flow Invocation

Create a new Apex class named CaseFlowInvocation. This class will contain the method that actually invokes the flow. Here’s where we’ll use the Flow.Interview class to start the flow. This is the key to programmatically invoking a flow from Apex.

Here’s the code for the CaseFlowInvocation class:

public class CaseFlowInvocation {
 @InvocableMethod(label='Invoke Case Flow' description='Invokes the Case Update Async Processing Flow')
 public static void invokeFlow(List<Case> caseList) {
 List<Flow.Interview> interviews = new List<Flow.Interview>();

 for (Case caseRecord : caseList) {
 Flow.Interview interview = Flow.Interview.Case_Update_Async_Processing_Flow( // Replace with your flow API name
 new Map<String, Object>{
 'recordId': caseRecord.Id
 } 
 );
 interviews.add(interview);
 }
 for(Flow.Interview interview : interviews){
 interview.start();
 }
 
 }
}

In this class, we have an @InvocableMethod. This annotation makes the method callable from flows, processes, and, most importantly, Apex triggers. The method takes a list of Case records as input. Inside the method, we loop through the Case records and create a new Flow.Interview for each record. We’re passing the Case record ID to the flow using a map. This allows the flow to access the Case record data. Replace `