Pages

Monday, November 11, 2024

CRM Analytics: Recipe formula syntax in Transform node

For those who have used Dataflow in the past and migrated to Recipe recently, some of the syntax and functions are different from SAQL in Dataflow.

1. string
use ' instead of "
in SAQL, case when 'Data.Name' is null then "No" else "Yes" end
in the recipe, case when "Data.Name" is null then 'No' else 'Yes' end


2. operand in comparison
in the recipe, equal, use = instead of ==
unequal, use !=


3. operand logic
in the recipe, use AND or OR


4.  instr() to replace index_of() 
Syntax: instr(field, searchString, [position, [occurrence]])
instr('123!456!78!', !) -- the result is 4
instr('123!456!8!', !, [4])  -- the result is 7
instr('123!456!8!', !, [4, [2]])   -- the result is 9
case when instr(Email, '@ap') > 0 then 'APAC' when instr(Email, '@eu') > 0 then 'EMEA' else 'AMER' end


5. to_timestamp() to replace toDate()
in SAQL, case when 'Region' == "APAC" then toDate("2024-01-06 21:00:00") 
else toDate("2024-01-07 11:00:00") end

in the recipe, case when "Region" = 'APAC' then to_timestamp('2024-01-06 21:00:00') else to_timestamp('2024-01-07 11:00:00') end

The output type from to_timestamp is Date Time.


6. Formula in Compute Relative
Make sure the "Multiple row formula" is selected
in SAQL, case when previous(CaseId) is null  then "Yes" else "No" end
in the recipe, case when lag(CaseId) IS NULL then 'Yes' else 'No' end


7. format_number() to replace number_to_string()
in SAQL, case when 'OwnerHistory.OwnerChangeCount' is null then "00" else number_to_string('OwnerHistory.OwnerChangeCount',"00") end

in the recipe, case when "OwnerHistory.OwnerChangeCount" IS NULL then '00' else format_number("OwnerHistory.OwnerChangeCount", '00') end


8. Date/time comparison
in SAQL, case when ('CreatedDate_sec_epoch' >= StartDateTime_sec_epoch) && ('CreatedDate_sec_epoch' <= EndDateTime_sec_epoch) then "Yes" else "No" end

in the recipe, case when (to_unix_timestamp(CreatedDate) >= to_unix_timestamp(StartDateTime)) AND (to_unix_timestamp(CreatedDate) <= to_unix_timestamp(EndDateTime)) then 'Yes' else 'No' end


9. substr()
Formula substr() has no change in recipe
case when substr(OwnerId, 1, 3) = '00G' then 'Yes' else 'No' end


10. IN() function
in SAQL, Type in ["Transfer", "TransferredToSbrSkill"]
in the recipe, Type IN ('Transfer', 'TransferredToSbrSkill')
 


Reference:

Sunday, August 11, 2024

Navigating Salesforce's Governor Limits (Part-2)

How to Manage Governor Limits in Salesforce: Key Challenges and Best Practices

This is the continuation of Part 1, a guest blog post by Dorian Sabitov.



Governor Limits are crucial for keeping Salesforce's multi-tenant environment running smoothly and efficiently. However, they can also present significant challenges for developers, especially when building complex applications or scaling existing solutions. Understanding these challenges is key to effective Salesforce development.

Common Challenges with Governor Limits

1. Hitting SOQL Query Limits

One common issue developers face is exceeding the limit on SOQL (Salesforce Object Query Language) queries. This often happens with complex or inefficient queries. When the query limit is surpassed in a single transaction, it triggers a runtime exception and causes the transaction to fail.

Impact: This disruption can interrupt operations, lead to data retrieval issues, and require code refactoring, consuming valuable development time and resources.


2. Exceeding CPU Time Limits

Apex code execution has strict CPU time limits to prevent any single transaction from monopolizing processing power. Exceeding this limit is a frequent challenge, particularly in large-scale or resource-intensive applications.

Impact: Transactions that surpass CPU time limits are terminated, interrupting business processes and degrading user experience. Identifying and optimizing inefficient code is essential but can be time-consuming.


3. DML Operation Limits

Salesforce restricts the number of DML (Data Manipulation Language) statements, such as insert, update, delete, and undelete, within a single transaction. Exceeding this limit causes transaction failures.

Impact: Developers must batch DML operations or use more efficient design patterns to stay within limits, adding complexity to the development process.


4. Heap Size Limits

Heap size refers to the memory allocated to an Apex transaction. Handling large data sets or complex objects can easily exceed the heap size limit.

Impact: Exceeding heap size can lead to memory overflow errors, causing transactions to fail. Developers need to optimize code to manage memory usage effectively.


5. API Call Limits

Salesforce sets daily and concurrent limits on API calls to ensure fair usage among all tenants. Exceeding these limits can halt integrations and disrupt data flow between systems.

Impact: This can affect external system integrations, leading to delays in data synchronization and operational inefficiencies. Monitoring and managing API usage becomes critical, especially in scenarios involving Salesforce SAP integration. Proper planning and optimization strategies are essential to prevent these issues and maintain seamless integration.


6. Email Sending Limits

Salesforce imposes limits on the number of single and mass emails that can be sent. Reaching these limits can be problematic for organizations relying on Salesforce for email communications.

Impact: Hitting email limits can hinder marketing campaigns, customer notifications, and internal communications. Developers need to implement alternative strategies for email delivery when limits are reached.


7. Data and File Storage Limits

Storage limits for both data and files can pose challenges, especially for organizations with large amounts of data or extensive document management needs.

Impact: Exceeding storage limits necessitates data archiving, deletion, or purchasing additional storage, adding costs and operational overhead. Efficient data management strategies are essential to mitigate these issues.


Best Practices for Managing Governor Limits

Effectively managing Governor Limits in Salesforce is essential for ensuring optimal performance and stability. 

1. Optimize SOQL Queries

Efficient queries are crucial for staying within SOQL limits. Consider the following practices:

  • Selective Fields: Query only the necessary fields to minimize resource usage.

  • Indexed Fields: Use indexed fields in WHERE clauses to speed up query execution.

  • Limit and Offset: Handle large data sets incrementally with LIMIT and OFFSET.

  • Avoid Nesting: Minimize nested SOQL queries to reduce complexity and execution time.


2. Implement Batch Processing

Batch processing helps manage large data volumes within limits.

  • Batch Apex: Use Batch Apex to process records in chunks, distributing the workload.

  • Scheduled Apex: Schedule batch jobs during off-peak hours to spread resource usage.


3. Efficient DML Operations

Optimizing DML operations can significantly reduce resource consumption.

  • Bulk Processing: Perform bulk DML operations using collections instead of single-record operations.

  • Prevent Recursive Triggers: Design triggers to avoid recursion and use static variables to control trigger execution.


4. Manage Heap Size

Effective memory management is key to staying within heap size limits.

  • Scoped Variables: Limit the scope of variables to ensure they are garbage collected.

  • Transient Variables: Use transient variables in Visualforce controllers for temporary data.

  • Efficient Structures: Use efficient data structures and algorithms to minimize memory usage.


5. Optimize API Calls

Proper API call management helps avoid exceeding daily and concurrent call limits.

  • Reduce Call Frequency: Cache data locally and batch requests to minimize API calls.

  • Monitor Usage: Regularly monitor API usage and set up alerts for approaching limits.

  • Asynchronous Processing: Use asynchronous methods (Future methods or Queueable Apex) for non-urgent tasks.


6. Efficient Email Practices

Optimizing email sending helps manage Salesforce email limits.

  • Third-Party Services: Use external email services for high-volume needs.

  • Batch Emails: Send mass emails in batches to stay within limits.


7. Effective Storage Management

Managing storage efficiently helps avoid data and file storage limits.

  • Archive Data: Move outdated or less accessed data to external storage.

  • Limit Field Tracking: Track only essential fields to reduce storage consumption.

  • File Compression: Compress large documents and attachments to save space.


Tools for Monitoring and Diagnostics

Salesforce offers various tools to help monitor and diagnose resource usage, making it easier to manage Governor Limits.

  • Debug Logs: Monitor Apex code execution, workflow rules, and other processes to identify inefficiencies.

  • Salesforce Optimizer: Receive recommendations for improving performance and staying within limits.

  • Apex Exception Emails: Configure to get notifications when limits are exceeded for quick resolution.

By following these best practices, developers can effectively manage Governor Limits, ensuring their Salesforce applications are both performant and compliant. Efficient query optimization, batch processing, and smart resource management are key to navigating these constraints. Additionally, it can be beneficial to hire a Salesforce consultant who can provide specialized expertise and guidance, helping you overcome these challenges and optimize your Salesforce environment. Moreover, leveraging Salesforce's monitoring and diagnostic tools enhances the ability to stay within limits and optimize performance.


Wrapping Up

By following these best practices, you can manage Governor Limits effectively and build applications that perform well and scale smoothly:

Write Efficient Code: Efficient coding is key to staying within Governor Limits. This includes such things as optimizing SOQL queries by selecting only necessary fields, using batch processing for handling large data sets, managing memory carefully by limiting the scope of variables, and using efficient data structures.

Monitor and Manage: Regularly monitor and manage API calls and email practices to avoid hitting daily or concurrent limits. Use asynchronous processing methods to spread out the workload and prevent bottlenecks.

Leverage Salesforce Tools: Use Salesforce's tools for monitoring and diagnostics, like Debug Logs and Salesforce Optimizer, to keep an eye on resource usage and spot areas for improvement. Setting up Apex Exception Emails can also alert you when limits are exceeded, so you can act quickly.

Handle Storage Wisely: Avoid hitting data and file storage limits by archiving old data, tracking only essential fields, and compressing files to save space.

Remember, the goal is to deliver a great user experience while staying within Salesforce's resource management guidelines. That’s all my friend! With a good understanding and strategic approach, you can overcome the challenges of Governor Limits and make the most of the Salesforce platform.




Wednesday, July 24, 2024

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



Page-level ad