Salesforce Functions Overview and Architecture
Why Salesforce Functions
Salesforce Functions lets you extend Salesforce business logic to meet any demand. With Functions, you write code in industry-standard programming languages, and run your code within the Salesforce trust boundary. When your code runs, it automatically scales with load and doesn’t count against your Salesforce request limits.
Salesforce Functions lets you use industry-standard programming languages and frameworks. Your team now can use their preferred language and tools to develop Salesforce solutions, instead of having to write or re-write code in a Salesforce-specific language. Your Salesforce app can now use open-source or third party frameworks, saving you development time and effort.
Salesforce Functions securely and seamlessly works with your existing org resources, making it easy to stay on the Salesforce Customer360 platform. 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 an external system access your org.
With Salesforce Functions, you can perform compute-heavy tasks that would be difficult or impossible to do in your org. Salesforce elastically scales compute resources for your Functions for you, meaning you don’t have to manually modify compute resource configurations every time you update your Function.
Salesforce Functions Infrastructure Overview
Salesforce Functions are deployed to, and run in, a secure Salesforce-managed infrastructure separate from your Salesforce org. This has application lifecycle implications that require understanding how Functions are deployed, where they run, and how they’re associated with orgs.
A Salesforce Function is code that performs a specific compute task. You could 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 your org or run in your 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 Functions 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.
Your Salesforce org can be connected to one or more compute environments. When you deploy your Salesforce DX project that contains Functions, you specify an org that will be invoking the Project Functions. The Functions deploy process will use your org information and the Project name to determine which compute environment to use or create. For example, if you wanted to test your “Billing” Project in a sandbox org, you’d deploy your Project, specifying your sandbox org, and the deploy process would determine the compute environment to use and automatically connect your org to this compute environment.
When you need to invoke a Function from your org, you specify the project name and the Function name. Because your org is already connected to a compute environment, the invocation process knows exactly which compute environment to use. You don’t have to specify the compute environment, which ensures that you can’t, for example, accidentally run your in-development Function in a compute environment connected to your production org.
Currently the infrastructure for Functions compute environments is located in 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.