Navigating Salesforce's Governor Limits (Part-1)

I assume many of us have at least once encountered this type of error or a similar one: ‘DeleteCaseTrigger: System. LimitException: Too many query rows: 50001’. This error means that you have just hit the Salesforce Governor limits in your Salesforce org. These limits are key to Salesforce development, ensuring the platform stays efficient and reliable even with many users accessing it at once. But what exactly are Governor Limits, and why are they so important?

Governor Limits are rules set by Salesforce to keep shared resources in the multi-tenant environment healthy. Since Salesforce uses a shared infrastructure where multiple organizations (tenants) use the same instance, these limits prevent any single tenant from hogging resources. This ensures fair resource distribution, optimal performance, and system integrity.

Understanding and respecting these limits is crucial for developers. Ignoring them can lead to failed transactions and poor performance, ultimately affecting the user experience. In essence, Governor Limits are Salesforce's way of enforcing best practices and encouraging developers to write efficient, scalable code.

Governor Limits may seem restrictive at first, but they play a vital role in maintaining a balanced and high-performing ecosystem and different implementations, such as Salesforce Commerce Cloud implementation. In the following sections, we'll explore what these limits involve, the challenges they present, and how developers can effectively manage and work within them.

Insight:  

You can encounter the limit error not only when compiling your code but also in other automation, such as Salesforce Flow.

Salesforce Governor Limits error in the Salesforce Flow example

Understanding Governor Limits

To effectively handle Governor Limits in Salesforce, it's important to understand what they are and the various types that exist. AppExchange consultants are professionals who can assist in managing these limits efficiently. In this section, I’ll try to explain Governor Limits and categorize them to help you understand their scope and application.

Types of Governor Limits

Apex Execution Limits

Apex execution limits ensure that no single process consumes too many resources, protecting the overall system performance. These limits include:

• SOQL Queries: Apex limits the number of SOQL queries that can be executed in a single transaction to 100 for synchronous transactions and 200 for asynchronous transactions. For example, if an Apex class tries to execute 101 SOQL queries in a synchronous transaction, it will fail.

• CPU Time: The maximum amount of CPU time allocated for an Apex transaction is 10,000 milliseconds for synchronous transactions and 60,000 milliseconds for asynchronous ones. This prevents any single transaction from overloading the server.

DML Operations Limits

These limits control the number of data manipulation language (DML) operations that can be performed within a single transaction:

• DML Statements: The limit for DML statements (insert, update, delete, etc.) is 150 per transaction. This means that if a process tries to perform 151 DML operations, it will be stopped, and an error will be thrown.

• Records Processed: A single transaction can process up to 10,000 records via DML operations. This ensures that large data operations do not hinder system performance.

Callout Limits

Apex limits the number and duration of external web service callouts to ensure balanced usage:

• Number of Callouts: Each transaction can include up to 100 callouts (HTTP requests or web service calls). This helps maintain the availability of external services.

• Callout Time: The cumulative timeout for all callouts in a transaction is 120 seconds. This prevents long-running callouts from blocking system resources.

Heap Size Limits

The heap size limit governs the amount of memory allocated to an Apex transaction:

• Heap Size: The heap size limit is 6 MB for synchronous transactions and 12 MB for asynchronous transactions. This helps control the memory usage of complex or large-scale processes.

Email Limits

Salesforce controls the number of emails that can be sent to prevent misuse:

• Single Email Messaging: The limit for single email messages is 10 per transaction, ensuring that email services are not overloaded.

• Mass Email Messaging: Limits also exist on the number of mass emails that can be sent, managing server load and preventing spam.

API Limits

These limits ensure fair usage of the Salesforce API:

• API Calls: Each Salesforce org has a daily limit on the number of API calls it can make. This prevents any single org from overloading the system.

• Concurrent API Calls: There are also limits on the number of concurrent API requests, which helps to prevent server overload.

Platform Event and Streaming API Limits

These limits control the usage of platform events and streaming APIs:

• Event Delivery: There is a cap on the number of platform events that can be delivered in a transaction, ensuring that the event processing system is not overwhelmed.

• Streaming API: Limits exist on the number of push topics and the number of clients that can be connected simultaneously to the Streaming API, maintaining balanced system performance.

Storage Limits

Salesforce imposes limits on both data and file storage to manage resources effectively:

• Data Storage: Each org has a limit on the amount of data that can be stored, which varies by Salesforce edition. This ensures that storage resources are used efficiently.

• File Storage: Similarly, there are limits on the amount of file storage available, including attachments and documents.

Why Understanding These Limits Matters

Knowing and understanding these various Governor Limits is crucial for Salesforce developers. It allows them to design applications that are efficient and comply with Salesforce's resource management policies. By adhering to these limits, developers can avoid runtime exceptions and performance issues, ultimately providing a smoother user experience.

Salesforce Governor Limits error in the Apex code example

Wrapping Up

Navigating Salesforce's Governor Limits is important for building efficient and reliable applications on the platform. Understanding the different types of Governor Limits — such as SOQL query limits, DML operation limits, CPU time limits, heap size limits, and API call limits — is essential.

These limits help keep the system running smoothly by preventing any one user or application from hogging resources. Although these limits can seem restrictive, they are designed to ensure fair resource distribution and maintain system performance.

To be continued...

This is a guest blog post by: Dorian Sabitov

Salesforce: Target Object for Create a Record Action Type

We discussed in an earlier blog that we can use an action to "find" a child object; however, for a child object with multiple parent objects, the object may not be available for selection as a Target Object in “Create a Record” quick actions.

Salesforce does not allow to create the actions to related child entity when we have multiple relations of different types to the child entity. 

For Example:

Custom objects A-B with Master-Detail relationship and custom objects A-C with Master-Detail relationship too --> create quick action “Create a Record” on A, you will see both B and C as target objects.

Custom objects D-E with a Master-Detail relationship and custom objects F-E with a Lookup relationship, too --> create a quick action “Create a Record” on D; you will see E as the target object, but create a quick action “Create a Record” on F; you will NOT see E as the target object.

* blue line = Master-Detail and red line = Lookup relationship

Now, change the D-E objects relationship to Lookup, and you will see E as the target object from both D and F.

If you change both the D-E and F-E relationships to Master Detail, you will see E as the target object from both D and F too.

Reference: 

• Unable to choose a child object as Target Object in “Create a Record” quick action when it has multiple relationships.

CRM Analytics: Recipe and Dataflow case sensitive

Key in join node in CRM Analytics is case-sensitive, sample:

The same applies to the augment node in the dataflow; the key is case-sensitive too, sample:

 

 

Salesforce: Custom Object without Tab

It's easy to create a custom tab to create a new record of an object from UI; however, in some scenarios, we (admin) are not supposed to create a custom tab, so how to enter new data from the UI, or to see data created (I know we can use report if that object is enabled for reporting) in UI.

Create a New Record
https://domainname.lightning.force.com/lightning/o/objectname__c/new

View Record in the List View
https://domainname.lightning.force.com/lightning/o/objectname__c/list?filterName=Recent

Once you have landed in the list view, you can create a new list view with filters to see the data as needed.

CRM Analytics: Recipe syntax

Every computer language has its own syntax, the same with query language or formula. Here are the samples of SAQL that are used in Dataflow.

 Since CRM Analytics is moving with Recipe, here are samples of the formula syntax in the Recipe:

String - use '  ', e.g., 'Singapore'

Field name - use "  ", e.g., "Account.Id", optional if the field name does not contain dot(s)

Field with blank value - "Opportunity.Id" IS NULL

CASE, e.g., case when Have_Activity = 'Yes' or Have_Opportunity = 'Yes' then 'No' else 'Yes' end

IN with (), e.g.,
case when Type in ('Customer', 'Other') then 'A'
        when Type in ('Customer - Direct', 'Customer - Channel') then 'B'
        else 'C' 

end

Logical Function
use or, and, e.g., case when Have_Activity = 'Yes' or Have_Opportunity = 'Yes' then 'No' else 'Yes' end

Compare Operator
use != (not <>) as compare operator, also use = (not ==), e.g., Have_Activity != 'Yes'

Current and Previous Quarter

case 

    when quarter(now()) = 2 and (year(now()) = year(LastActivityDate)) then 'Yes' 

    when quarter(now()) = 3 and (year(now()) = year(LastActivityDate)) and (quarter(LastActivityDate) in (2,3)) then 'Yes' 

    when quarter(now()) = 4 and (year(now()) = year(LastActivityDate)) and (quarter(LastActivityDate) in (3,4)) then 'Yes' 

    when quarter(now()) = 1 and ((year(now()) = year(LastActivityDate)) or (quarter(LastActivityDate) = 4 and year(LastActivityDate) = year(now()) -1)) then 'Yes'

    else 'No'

end

Do you have a great formula to share? Feel free to add in the comment.

CRM Analytics: Adding Salesforce Action in CRM Analytics

Here is the step:

1. Create Salesforce Action --  navigate to Salesforce's object manager, look for the object, click on Buttons, Links, and Actions menu, then click New Action.

2. Add the newly created Action to a Salesforce page layout (this is a must).

3. Configure the Action from the CRM Analytics dataset. 

Once configured, if you have a table widget in the dashboard, you can also set up one-click actions, so by clicking the value, the action selected will be performed, e.g., click the value in Account Name to call the action to edit Industry.

Reference:

• Perform Actions on a Salesforce Record from CRM Analytics