A Simple Introduction to Salesforce Bulkification

Unless learning and using Salesforce is your sole full-time job then you’re most likely in “do now, learn later” mode. Whether you’re a sales, marketing, or customer success team lead or an army of one trying to keep your business organized, you’re short on time and care about the results more than the process.

If there was one thing I could hit the pause button on, making you stop and learn first it’d be bulkification. This is for three reasons: (1) it’s easy to learn, (2) it’s easy to implement, (3) it’s a nightmare to unlearn and undo if overlooked.

We’ll break down bulkification in three simple sections answering what is it, why is it important, and how to use it.

What is Bulkification?

Bulkification — at its core — is the design choice to make one larger request instead of many small requests. Multiple recipients for a single email, several items in a single Amazon box, and taking everybody’s orders for lunch are all real-world examples of bulkification.

When we abstract our real-world examples we see they all have one thing in common: some sort of outer container, generally a list or set of items. We construct a single payload that satisfies multiple requests at once instead of processing each email/item/order separately. This is the heart of bulkification.

In terms of Salesforce, bulkification revolves around the efficient processing and retrieval of data. Simply put, we do not want to retrieve/insert/update/delete data one at a time.

Let’s read on to explain the importance not only of bulkification, but of why you need to learn it now instead of later.

Why is Bulkification Important?

Bulkification is a critical design pattern due to Salesforce’s execution governors and limits. Essentially, Salesforce users share the same highway so there are rules in place to prevent traffic jams and backups by resource-hungry processes.

At first, the governor limits seem like pain and inconvenience…this is probably because you’re designing your classes and processes inefficiently. In truth, the governor limits shouldn’t be an issue if you’re using proper design patterns like bulkification.

The scary thing about governor limits (and ignoring bulkification) is that they may not be evident at first when you’re testing in a sandbox or growing a smaller environment. It’s not until you have a solid base of data that you may run into them and at that point you have a lot of catching up to do.

Instead of “waiting until it’s a problem”, I strongly recommend learning and getting used to bulkification practices. Speaking of, let’s learn how to bulkify requests with two examples.

How to Use Bulkification?

There isn’t a single “way” to always bulkify a process; however, there are common design patterns that we’ll introduce by taking a look at bulkifying both DML and SOQL requests.

DML Requests

DML — short for data manipulation language — is the mechanism for inserting, updating, deleting, data. In case we’re uninitiated, here’s a simple example.Account acc = new Account();
acc.Name = 'Our Test Account';insert acc;

That last line does the actual save, inserting the new account into the database. What we want to avoid is something like this:for(Integer i=0; i < 5; i++) {
  Account acc = new Account();
  acc.Name = 'Test Account ' + String.valueOf(i);insert acc;
}

In the above example, we create five accounts but we’re also making five DML requests. Lets bulkify this process by using a list of accounts.List<Account> accounts = new List<Account>();for(Integer i=0; i < 5; i++) {
  Account acc = new Account();
  acc.Name = 'Test Account ' + String.valueOf(i);accounts.add(acc);
}insert accounts;

We’re still creating five accounts, but now we’re only making one DML request. So much better!

SOQL Requests

SOQL — short for Salesforce Object Query Language — is the mechanism for retrieving data from an object (and its relatives). SOQL looks a lot like SQL, here’s an example.List<Contact> contacts = [SELECT AccountId FROM Contact];

In the above example, we retrieve the AccountId of all contacts. What we don’t want to do next is something like this:for(Contact con : contacts) {
  Account acc = [
     SELECT Name
     FROM Account
     WHERE Id = :con.AccountId
  ];// Do stuff
}

Why is this bad? We’re making a separate SOQL request for every contact. We can bulkify this by creating a set of Account Ids and condense into one request.Set<Id> accountIds = new Set<Account>();for(Contact con : contacts) {
  if(con.AccountId != NULL) {
     accountIds.add(con.AccountId);
  }
}List<Account> accounts = [
  SELECT Name
  FROM Account
  WHERE Id IN :accountIds
];for(Account acc : accounts) {
  // Do stuff
}

We use a set to leverage its natural property of removing duplicates. The small adjustment to the code turns what could have been hundreds of SOQL requests for individual accounts (many potentially duplicated) into a single bulkified query.

Conclusion

As you can see, bulkification is a relatively simple concept and is not hard to implement either. However, ignoring bulkification can have catastrophic results. Governor limits can be easily missed during testing or while initially populating a growing environment.

Ignoring bulkification best practices will lead to redoing processes later on after they’re established and complexity becomes an issue.

Learning bulkification as early as possible will pay dividends. Before you know it you’ll be bulkifying without a second thought!

Please share your experiences, questions, and feedback below. Follow Code 85 for more plain language programming guides. Thanks for reading!