Welcome to Salesforce functions

Finally, Salesforce Functions became generally available in the Salesforce Winter’22 Release. But before we jump into a deeper discussion of the Salesforce Functions, let me highlight how and where the Functions could be helpful.

Do you have a Salesforce organization with heavily customized Apex triggers that reach Salesforce’s transaction limits? Or, maybe you have complex Apex Batch jobs that hit the maximum number of asynchronous Apex limits? Or, your Apex code makes API callouts and, as a response, gets a timeout exception? If these sound familiar, then a new cool feature called Salesforce Function is for you.

Salesforce Function is a service of the platform that lets Salesforce developers create code that connects data and events. It can run on-demand with an elastic scale in a Compute environment and can be integrated with low-code and pro-code services to deliver an agile and unified Salesforce experience.

The Compute environment, aka Evergreen, is a new serverless environment powered by Kubernetes for the Customer 360 platform that integrates Heroku’s decade-long experience in creating extensible container runtimes and highly efficient data stores with Lighting functionality. Salesforce’s Evergreen Function is equivalent to Azure’s Functions and AWS Lambda.

Key Features of the Salesforce Functions

• Innovate with Cross-Cloud Open Standards – Develop complex business logic using the languages and tools of your choice.
• Scale Elastically on Trusted Infrastructure – Deploy and run your Function in a Salesforce managed elastic compute infrastructure.
• Deliver Connected Experiences – Integrate your Function securely and easily with your org.

Salesforce Functions Infrastructure Overview

Salesforce Functions are deployed to, and run in, a secure Salesforce-managed infrastructure separate from Salesforce org. This has application lifecycle implications that require an understanding of how Functions are deployed, where they run, and how they’re associated with orgs. Salesforce Function Projects are deployed to a Salesforce compute environment. One Salesforce org can be connected to one or more compute environments.

A Salesforce Function is a code that performs a specific compute task. You can now have a Function that reads your sales data and calculates a sales tax, or a Function that collects data and generates a formatted PDF report file. Functions can securely work with org data, but aren’t deployed to org or run in org’s infrastructure.

Functions are contained in the functions directory of a Salesforce DX project. One or more Functions can be included in a single Project. For example, you might have a “Billing” Project that contains a “CalculateTax” Function and a “GeneratePDF” Function. Projects are created using Salesforce DX. You create a DX project that contains your Function code, Function configuration files, Apex code, permissions sets, and anything else necessary for deploying and using the Function. You give the Project a name (via a parameter in the DX project configuration file) which helps identify a Project when deployed.

Salesforce Function Projects are deployed to a Salesforce compute environment. In general, an environment in the Salesforce cloud represents a place where things run. Your org is an environment that runs things like your Apex code or your Flows. A compute environment is where your Functions’ code runs. A single compute environment contains a single Project so that Functions in a Project can run in an isolated and dedicated environment.

Note

Currently, the infrastructure for Functions compute environments is located in the US regions. At this time, compute environments can’t be created in EU or APAC regions. This means that if you have an org in the EU or APAC regions that invokes a Function, the Function will run in an infrastructure located in a US region, and access your EU or APAC region org data from the US.

Salesforce Functions and a Managed Package Solution

Salesforce Functions are not supported in Managed Package functionality yet. The Salesforce team works on this part of the functionality and considers a couple of approaches:

• Create a separate compute environment per Managed Package installation as part of the Managed Package
• Create a separate compute environment per Managed Package installation as part of the customer environment
• Use one shared compute environment for all customers

The Salesforce team actively collaborates with ISVs partners and collects feedback from other partners to better understand the current needs.

Where Salesforce Functions can be helpful

Scenario 1

We have heavily customized logic on Salesforce triggers or other Apex tasks that are reaching the Apex transaction limits. You periodically receive a notification that triggers a reached CPU Time limit, Max SOQL query limit, Max DML operation limits, or similar transaction limits.

Scenario 2

We have a set of Apex asynchronous jobs in the Salesforce environment that have reached the maximum number of asynchronous Apex method executions (batch Apex, future methods, Queueable Apex, and scheduled Apex) per a 24-hour period that is 250,000 executions or the number of user licenses in your org multiplied by 200, whichever is greater.

→ Our insights on Apex Describe Performance

Scenario 3

We have a set of Apex asynchronous jobs in the Salesforce environment that has reached the maximum number of batch Apex jobs in the Apex flex queue that are in a Holding status (limit equals 100), or the maximum number of batch Apex jobs queued or active concurrently (limit equal 5).

Scenario 4

We have an outbound Apex API integration in the Salesforce environment that has reached the Maximum cumulative timeout for all callouts (HTTP requests or Web services calls) in a transaction due to complex logic on the external service side.

Scenario 5

We have a need to backup a large Salesforce data set. There are a few solutions on the market to back up Salesforce data, but these services work with queries and might reach the set limits. The key advantage of the Salesforce Function is that you won’t reach the limits on system queries. So, if you need to deal with big data volumes for backup, the Function is a good option.

Limitations to Salesforce Functions

Functions run “outside” of org in an elastic compute infrastructure that frees you from having to worry about many Salesforce org limits. Additionally, when invoking Functions, some Salesforce-side limits, such as API call limits, are adjusted to make sure the Functions can scale to your needs. There are, however, some Salesforce Function limits that you still need to keep in mind while developing your Functions.

Apex Limits and Functions

Apex code that invokes Functions still runs on your org, and still has the usual Apex limits applied. The following Apex limits have special considerations when applied to Apex code invoking Functions:

Function Execution Limits

The following table lists the limits for Functions deployed and running in compute environments.

API Limits for Functions

The following limits apply to the Salesforce web service API calls your Function’s code makes to the org that invoked the Function. Keep in mind if you’re using the Function’s SDKs, such as the Node.js or Java SDKs, data API methods in the SDKs are using the Salesforce web service APIs as well.

On a Final note

Salesforce Functions are a welcome addition that are well-suited for building integrated and scalable apps. Though not without imperfections, their integration capabilities, elasticity, data accessibility, etc. make it much more comfortable to extend the solutions with custom code applications. Avenga will keep watching the developments of the Salesforce ecosystem and implementing them into first-hand experiences, so that we can ensure our clients get their full Salesforce investment into their quality deployment and timely project implementation.