How To Improve Salesforce Performance

Slow performance in Salesforce can be frustrating for users and a drain on business resources. While there are a number of potential causes for a slow system, there are two solutions you can employ right away that might just be the fix you’re looking for.

In this post, we look at the most common challenges Salesforce Admins and developers face when it comes to Salesforce org performance as well as how to resolve those issues, namely: 

1. Decreasing load/save times due to technical debt, and
2. Reducing the risk of Process timeouts.

Why Should Enterprises Care About Slow Salesforce Orgs? 

For many companies, Salesforce is a critical component in their business operations.

Companies rely on Salesforce to keep the business moving smoothly and profitably. If the application’s performance suffers, so does the business.

Delays within the Salesforce application, slow page load times, and timeouts aren’t just productivity killers. In some cases, important work can be lost and files can’t be saved. Even worse, when users are unable to make updates, a lack of visibility across the company can ensue.

Given the serious repercussions of a poor performing Salesforce org, it’s important that enterprises are proactive about Salesforce maintenance.

How to Improve Salesforce Org Speed and Performance 

Now that we’ve covered why it’s important to prioritize improving Salesforce performance, let’s take a look at some solutions.

First, we’ll walk through best practices for reducing technical debt, then you’ll learn, from an Admin’s perspective, how to solve the elusive Apex CPU timeout error. 

In a future post, we’re also going to show you exactly how to use the Developer Console to benchmark Process times so you can determine whether the efforts you’ve made to speed up your Salesforce org have made a significant impact. 

Speed Up Your Salesforce Org by Reducing Technical Debt

According to Salesforce, technical debt is the “ongoing cost of expedient decisions made when implementing code.” If you’d like to read more about technical debt before moving on to best practices for reducing it, we’ve dedicated an entire blog post to the topic here. 

Examples of Technical Debt in Salesforce

In a Salesforce instance, technical debt can manifest in many different ways:

• It may be a large number of unused fields that were created for a Process that has since been deprecated. 
• It could be old Workflows, Process Builders, or Apex Code that once supported these old Processes. 
• Technical debt could also be a result of old workarounds that were required at one time, but that Salesforce has since patched or provided a direct solution for.

Impact of Technical Debt

Why does technical debt matter? When you start hitting some of Salesforce’s limitations, all this technical debt can quickly become an issue for Admins or developers. Some common limitations include object field limits, data storage limits, and various apex governor limits. 

Plus, technical debt can lead to overwhelming setup configurations. Just imagine trying to find a single profile in a list of 500 similarly named deprecated profiles.

Many, if not all, of these issues will crop up as new projects get underway. In other words, you’ll run into them at the worst possible time.

Dedicate Time to Reducing Technical Debt

In order to reduce this problematic technical debt, administrators should start by creating a dedicated schedule to check, review, and eliminate debt.

Since no two businesses are alike, you should schedule according to the frequency that makes the most sense for your business. This might mean setting aside 1-2 days per quarter to prioritize and determine what constitutes technical debt in your Salesforce org, and another week per month to make necessary changes.

Again, depending on the complexity and age of your organization, your schedule may look very different.

Finding Technical Debt

Once you have a plan in place to address your technical debt, how do you find it?

If you know your business inside out, this may be easy for you because you’ll likely know where all the components live that were created urgently or under time constraints. In that case, you can begin reviewing those old rush jobs and determining whether a better solution exists. 

Additionally, you can start looking at the largest and most complex business processes to see if there is room for optimization. At the very least, you can make sure everything is up-to-date documentation-wise. 

But what if you don’t know where to start or look next? Tools like Field Trip and the Salesforce Optimizer help identify loose metadata that has the potential to be removed. By leveraging information from these reports and the Dependency API, you can sift through and start chipping away at unused metadata. 

Reducing technical debt is a great step toward improving your Salesforce org’s performance.

However, there’s another big issue that can slow your system down, and it deserves attention.

Speed Up Your Salesforce Org by Solving the “Apex CPU Timeout Error”

Is your Salesforce org still slow after reducing technical debt? While addressing all that non-essential data certainly helps speed up your Salesforce org, it’s likely not the sole cause for slow performance. In fact, one of the most common problems that pop up out of the blue is the “Apex CPU timeout error.” 

You may think this is just an Apex problem and, as an Admin, you can simply redirect the issue to your developer. However, those three recursive Process Builders you put together a year ago, for example, may actually be at the heart of this issue.

Let’s take a closer look.

Troubleshooting the Apex CPU Error

This error can creep up in a variety of ways. If a Process fails, you’ll receive a warning as an exception email. You might also start anticipating the error when you experience slower load times while creating or updating records.

Contrary to what you may believe, when you receive an Apex CPU error, Apex shouldn’t necessarily be the first place you look.

With the rise in popularity of Salesforce’s Flow Builder and Process Builder, a lot of complex business logic is being moved over to declarative tools. 

And even small Processes can negatively impact the speed of your Salesforce org, leading to timeout errors.
This is actually great from a maintenance perspective since declarative processes are easier to understand than Apex, the tradeoff being that the builders don’t always allow you to be as efficient as you could be in Apex. You don’t necessarily have to revert everything back to Apex, but you’ll have to optimize your flows to make them run faster. We’ll talk more about run times in a future post.

What if Apex is the Problem?

If your problem is with custom Apex, it’s a good idea to review Salesforce’s tips for improving efficiency here. 

It should also be noted that AppExchange packages do get an increase for a lot of different Salesforce limits, but not for CPU time. A managed package shares the same CPU pool with everything else in your organization as mentioned here. 

There isn’t much you can do to edit the code of most managed packages, so it’s important to just keep packages in your instance that are adding value to your business and quickly get rid of those that are no longer needed.

Increase Efficiency with a Master Process Builder

One way to eliminate or reduce the Apex CPU timeout error and speed up your Salesforce org is by compiling each object’s Process Builders into a single, master Process Builder.

This removes the overhead associated with starting up and shutting down Process Builders, which can add up to a significant amount of time. 

Ensuring that you only execute on a given node in Process Builder when it is appropriate to do so will help reduce unnecessary actions. You can do this by selecting the “yes” checkbox on the node labeled “Execute actions when specified criteria change.” This also makes it easy to figure out if the value you care about is being updated. 

In your master Process Builder, don’t forget to remove the recursive flag at the top as it can be very difficult to control Process Builder recursion so not to trigger each node. There are some great notes about that here.

Wrap Up 

A slowly performing system is one of the biggest frustrations for Salesforce users as well as a major drain on business resources. Luckily, addressing the two common problems covered in this post, technical debt and Process timeouts, can significantly speed up your Salesforce org. 

We hope you find the actionable insights provided here to be helpful. Have questions about how to improve your Salesforce org? Sign up for our newsletter! We send out a monthly recap of our latest Salesforce content, including articles on security best practices, actionable insight on Salesforce optimization for enterprises, and more.