Sudipta Deb
Founder of Technical Potpourri, Co-Founder of Shrey Tech, Enterprise Cloud Architect
In Salesforce, bulkification of code is essential due to the platform's multi-tenant architecture and the associated governor limits. Salesforce operates on a multi-tenant architecture, meaning that multiple customers (organizations) share the same underlying hardware and infrastructure. This shared environment necessitates strict resource management to ensure that no single customer monopolizes resources and impacts the performance of others. To enforce fair resource usage, Salesforce imposes governor limits on Apex code, which is the platform's programming language.
Without bulkification, Apex code would process records one at a time.
In this blog post, I will share the process to bulkify your invocable apex method call from Salesforce Flow.
The form you have selected does not exist.
Watch The Video Or Read The Article (Or Do Both 
)
)
Let's Understand The UseCase
The Use Case I will be implementing today is - "Any time a Case is created or updated with fetchContactName field (Custom Field of type Checkbox) checked, Contact's Full Name from that case should be returned".
This is a very simple use case. I don't want to make the use case too complex, as my intention is to demonstrate the way to bulkify your apex invocable callout implementation so that you can avoid some unnecessary issues.
Implementation Approach
To implement the above use case, I will be writing an invocable apex class which I will call from record-trigerred Salesforce Flow. Again very straightforward. So without any further delay, let's start implementing the use case.
Let's Write The Apex Class
As you can see in the below Apex class, I will be passing the list of ids (which is basically the case ids passed from the flow). This is important. I am dealing with a list of ids and not a single id. This is the first step to make things bulkified. Rest of the code is very straightforward. Using the ids, fetching the case's contact names, and then storing them in the list. The same list is being returned at the end of the code execution.
public with sharing class FetchContactDetailsFromCase {
@InvocableMethod(label='Fetch Contact Names' description='Returns the list of strings holding contact names' category='Case')
public static List<String> fetchContactNames(List<ID> ids) {
System.Debug('--++-- Inside fetchContactNames --++--');
System.Debug('--++-- List of Case Ids : ' + ids);
List<String> allNames = new List<String>();
//Fetch Case Details
List<Case> allCases = [Select Id, Contact.Name From Case Where Id in: ids];
for(Case singleCase : allCases){
allNames.add(singleCase.Contact.Name);
}
System.Debug('--++-- Contact Names : ' + allNames);
return allNames;
}
}Let's Build The Flow
This is going to be record-triggered flow and from the flow, I will be calling the invocable apex. Screenshots given below.
An important thing to notice is from the second screenshot above. While passing the record id to the Apex Invocable method, I am passing the triggering record ID (a flow variable). But if you can remember, the apex class is expecting the list of ids. This is where the Salesforce magic starts. Salesforce Flow will make sure if there are multiple records being updated satisfying the condition of this flow, instead of calling the flow that many times, Salesforce will club them in one transaction (max 200 records) and pass the list of record ids. This is how the bulkification being handled in Salesforce Flow.
Execute And Check The Debug Log
Now is the time to execute some code and check the behavior. For that I will be executing the below code snippet from Developer Console's Execute Anonymous Window.
List<Case> allCases = [Select Id, fetchContactName__c From Case Limit 5];
for (Case singleCase : allCases){
singleCase.fetchContactName__c = true;
}
update allCases;The above code snippet will update 5 cases with the fetchContactName checkbox checked. This will initiate the record-triggered flow, and finally all those 5 case record ids will be passed into the apex invocable class. From the debug log, it is very clear that Salesforce passed all 5 ids in one single transaction. (screenshot below).
But the surprise element is still pending. Salesforce will also make sure that it will put the contact names in the same sequence that case ids came as input. Which is super helpful to do any work inside Flow after the invocable call. You as a developer don't need to do any extra logic and you can reply on the output from the invocable apex to perform your business logic.
Reference Documents
Final Thoughts
I hope this blog post and video will give you the clarity to write your next flow and invocable apex class in the correct way following the best practices.
Disclaimer
This article is not endorsed by Salesforce, Google, or any other company in any way. I shared my knowledge on this topic in this blog post. Please always refer to Official Documentation for the latest information.
0 Comments