All Posts

3 Considerations for Salesforce Coding

Checklist and pen with 3 checked boxes

Sooner or later, in the Salesforce ecosystem, you will find yourself writing code to customize a Salesforce organization. There are plenty of references about the Apex programming language, which is Salesforce’s Java-esque proprietary language for controllers and triggers. Of course, you’ll follow general programming best practices. You’ll also want to keep a few things top-of-mind about Salesforce coding.


The Zeroth Law of Salesforce Coding


You’ve heard it many times, and here it is again. Only write custom Salesforce code when you really need it. Seriously. “Clicks, not code.”

Salesforce has really stepped up their declarative automation game in the last few years. Visual workflows, Process Builder, and workflow rules cover a lot of automation use cases. You may be pleasantly surprised at what you can accomplish this way.

That said, there are still times when a tiny custom Apex class can do the work of a complex flow. There are also times when it simply isn’t possible to accomplish what you need without custom Apex code. When you write that code, do it right and save yourself a world of trouble.

Consideration #1: Cover your code.

We’re well aware that Salesforce requires at least 75% of Apex code to be covered by unit tests. How does Salesforce determine code coverage?

Basically, Salesforce parses your (non-test) Apex classes and counts how many lines of executable code are included. Then it goes through your unit tests and counts how many of those executable lines the unit tests touch. The ratio of covered executable lines to total executable lines becomes your code coverage percentage.

Don’t just reach for the minimum, though! If you want robust, durable, maintainable code in your Salesforce org, make sure your Salesforce coding goal is maximum coverage. No, you don’t have to kill yourself to cover that last 2-3%, but you’ll be saner in the long run if you aim for 100% and fall a little short than if you aim for 75% and just squeak by.

High quality testing

Many Salesforce developers prefer the test-first approach, or test-driven development. There are many benefits to this practice, not the least of which is clear requirements. Writing the unit tests first is a great way to make sure you understand exactly what your code should – and should not – do. It’s a built-in way to define use cases and exceptions precisely.

In an org with lots of automation in play, it’s also a good idea to use plenty of asserts in your unit tests. This helps you test the code more meaningfully for its end results. Sure, you can write a unit test that covers enough lines of code to pass muster, but the real purpose of testing is to make sure your stuff works!

Consideration #2: Bulkify your code.

It’s all too easy to fall into the one-record trap, especially when you define requirements. After all, most custom code in Salesforce involves automatic data modification in response to a triggering event. From a user perspective, a triggering event usually involves just one record.

From an administrative or systems perspective, though, anything that happens to a single record can happen to lots of records at the same time because more than one user can work at a time. Salesforce coding must adhere to strict limits that govern resource use like SOQL queries, DML statements, and CPU time.

Save yourself a lot of grief. In all of your Salesforce coding, minimize how many times you touch the database to read or write records. Need to modify some data? Pull it into an Apex collection all at once, loop through the collection to do what you need to do, then push it back to the database all at once. This applies to triggers, helper methods, controllers: anything that touches Salesforce data.

I repeat: never put SOQL or DML inside a loop. Don’t do it!

Consideration #3: Streamline your code.

Streamlining your code can take different forms, depending on what else is going on in your Salesforce organization and how much custom code it includes. A common principle in Salesforce coding is one trigger per object.

Does one trigger per object mean that triggers become huge and unreadable? No. It’s very possible – and recommended – to use helper methods for the actual data manipulation. Having one trigger per object makes it easier to stay within governor limits and reduces the risk of interference. The Salesforce Technical Library goes into more detail about this in its “Apex Code Best Practices” page.

Another streamlining concept is reducing the number of script statements or executable lines in your code. This consideration only arises in larger Salesforce orgs with a lot of custom code. It’s worth mentioning, though. Governor limits allow at most 200,000 script statements. That sounds like a lot, but some coding styles that increase readability can also increase the number of statements unnecessarily. In an org with a lot of Apex code, if you’re approaching your limit, consolidate where you can.


When you need to do Salesforce coding, keep a few basic considerations in mind to avoid a lot of headaches. These ideas aren’t very different from general coding best practices, but in the Salesforce environment, some principles are enforced more strictly than you may be used to. Only write custom code when you really need to, and keep these principles in mind: cover your code, bulkify your code, and streamline your code. Keep it simple, and enjoy the benefits!

Click here to learn more about Salesforce development.

Recent Posts

Covid-19 Illustrates the need for Digital Transformation

It’s no surprise that COVID-19 has had a massive impact on businesses of all kinds. Companies around the world are challenged to maintain day-to-day processes without the luxury of face-to-face interaction. Despite this challenge, businesses still need to deliver results to their customers. While many people have resorted to using video technology such as Zoom […]

Would Your Business Benefit from Custom Software?

Many businesses today leverage software to boost efficiency, reduce the cost of operations, and comply with regulatory requirements. You can either choose off-the-shelf software that offers stock features for every business or custom software that is adaptable to specific business requirements. While packaged software remains popular, here are some reasons to go against the tide […]

How Emergent Workflows Can Slow Down a System

Defining Emergent Workflows Workflows In general, ideal business software operates solely under the conditions and functions for which it was designed. Emergent workflows occur when elements of a business software develop independently of and in conflict with its initial, intentional design. These developments often slow down entire workflow systems, creating inefficient processes that can hurt […]