System scalability is crucial in every framework, but especially in Salesforce because of the multi-tenant environment. Scalability in a Salesforce org is affected by many factors, but most of those factors can be controlled by proper design considerations upfront. Sound techniques in Data Governance, sharing and ownership design, and simplicity in automation will set you up for success for many years to come.
Why Scalability is Important
Your Salesforce org needs to continue to quickly respond to user page views along with data edits, adds, and deletes, even when thousands of users are accessing the system. In order to make that happen now and in the future, scalability must be addressed during design. Ensuring you don’t have to do a redesign at any point in the future saves time and money and displays reliability to the end-user. Key points to consider:
- Address it now so you don’t have to address it later
- Addressing during the design phase maximizes the capacity to recover quickly from sudden increased system demands
- Scalability is an integral part of the data management plan
- Org is scalable if you don’t have to redesign it to maintain performance after an increase in users or stored data
Factors that Impact Salesforce Scalability
There are three main categories of factors that can affect scalability; Stored Data, Record Sharing, and Transaction Complexity.
In a Salesforce environment, emphasis is placed on the following points around data during design:
- Data Governance
- Excessive Records in a Single Object
- Data Skew
- Custom Indexes, skinny tables, data virtualization
A sound Data Governance plan will ensure that your data remains valid and easily accessible. Data Governance is a process of ensuring your data is reliable, usable, available, and secure. The Data Governance framework is the rules, processes, and roles in an organization that work together to ensure compliance with the data management strategy.
The number of records in a single object can greatly influence response time, especially during queries. Determine how long data in each object needs to be retained and include an archive strategy in the Data Governance plan. The archived data can easily be exported to CSV and safely stored outside of Salesforce before deleting records from the Salesforce table.
Salesforce also defines a concept called Data Skew that occurs when there are more than 10,000 child records associated with the same parent. This can not only make queries slower, but affect list views, reports, dashboards, and sandbox refreshes. I’ve heard requests from clients in the past to have generic accounts to hold child records or numerous contacts that had the ability to reach 10,000 tied to a single parent. A much better design to meet the client request would be to divide the parent records using an intuitive data point, such as region or state/province to ensure the limit is not approached.
When there are or will be a huge number of records in a table, use custom indexes and skinny tables to optimize search performance. Indexing aligns the records of a table in a specific order so they can be found more quickly. Skinny tables contain a subset of fields from a table so more rows can be returned in a search. This greatly speeds up the search process, especially at scale.
Record visibility starts with Organizational Wide Defaults (OWD) and record ownership. Always set the defaults to the most private setting that will be needed. For most companies, that is private for Accounts, Contacts, and Opportunities, but some organizations are totally open with all objects across their own employees. The main items that will affect scalability that you should be cognizant of are:
- Ownership Skew
- Complexity of Role Hierarchy
- Excessive Sharing Rules
Ownership Skew is similar to Data Skew, but pertains specifically to record ownership. Skew can occur when one person owns more than 10,000 records of a single object. Validate proposed ownership during design and ensure the business plans to disperse record ownership.
Many businesses believe the Role Hierarchy should mimic the organizational structure of the business model. Most organizations are swayed in this direction with the naming conventions of roles which will lead to a very deep and complex hierarchy. The role hierarchy should be used to expand visibility beyond OWDs. Group roles based on necessary record access needs, not role names.
Sharing rules should also be monitored closely to ensure that visibility isn’t dependent on excessive rules. Try to use the OWDs and role hierarchy to minimize sharing rules where possible. Salesforce recommends you limit ownership-based sharing rules to less than 100 per object.
Not sure about sharing rules and who can see what in Salesforce? We’ve got a great overview for you that breaks down these topics:
- Object Access with User Profiles
- Org Wide Defaults
- Record Access With Roles
- Permission Sets and User Access
- Field Level Security
- Record Types & Access
Below are the best practices to limit transaction complexity:
- Use Flow instead of process builders and workflow
- Complexity of Transactions (number of callouts within transactions)
- Filter Data before automation
Flow has now been enhanced to perform all actions previously performed by Process Builder and Workflow. You should create all low-code automation using Flow, as Process Builder and Workflow will eventually be deprecated. Use filters at the beginning of the flow to ensure only pertinent records are considered for processing and limit the callouts to other processes.
Designing your solution with scalability in mind will ensure that your system will continue to perform in the future when your data has grown and the demands have increased because of customer and user growth.
We’re an Austin-based Salesforce Consulting partner, with a passion and belief that the Salesforce platform’s capabilities can help businesses run more efficiently and effectively. Thanks for stopping by the Roycon Salesforce blog, be sure to subscribe. If you need help, or just feel like talking Salesforce you can always contact us. Thanks for reading and as always, happy building!
Salesforce Solution Architect
Steve Gummere is an accomplished IT professional with strong business acumen and in-depth technical aptitude. Steve has over 20 years of platform experience, making his expertise and experience invaluable. As a Salesforce solution architect with experience as a B2B Commerce solution architect, and functional consultant, Steve designs a vision to solve business problems.