Discover Why We Have Limits in Salesforce
- Describe how Salesforce manages limits.
- Identify the difference between limits, allocations, and limitations.
- Identify the types of limits and allocations that matter to you.
Welcome to the Neighborhood
We’re glad you’re here. This module, and the trail it’s in, are all about how to manage your place in our multitenant environment. Multitenant means many users for one instance or even many instances sharing some resources. No matter your edition, licensing, or app user base, you’re sharing some part of the Salesforce environment with other users. This multitenancy means Salesforce has to set up some rules and limits to ensure maximum efficiency. In this module, we discuss these limits and how to work within them for the best results.
Working within limits is a lot like plotting your route through a city. You have a lot of options. Make a plan, and be prepared to adjust your path along the way. For example, if you’ve ever been to San Francisco, you know there are plenty of hills and intersections. A map can show the shortest way to your destination, but as you navigate the streets there, you can find several steep hills, up and down, along the way. Perhaps a few of the intersections are particularly busy. Knowing in advance can enable you to follow a different, nicer, flatter route and have an easier time. This module gives you the techniques and resources to map the right route for successful designs that avoid limits and all those steep hills.
Whether they admit it or not, every service has limits. “Unlimited” data plans have limits on the rate at which you can use data. A laptop has memory limits. Believe it or not, limits protect your organization. Since Salesforce orgs live in a multitenant environment, we enforce limits to ensure that errant applications or “runaway” processes don’t impact the performance of your organization. Other customers can introduce changes that tie up shared resources. It’s best for everyone to work within known limits so orgs continue to function in a generally efficient and stable manner. With a little foresight, you can achieve your business goals, avoid limits, and enjoy smooth sailing.
Limits, Allocations, and Limitations
First, let’s clarify some terminology.
- Limits are concrete values assigned to features and functionality. Typically, they are numeric. For example, total active rules per object is the current limit for workflow rules. If customers exceed the limit value for any specified feature, it can affect the performance of the noncompliant org. Exceeding these limits also can negatively impact other orgs in our multitenant environment. Other examples of limits include maximum number of Chatter groups per org, or assignment rules, or sharing rules.
- Allocations are constraints that are part of the edition a customer purchases. Established allocations can help you select the edition with the right size and feature set for your organization and budget. Examples of allocations include validation rules per object, custom objects per edition, or users per edition.
- Limitations cover functionality that users can expect from a feature but that are unavailable. Pilot features often have many limitations, but GA features can have them, too. Sometimes limitations arise when you use two features together. Examples of limitations: Historical trend reports are supported only for matrix reports. You can’t import documents into an org using the Data Import Wizard. Search options are unavailable to Chatter Free users.
When You Encounter Limits
An application’s life cycle plays a big role in how to think about certain limits. Think about mapping your trek through a city. You plan a route, and then you follow it. Certain factors affect your planning, and others affect your progress. For limits, these fall into two phases.
These are limits that come into play while you’re working on your new app or customizing an org… during the design and build phase. You plan your route the best you can. For example, the number of picklists you can add to an object is a design-time limit.
These limits happen when, you guessed it, a customer, process, or user is running your deployed app or customization. For example, the limit for the total number of records retrieved by a SOQL query is a runtime limit.
During runtime, you have a category of limits that are time-based. Time-based limits manage the flow of traffic. Think of a traffic signal.
Sometimes you need to wait for the next cycle to cross the street so traffic flows smoothly. The number of push notifications allowed per day is an example of a time-based limit.
This all can sound like an annoyance. You might be thinking, “Why are you limiting me?” But if you think of traffic flow through a city (well-managed traffic flow, that is), it’s for everyone’s benefit. A little management keeps the whole system moving efficiently.
How to Prepare
Most of the time, you won’t even know what the limits are. Salesforce manages operations for you and keeps things running smoothly. But as your app scales, your user base grows, and it’s important to keep your org or app at peak performance. You can’t predict the future, of course. You design your app or customize your org with the information you have. Sometimes, these design decisions don’t scale well, or requirements change. With a little practice, you can learn the right ways to stay on top of all this growth and demand. You can plan the best route forward.
Do a little research early in your design process (like earning this badge!). We recommend you know some common design patterns and types of apps whose demand tends to grow quickly. Following are some common scenarios where reasonable designs end up in unforeseen territory—where customers approach our limits.
An app with many simultaneous users that performs callouts to external systems
For example, in a call center application, many users generate synchronous transactions in a Visualforce page. If the application integrates with other systems by using callouts, you have lots of callouts running simultaneously. When the response from the callout takes longer than 5 seconds, you reach the limit on concurrent long-running transactions.
Frequent API calls
For example, a Sales Cloud application connects to a legacy on-premises data store. A middleware-style integration connects the data together to replicate changes from one system in the other. This middleware makes many requests for information, especially when the transaction volume is large, and can encounter the daily API call threshold for your org.
Reports and dashboards with a lot of filters
For example, you share a weekly sales report with a lot of filters to narrow the scope of the report. Over time, the number of objects, users, and filters has increased. The report now takes many times longer to render results than it initially did. You need to fine-tune it so you spend more time looking at the results than running the report.
A lot of activities (tasks and events)
For example, your regional sales teams share contacts, leads, and opportunities. They track meetings with customers and related files. You’re building your own contact management app. As your customer base and sales teams grow, you need your app to stay responsive.
Notice a pattern? These are all growth stories. A successful app, report, or customization must scale gracefully. We can give you some insight on how to stay successful even as your demand grows.
What You Can Do
OK. You’ve done your planning. Your app or customization is in production. You want to keep things running smoothly. Here are the things to do.
- Monitor usage (reports, UI, and so on)
- Right-size your org
Need more storage? The answer might be to get an upgrade.
- Take advantage of Salesforce add-on products (like Salesforce DX, Marketing Cloud, and so forth)
- Stay successful (use the Trailblazer Community success site )
For example, to solve your storage problems, you can come up with an archiving strategy based on discussions and information from the community.
Generally, be prepared to make smart decisions using the features and capabilities of Salesforce. The modules and challenges in this trail can give you some practice making situational decisions to keep yourself, your org, or your app efficient.