Welcome to Salesforce Functions

Salesforce function introduction

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 StandardsDevelop complex business logic using the languages and tools of your choice.
  • Scale Elastically on Trusted InfrastructureDeploy and run your Function in a Salesforce managed elastic compute infrastructure.
  • Deliver Connected ExperiencesIntegrate your Function securely and easily with your org.

Why Salesforce Functions

Salesforce Functions extend Salesforce business logic to meet any demand. With Functions, you can write code in industry-standard programming languages like Java or Node.js using SDK, and run your code within the Salesforce trust boundary. Your Salesforce Function is automatically authenticated to the org invoking your Function at run-time, meaning that you don’t have to worry about dealing with authentication, or any of the other complexities of making external systems access your org. When the code runs, it automatically scales with load and doesn’t count against your Salesforce request limits.

With Salesforce Functions, we can perform compute-heavy tasks that would be difficult or impossible to do in Salesforce org. Salesforce elastically scales compute resources, which means that you don’t have to manually adjust compute resource configurations every time you update a Function.

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.


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:

Description Limit Considerations
Max timeout for a response from synchronously invoked Function 2 minutes Consider using asynchronous invocation instead of synchronous, or splitting up work into multiple Functions.
Max number of asynchronous Function invocations from Apex No limits Asynchronous Function invocations are not counted against the maximum number of asynchronous Apex method executions for an org. Apex callbacks for asynchronous Function invocations are otherwise identical to other asynchronous Apex usage restrictions (like future annotations) at runtime.
Max number of concurrent synchronous long-running (over 5 seconds) Function invocations 10 per org For beta, run-time includes a Function’s execution time, however this will be excluded when Functions is generally available. Consider using an asynchronous invocation instead of synchronous invocations.

Function Execution Limits

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

Description Limit Considerations
Execution time 15 minutes Consider splitting up the work of your Function into separate Functions, or separate phases of the overall workflow you’re trying to accomplish.
Process memory 1 GB Consider splitting up the work of your Function into separate Functions, or separate phases of the overall workflow you’re trying to accomplish.
Payload size 6 MB synch, 12 MB async Large data files, such as image or video files, should not be passed as part of the Function payload. Instead, store the data externally prior to the invocation and reference the data by URL.
Response size 6 MB synch, 12 MB async This only applies to the response data from the Functions sent back to Apex, not to the total amount of data that can be written back to the org.

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.

Description Limit Considerations
API requests per 24 hour period per org For beta, the same as the API limits. It will increase when Functions are generally available. Currently, API requests from Functions are counted against the maximum API requests for a given org (this applies to the Function’s beta only and may change once the Function is generally available). Use UnitOfWork classes in the SDKs or the Composite Graph API to reduce the number of API requests.
Concurrent long-running API requests The same as the API Limit. Long-running requests are requests that take 20 seconds or longer. Consider moving long-running requests into the org — for example, move a complex data operation into Apex and have the Function utilize this code via Apex REST, or perform the complex data operation in the Apex callback code from an asynchronous invocation.

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.

Back to overview