Why Salesforce’s AMPScript Functions aren’t flawless yet?

A brief look at the shortcomings of popular Sales & Service Cloud AMPScript functions.

Why Salesforce’s AMPScript Functions aren’t flawless yet?

Context:

The integration of Salesforce’s Marketing Cloud Engagement and Sales and Service Clouds through Marketing Cloud Connect provides the capability to create, read, and update records in Salesforce Objects using AMPScript Functions.

I often use these functions in implementations such as lead registration forms, custom preference centres, and personalization in triggered emails.

However, there are a few shortcomings in these functions; let’s examine some of the limitations:

Disclaimer: These limitations are based on my personal experience and may not apply to all use cases.

A) Batch Processing:

Recently, I worked on a project that required updating multiple records in a Salesforce Object using UpdateSingleSalesforceObject via a CloudPage. The project was a custom preference centre that allowed users to update 10 different preferences, each of which corresponded to a record in the Salesforce Campaign Member Object. However, the Salesforce AMPScript functions are limited to processing individual records at a time.

If you wish to process multiple records in a single request, you would need to execute these functions multiple times in a loop, which results in significant processing latency.

Ideal Solution: By introducing the capability to batch process multiple records in a single request, such as the function UpdateBatchSalesforceObjects, the processing latency could be greatly reduced, thereby improving performance overall.

B) Core SSJS Support:

One of the significant challenges of utilizing these Salesforce functions is that they are exclusively available in AMPScript. This means that in order to implement a solution without utilizing AMPScript, a hybrid approach incorporating both AMPScript and SSJS will be required.

If you desire to implement your solution using the hybrid approach, it will be necessary to encapsulate AMPScript functions within the TreatAsContent SSJS function. (Refer to the below reference section for more detail.)

Ideal Solution: Since SSJS has become an essential part of SFMC implementations, it would be beneficial to have the option to access Salesforce functions within the Core SSJS Library. This would eliminate the need to wrap AMPScript functions with TreatAsContent and simplify the implementation process.

C) Overhead and Concurrency:

The Salesforce functions are known to have high latency in processing times, and generally, each function execution takes approximately 1 second (although it may vary) to process.

It should be noted that using the RetrieveSalesforceObjects function to personalize an email campaign with the FirstName field directly from the Contact object for a list of 1 million subscribers could take up 2,777 hours of processing time, which is equivalent to 115 days — 🤯absurd right? (It should be noted that this is an estimation and the actual processing time may vary.)

Disclaimer: You are solely responsible for the application of this theory and any risk incurred.
It is highly recommended to use Synchronized Data Extensions with Lookup functions when personalizing or retrieving content from Salesforce Objects as they are more efficient for performance.

A recent inquiry with Salesforce support confirmed that the Salesforce AMPScript functions have additional overhead processes compared to Lookup functions that do not follow the same procedure. (see below for the exact response).

(Salesforce Support Case Response)

Ideal Solution: Without any architectural insight, I can only assume that Salesforce could improve its AMPScript operations by reducing overhead costs and increasing concurrency for faster operations.

References: