Monitoring Salesforce API calls, storage usage, outgoing emails and other resources and limits
Like many other cloud platforms Salesforce monitors and limits resource usage on its instances (orgs). User count is the most obvious example as it drives monthly customer charges, however there about 50 other limited resource types* such as numbers of scratch orgs, dashboards, mass emails sent and others.
Organizations that use Salesforce as a ‘vanilla CRM’, typically do not need to worry about anything else than user counts and data storage. This however changes when adding more Salesforce components such as quoting, order processing, billing or integrating with third party systems.
This post provides information on monitoring resource usage as well as addressing problems with reaching the limits.
* Based on the return of v50.0 of the limits API
API calls
API calls are the only integration interface to Salesforce. They are used by third-party tools and add-ons such as backups, reporting tools, etc. as well as custom integrations. API calls are a metered resource and have 24 hours’ limits. When the limits are exhausted, Salesforce becomes inaccessible until usage counts are re-set.
| In our experience, the most common problem with exhausting API limits by far is inefficient programming. Please take a look at his section below for possible remedies. |
Checking your limits
API limits are dependent on many factors (type of org, edition, number of users, additional API purchases, etc.) and can be checked in Setup → Company Settings → Company Information:
Obtaining detailed information
API usage consumption details are available from the API Usage Last 7 Days report, which is only available in the classic experience. To access the report:
- Switch to classic user experience (user profile icon → Switch to Salesforce Classic)
- Choose Reports from the menu bar
- Navigate to the Administrative Reports folder
- Select the API Usage Last 7 Days report
The limits API call returns fewer details, i.e. only information for the last 24 hours:
"DailyApiRequests":
{
"Max": 375000,
"Remaining": 270012,
... individual application statistics follow ...
}
Building a better client
Salesforce REST API returns the current usage with every response in a Sforce-Limit-Info response header: Sforce-Limit-Info: api-usage=1212/15000 The code below is an example of how to retrieve the value in Java using Apache HttpClient (error handling omitted for simplicity):
String apiUsage = Arrays.stream(response.getHeaders("Sforce-Limit-Info"))
.filter( h -> h.getName().equals("Sforce-Limit-Info"))
.findFirst()
.get()
.getValue();
... parse the apiUsage string and take action ...
This strategy is implemented by the Nextian RMM, which integrates Salesforce with NMS/RMM/Observability systems.
Setting up alerts
It is possible to set up API usage alert notifications via Setup → Environments → Monitoring → API Usage Notifications (more information). At Nextian we recommend setting API notification thresholds as follows:
| 30-40% | Normal level allowing for daily spikes such as extra backups, data warehouse refreshes, etc. |
| 50% | Warning level — system administrators need to examine what is happening |
| 80% | Critical — usually triggers an action to suspend offending user or software package |
API limits remedies
- Optimize programming — ‘bulkify’ requests to Salesforce (i.e., consolidate multiple calls into fewer ones), reduce number of calls by decreasing polling frequencies, etc.
- Purchase more API licenses from Salesforce — this should only be done once options in #1 above have been exhausted.
| Important | Salesforce event log files can be helpful troubleshooting API usage, as they provide detailed information down to individual calls. |
Storage
Salesforce storage is split into object storage (similar to a relational database table row storage) and file storage (similar to relational database blobs).
| The smallest record size in Salesforce is 2Kilobytes regardless of number of fields, therefore storage optimization should start with small but numerous objects. |
Checking your limits
Current storage limits are available (just like the API limits) in Setup → Company Information.
Obtaining detailed information
Detailed storage usage (with per object/row count breakdown) is available in Setup → Data → Storage Usage.
Optimizing storage usage
- Implement a retention policy to delete or archive unneeded records. There are off-the shelf archive packages such as ownBackup Archiver; a backup solution or a replication of Salesforce storage to a relational database can be used to the same effect.
- Consider external file storage alternatives like Box.com when storing large volumes of files.
- Clean up ‘orphaned records’, i.e., records for objects that could not be set up as master-detail and do not get deleted along with their ‘master’ records.
- Look at the detailed storage information and optimize the schema, e.g., replace junction objects with lookups wherever possible.
- As a last resort — evaluate purchasing additional storage from Salesforce.
Outgoing emails
There are three types of email limits in Salesforce, per each origination type (described here). Unfortunately, the usage can be only retrieved via the limits API. For example, for emails sent from APEX code as notifications (‘SingleEmail‘), the limits API returns:
"SingleEmail": {
"Max": 1000,
"Remaining": 920
}
Usage limits may pose problems to organizations sending high volumes of notifications to external contacts (sending internal emails does not count against the limits). Usually, the business process dictates what needs to be sent, so the only way around the limits is to purchase additional email amounts from Salesforce.
Limits API
In essence, Limits API it is a single REST endpoint returning all limits and current usage as JSON data:
<your Salesforce org URL>/services/data/v50.0/limits
It is accessible via any tool capable of working with REST endpoints such as Postman. Detailed information about the API is available here.
Event monitoring
In addition to the Limits API, Salesforce provides Event Log Files (ELFs) containing records of operations (‘events’) happening on orgs. More than 50 types of events are logged including logins, logouts, object access, data downloads and others — the detailed list is available here.
| Important | Production orgs often log only login and logout events — in that case, full logging may require an extra purchase from Salesforce. |
Log files are stored as CSV (comma separated values) files. The log files are only accessible via the API, although tools such as Splunk or Salesforce own Event Monitoring Analytics automate the process of their retrieval and parsing (which is a bit convoluted as shown below).
The list of Event Log Files can be retrieved using the following SOQL query in the Developer Console:
SELECT Id, /* event log file id needed later for content retrieval */ EventType, /* type of events contained in the file */ LogFileFieldNames, /* event type specific columns in the file */ LogFileFieldTypes, /* types for LogFileFieldNames */ LogDate /* log file date */ /* LogFile field contains blob with file CSV content */ FROM EventLogFile
The contents can be retrieved using tools like cURL:
curl --compressed "https://<org instance>/services/data/v50.0/sobjects/EventLogFile/<id from query above>/LogFile" -H "Authorization:Bearer <user token>" -o LogFile.csv
Once downloaded, the file can be further processed.
Conclusions
Like many other cloud platforms, Salesforce monitors and enforces limits on resource usage. For complex implementations with many add-ons and integrations, excessive resource usage can lead not only to unnecessarily high ownership costs but can also make an org unavailable until limits are reset.
Nextian is a vendor of Quote-to-Cash (QTC) software for cloud and communications helping providers accelerate growth and increase customer lifetime value.
Contact us today to find out how we can help you!
