Build Scalable Solutions with Salesforce

While Solutioning, should we consider the scalability of the Salesforce Application? Should we even think about scalable solutions in Salesforce? These are very important questions from Salesforce architects. This post will answer these questions and we will see how to build scalable solutions with Salesforce

What Is Application Scalability?

Scalability is the ability of an application to handle a growing number of users, clients, and customers. Application scalability guarantees that our Salesforce application will be capable of efficiently handling a high growth of its user base. Scalability makes sure that the customer experience remains the same regardless of how many users are added to Salesforce Org.

Why Should We Care About Scalability?

If our application is not scaled properly then it will adversely affect platform performance and eventually impact the trust of clients/customers. It might be possible that there will be downtime to handle that excessive load. This can be a huge financial loss for clients and for us also.

If we prioritize scalability as part of the system design, we can ensure a better user experience, lower costs, and higher agility in the long term.

Scalability Factors

In Salesforce, Scalability is also impacted by lots of data and how this data is structured. Below are four factors that affect scalability in the Salesforce application

1. Data Stored in Org
2. Transaction Complexity
3. Record Sharing
4. Clean and Bulkified Code

Let us see how we can handle these factors effectively.

1. Data Stored in Org

While designing the Salesforce data model we should consider many factors. Some of the important factors are

• Numbers of records in the object
• Data Skew
• Custom Fields and Skinny tables
• Data virtualization
• Custom Indexes
• Data Governance

2. Transaction Complexity

When the Salesforce application will be used by concurrent users it may run concurrent triggers, workflows, async batch jobs, and data sync jobs which will lead to locking scenarios. 

We should design transactions using a combination of low-code and pro-code approaches. We should consider low-code solutions like Visual Flow to meet UX requirements.  Pro-code solutions should be used to leverage automation. We should run non-business critical batch jobs and data sync operations at off-peak hours.

3. Record Sharing

Most organizations make default Organizational Wide Defaults (OWD) to private. To share data they create different sharing rules. Sharing rule can impact the performance of the application as it will change the owner and sharing calculation is done during business hours which will make the application slower.

Ownership Skew

Due to sharing rule, it is possible that more than 10,000 records are assigned to a single user. When we change user roles or group membership for those records, it will impact a very large number of entries in the sharing tables, resulting in lengthy access rights recalculations.

To avoid ownership skew, we have to distribute ownership of records across a greater number of users.

Redundant Sharing Rule

Redundant sharing rules and excessive sharing rule calculations can make transactions very slow. When we change the role hierarchy during business hours it can impact business operations.

We should design our system in such a way that

• The number of ownership-based sharing rules should not exceed 100 per object 
• The number of criteria-sharing rules should not exceed 50 per object.
• Defer sharing rule calculations during data loads.

Role Hierarchy Complexity

Role hierarchy is a mechanism to control the data access to the records on a Salesforce object based on the job role of a user. If we have a role hierarchy with more than 10 levels then performance/scale issues arise with an increase in role depth.  This will increase our data management complexity also.

We should create a role hierarchy with less than 10 levels and can group roles based on necessary data access levels.

4. Clean and Bulkified Code

Our code should be clean, properly commented and it should always handle bulkification.

1. One trigger per object 

We should avoid an excessive number of triggers per object. Excessive use of triggers is difficult to maintain in a large enterprise application.

We should avoid a trigger and if it is required then create one trigger per object. Create a logic in the trigger so that we can disable it when it is required. We should disable triggers during large data loads if possible.

Implement a helper class for each trigger. Bulkify helper classes and methods, as well as triggers to process up to 200 records for each call.

2. Keep business logic out of triggers

We should not put actual business logic directly into our triggers. It will increase the complexity to create individual unit tests for each piece of code. This leads to messy, difficult-to-maintain code. Logic-filled triggers also violate the single responsibility principle and encourage the creation of non-reusable code.

We should create a logic-less trigger pattern. there are many ways to implement logic-less triggers, but the most popular is to use the trigger handler pattern.

Check out different patterns and best practices for apex triggers in the blog Apex Trigger Code Optimization

3. Smaller Class

Break bigger classes into smaller reusable classes. We can implement an apex design pattern which is available at Apex Enterprise Patterns Open Source. Reusable classes help us in reducing redundant code and help us in reducing lines of code. This way our application will not exceed governor limit.

4. Use Custom Setting and Custom Metadata

We should use custom settings and custom metadata types as much as possible. Both are cached and it will avoid the governor limit. Check out the blog Custom Setting and Custom Metadata Type for more detail about their benefits and usage.

There are lots of other best practices for making our application faster and more scalable. Check out our other blog Optimizing Salesforce Apex Code for more detail.

5. Use Asynchronous processes

Use Asynchronous processes to work on huge data which might impact application performance. We have below four asynchronous processes which can be used based on the business use case.

• Batch Apex
• Queueable Apex
• Future method
• Scheduler class

These asynchronous processes will run when our application is not busy so it will not impact application performance. Check out the below blogs for more detail about these asynchronous processes

• Queueable Vs Batch Apex In Salesforce
• Avoid Batch Apex and Use Queueable Class
• Using Salesforce Bulk API V2

References:

Scalability with Salesforce 

Summary
Designing our solution with scalability in mind will ensure that our system’s performance will not be impacted in the future when our data will grow with the increase in customers.