A common challenge for Salesforce developers is designing Apex code that works efficiently with large data volumes. With strict governor limits on queries and DML statements, thinking "bulk first" isn’t just a good habit—it's a necessity.
In this post, you'll learn:
- Why bulkification matters: Real-world scenarios showing how non-bulkified code can fail.
- Key governor limits to watch out for: SOQL, DML, CPU time, and more.
- Bulk processing patterns: How to structure your triggers and classes to handle collections of records.
- The Trigger Handler pattern: A reusable, scalable way to keep triggers bulk-safe and organized.
- Sample code: See before-and-after examples of bulkified vs. non-bulkified code.
- Testing bulk operations: How to write effective test classes that verify bulk safety and performance.
By the end, you’ll be able to refactor your Apex logic for scalability, maintainability, and peace of mind during deployments and code reviews!
public class AccountTriggerHandler {
public static void onBeforeUpdate(List<Account> newList, Map<Id, Account> oldMap) {
List<Account> toUpdate = new List<Account>();
for (Account acc : newList) {
Account oldAcc = oldMap.get(acc.Id);
if (acc.Name != oldAcc.Name) {
acc.Description = 'Name changed on ' + DateTime.now();
toUpdate.add(acc);
}
}
if (!toUpdate.isEmpty()) {
update toUpdate;
}
}
}
Trigger:
trigger AccountTrigger on Account (before update) {
AccountTriggerHandler.onBeforeUpdate(Trigger.new, Trigger.oldMap);
}
Bulkification isn’t just about passing code review—it’s essential for delivering reliable, performant Salesforce solutions. Adopting the right patterns early will save you hours of debugging and help your org scale smoothly.
Happy coding! 🚀
Post a Comment