Salesforce Functions
Salesforce Functions was an elastic compute service that let developers write custom business logic in Java, JavaScript, and TypeScript, then run that code on demand in Salesforce-managed infrastructure that scaled automatically.
Definition
Salesforce Functions was an elastic compute service that let developers write custom business logic in Java, JavaScript, and TypeScript, then run that code on demand in Salesforce-managed infrastructure that scaled automatically. The code ran outside the Salesforce org, in a separate compute environment, and an org invoked it from Apex. Salesforce reached general availability with Functions in October 2021.
Functions is retired. Salesforce ended the service on January 31, 2025, and code that still tries to invoke a function fails after that date. Salesforce now points customers to Heroku for running Java and JavaScript workloads, and to Apex, Flow, or External Services for logic that fits inside the platform. This entry describes what Functions was and how to move off it.
How Salesforce Functions worked and where it went
The problem Functions tried to solve
Apex is the native language for business logic on the Salesforce Platform, and it runs inside strict governor limits. Those limits keep one tenant from starving others on shared infrastructure, but they also cap CPU time, heap, and callout counts. Some workloads do not fit. Think of a nightly pricing calculation across millions of records, a heavy data transformation, or a routine that pulls a popular npm or Maven library. Functions was Salesforce's answer to that gap. It gave developers a place to run compute-intensive or language-specific code without rewriting it in Apex and without standing up their own servers. Because the code executed in a separate compute environment rather than inside the org, it did not count against the org's Apex request limits. Developers could reach for the ecosystem they already knew in Java and Node.js, keep the result inside the Salesforce trust boundary, and invoke it from Apex when a record changed or a user clicked a button. The pitch was familiar languages plus elastic scale, with Salesforce handling the servers underneath.
Compute environments and elastic scaling
A function did not run inside your org. It ran in a compute environment, which is isolated infrastructure that Salesforce managed and connected to the org. One project mapped to one compute environment, and that environment lived in one of six regions: Virginia, Oregon, Dublin, Frankfurt, Tokyo, and Sydney. You picked a region close to your org to keep latency down. When nobody invoked a function, it sat idle and scaled down to use almost no resources. When traffic arrived, Salesforce scaled the compute up to match the load, then back down when the spike passed. Developers never sized servers or tuned autoscaling rules by hand. That elastic, pay-for-what-you-run model is why Salesforce marketed Functions as serverless compute for the platform. The trade-off was that a function lived a network hop away from your data. Each invocation crossed from the org into the compute environment, so chatty code that called back into Salesforce many times per run paid that cost repeatedly. Functions rewarded a coarse-grained design: send a payload, do the heavy work, return a result.
Invoking a function from Apex
Apex was the front door. The functions Apex namespace held the classes you used to find and run deployed code. You located a function with Function.get, passing the project and function name in the form MyProject.myfunction (a namespace prefix was added for cross-namespace access in global orgs). To run it and wait for the answer, you called Function.invoke(payload). That synchronous path returned a FunctionInvocation object holding the response data, and your function had up to two minutes to finish. For longer jobs you queued the work with Function.invoke(payload, callback). The callback was an Apex class implementing the functions.FunctionCallback interface, and Salesforce called its handleResponse method when the function completed. The asynchronous path allowed up to fifteen minutes of run time, and Salesforce noted that it did not count against asynchronous Apex limits such as the Queueable cap. A common shape was a trigger or a screen action that built a JSON payload, invoked the function, and either read the synchronous result or handled it later in the callback.
Limits you had to design around
Functions had its own ceilings, separate from Apex governor limits but just as real. A synchronous invocation timed out at two minutes and accepted a payload and response of up to 6 MB each. An asynchronous invocation ran up to fifteen minutes and allowed 12 MB for both payload and response. An org could run at most ten long-running functions at once, where long-running meant execution past five seconds, so a flood of slow calls could queue behind that limit. Memory was capped at roughly 1 GB per container, and concurrent invocations on the same container shared that budget; crossing it triggered an out-of-memory restart of the container. Consumption was metered per license: about 235,000 requests to the org per 24 hours and one million GB-seconds of execution per month. GB-seconds combined how much memory a run used with how long it ran, so a memory-hungry job that ran for minutes burned the monthly budget far faster than a light, quick one. Planning around these numbers was part of building anything serious on Functions.
Why Salesforce retired it, and when
Salesforce announced that Functions, also called Salesforce Elastic Services, would be retired, and the service ended on January 31, 2025. After that date, Apex code that invokes a function fails, which can break the org behavior that depended on it. The reasoning Salesforce gave was strategic rather than technical: it decided that Heroku would be the primary platform for running customers' Java and JavaScript code. Rather than maintain two overlapping ways to run off-platform compute, the company consolidated on Heroku, which already offered managed dynos, a mature buildpack ecosystem, and tight Salesforce integration through Heroku Connect and the Salesforce APIs. Functions had a relatively short life. It reached general availability in October 2021 and was retired a little over three years later. The lesson for architects is a familiar one: a brand-new platform service carries platform risk, and betting core business logic on it means accepting that the vendor may fold it into another product. Existing customers were told to migrate before their subscription term ended, because continuing to call a retired service was not an option.
Where the work goes now
The right replacement depends on why you reached for Functions. If you only needed logic that Apex could express but were worried about a one-off limit, the honest answer is often plain Apex, sometimes restructured into batch or queueable jobs that chunk the work across transactions. If a business user should own the rules, Flow handles record-triggered automation without code. If the job was really about calling an external API, External Services and Named Credentials let you register an external endpoint and invoke it from Flow or Apex declaratively. The case Functions uniquely served, running real Java or JavaScript at scale, now belongs on Heroku. You deploy your existing code as a Heroku app, expose it as an HTTP endpoint, and call it from Apex with a callout secured by a Named Credential. Salesforce published migration guidance and sample tooling to ease that move. The migration is rarely a copy-paste, because Heroku is a general platform rather than a drop-in for the Functions invocation model, but the underlying language code usually carries over with modest changes to how it is triggered and authenticated.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Salesforce Functions.
Hands-on resources to go deeper on Salesforce Functions.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Is Salesforce Functions still available?
Q2. What are the recommended alternatives?
Q3. What languages did Functions support?
Discussion
Loading discussion…