When architecting a solution on Salesforce, one of the design considerations is related to limits and allocations. Because Salesforce is a multi-tenant architecture, Salesforce enforces limits on resources that users consume in order to ensure that one user’s workload doesn’t negatively affect other users. As a user of Salesforce, you want some level of guaranteed performance from the platform.
Limits and allocations are complicated because they come in different shapes and sizes. Here are some of the categories of Salesforce limits:
- Apex governor limits
- API request limits and allocations
- Connect REST limits
- Bulk API and Bulk API 2.0 limits and allocations
- API Query Cursor limits
- SOAP API Call limits
- Metadata limits
- SOQL and SOSL limits for search queries
- Visualforce limits
- Platform event allocations
- Salesforce Function limits
- Email limits
- Push notification limits
- Maps and location service limits
Also, there are limits based on the edition of Salesforce that you are running. For example:
- Personal Edition
- Contact Manager
- Group Edition
- Essentials Edition
- Professional Edition
- Enterprise Edition
- Developer Edition
It is easy to see why there is no easy answer to the question “Will we run into any Salesforce limits in this solution design?” Some level of analysis must be done for each specific situation. Even after analysis, running a series of tests can confirm or deny a limit issue in your design.
To accelerate the analysis related to Salesforce limits and allocations, it’s best to document a set of common design questions to flesh out possible Salesforce limit situations. A standard list can help ensure higher quality solutions. These questions could include:
- What Salesforce Edition is being used?
- What data will be accessed? Read, writes, imports, etc. Does the data reside in Salesforce, in multiple Salesforce orgs or outside of Salesforce? What is the size and type of data?
- What specific SOQL and SOSL queries will we need? What jobs will we need? Batch, real-time, near-real-time, etc.
- … and many more…
Bring your developers and architects together to document this list of questions and keep iterating on it.
In summary, developing knowledge of Salesforce limits and allocations as well as creating a standard, documented way of analyzing a solution design will accelerate higher quality solutions. It will make testing more robust and you will run into fewer production issues.
In a follow-up blog, I will articulate common architectural design patterns that can help avoid running into Salesforce limits (eg leveraging Heroku, Mulesoft, etc.)
Helpful links below…
https://help.salesforce.com/s/articleView?id=000386730&type=1
