Your business runs on Salesforce, reliant on it to help your revenue team go to market smoothly, efficiently and effectively. Yet in an era where speed to lead is so important, many companies are frustrated with a slow and seemingly overburdened Salesforce instance.
Is Salesforce running a little too slow for your liking?
A slowly performing Salesforce instance is often a frustrating mystery for Salesforce administrators and users worldwide. Delays in processing, slow page loads and timeouts not only kill productivity, but also threaten data integrity through an inability to save files, update records and report accurately. The bottom line is a drain on precious resources – your time and your money – both in fixes and in delayed or lost revenue opportunities.
This post covers the root causes of sluggish SFDC performance and what you can do to ensure your Salesforce org operates at peak efficiency.
Slow performance rooted in technical debt
Defined by Salesforce, technical debt is “the ongoing cost of expedient decisions made when implementing code.” In short, it’s the cumulation of all the “fixes” – often shortcuts and workarounds – resulting from technical decisions made to give a short-term benefit and a quicker implementation. Technical debt goes well beyond code, and includes all abandoned or overlapping processes, workflows, custom fields, etc.
Ordinarily, technical debt is classified as either incurred or evolved. Incurred technical debt is built through either deliberate actions or inadvertently through happenstance, and includes technical decisions like using obsolete methods – for instance, deploying a Salesforce feature earmarked to be retired. Evolved technical debt is accumulated over the course of changes in both the Salesforce platform and your organization’s Salesforce org.
In small amounts, technical debt is not necessarily bad, and, in fact, it’s somewhat inevitable in most cases. For example, technical debt can accrue as a result of efforts taken to quicken development toward a critical short-term goal, where the deadline was the priority consideration. The key, however, is to retire that debt before the “interest” comes due in the future and adversely impacts your Salesforce org’s ability to operate efficiently.
Within the context of Salesforce, technical debt includes the following:
- Multiple configurations, like multiple email templates for similar communications, different approvals for similar GTM processes, etc.
- Excessive customizations, like creating coding triggers when Process Builder flows would work, creating custom objects rather than adjusting requirements to enable the use of standard objects, etc.
- Poor quality code, like writing multiple Apex code snippets rather than consolidating and using a shared helper, creating hard-coded variables rather than custom metadata, etc.
- Accumulated “cruft,” encompassing all poorly designed, unnecessarily complicated and obsolete or unused code, including inactive workflows, unused packages, and undeleted proofs and prototypes.
Salesforce’s multi-tenant architecture
Salesforce helped pioneer multi-tenant architecture, a design architecture where multiple instances of an application operate in a shared environment. The architecture works because each tenant (customer) is integrated physically, but separated logically. It results in an instance of the software running on one server, accommodating multiple tenants.
Multi-tenant architecture allows a software application to share a dedicated instance of configurations, user management and other properties. Those applications share the same users and displays, as well as rules and database schemas which tenants can customize to varying extents.
Salesforce has carefully built in safeguards, primarily governor limits, to prevent customer organizations and ISV (Independent Software Vendor) partners from consuming too much processing power. Everyone, including Salesforce itself, competes for the shared resources. While the strengths of the cloud are a great many, here also lies perhaps its biggest challenge – a poor steward of the system affects everyone on the server. Inefficiencies in any single element affects performance.
Measure your Salesforce performance
Slow Salesforce performance is most often realized with long page-loading times, and root causes can extend into your network, device, browser and your SFDC configuration. Salesforce states the most important factors in determining page load times are Octane score (a benchmark developed by Google that measures JavaScript performance, with a higher Octane score correlating to faster page load times), network latency, download speed and the amount of customization on a given page.
To measure your SFDC performance, run the Salesforce Performance Test by appending speedtest.jsp to your org’s domain (e.g., https://MyDomainName.lightning.force.com/speedtest.jsp).
Audit to understand root causes of slow Salesforce performance
Conducting a CPU audit of your Salesforce org is an endeavor you should undertake periodically, whether you’re looking specifically for root causes of performance challenges or just conducting regular maintenance. As a task, it requires a technical understanding of SFDC and as such, many companies utilize consultants and solution providers.
Additionally, audit each of your managed applications acquired through AppExchange, and gain an understanding of both the resources they consume and the timing in your processing when they are consumed. You cannot edit the code of most managed packages, so it’s critical to only keep packages in your instance that are adding value and uninstall those that are no longer needed.
Lastly, during your audit, turn a discerning eye toward yourself and any custom coding you may have written. Custom coding and process tools don’t ride for free. They all consume resources, and, unfortunately, SFDC doesn’t protect us from ourselves.
Configure your Salesforce org for faster performance
The configuration of your SFDC org can contribute to slow performance. Complex page configurations, with many fields and inefficient custom components, can produce long load times. Simplifying those pages might very well significantly improve performance.
Below are tips to get your Salesforce org in tip top shape:
- Run Salesforce Optimizer to get personalized recommendations on refining customizations, reducing complexity and driving feature adoption.
- Streamline the number of fields on any given page, and configure so the most relevant fields display first.
- Use tabs to break up page elements, as all components outside of a primary tab are rendered on demand and not in the initial page load. Break elements like fields, lists and custom components into separate tabs, and display your most relevant data on your first tab.
- Test all custom components and determine if you can replace any with Lightning Actions. Follow SFDC’s Lightning components best practices if you do continue to utilize custom components.
LeanData eases your Salesforce pain
As a Salesforce ISV, LeanData takes its responsibility as a steward of the shared ecosystem very seriously. It’s reflected in the code we write for our managed package solution applications and the tools they contain to allow our customers to build their GTM processes to run effectively and efficiently.
As a systemic solution, LeanData automation scheduling delivers short “bursts” of data transfers, occurring once approximately every 180 seconds. More importantly, within the solution, customers can use “Edge Priority” nodes to prioritize the most urgent records for processing.
For example, most every customer will treat incoming demo requests as the highest priority of all leads, and as such, LeanData processes those records first, ensuring they reach the right representative in time for them to be actioned upon before the expiration of a service level agreement (SLA). Visitors to a trade show booth, on the other hand, will have a lesser urgency, and those records will be slotted in behind more urgent records and processed as resources are available.
Summary
A slowly performing system is one of the biggest frustrations for Salesforce users as well as a major drain on business resources. Before jumping to the deployment of any quick fix, it’s important to first identify root causes. Once those have been established, corrective actions can run the gamut from SFDC configuration to your network and the type of hardware you use, and everything in between. Conduct periodic audits as best-practice maintenance and ensure your revenue teams are best equipped to succeed.
