Functions run “outside” of your org in an elastic compute infrastructure that frees you from having to worry about many Salesforce org limits. Additionally, when invoking your Function, some Salesforce-side limits, such as API call limits, are adjusted to make sure Functions can scale to your needs. There are, however, some Salesforce Functions limits that you still need to keep in mind while developing your Function.
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:
|Max timeout for 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 limit||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 |
|Max number of concurrent synchronous long-running (over 5 seconds) Function invocations||10 per org||For beta, run-time includes Function execution time, however this will be excluded when Functions is generally available. Consider using asynchronous invocation instead of synchronous invocations.|
See Apex Governor Limits for more details on Apex limits.
Function Execution Limits
The following table lists limits for Functions deployed and running in compute environments.
|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 asynch||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 asynch||This only applies to the response data from the Function 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 code makes to the org that invoked the Function. Keep in mind if you're using the Functions SDKs, such as the Node.js or Java SDKs, data API methods in the SDKs are using Salesforce web service APIs as well.
|API requests per 24 hour period per org||For beta, same as API limits. Will increase when Functions is generally available||Currently API requests from Functions are counted against the maximum API requests for a given org (this applies to the Functions beta only and may change once Functions 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||Same as API limits||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.|
Normal platform limits apply to "downstream" actions invoked via the API. For example the Apex CPU time limit will apply to DML operations that invoke triggers.
Note that the UnitOfWork class in the Node.js and Java SDKs use the Composite Graph API for calls to your org, and therefore has the same limits as described in Composite Graph API limits. For example, your Function code can only reference a maximum of 15 different nodes/objects in one UnitOfWork transaction.
See API Request Limits and Allocations for more details on API limits.