Atlas Can
 - 

Intro to Salesforce Functions

Salesforce Functions are code you can run on demand which can be useful for resource intensive processing and automation tasks which you can hand over to functions which can offer an alternative to using Heroku or additional middleware.

The point of them is to reduce infrastructure overhead and reduce development time by integrating more natively to Salesforce. Some possible features are buildpacks, private and public spaces. I think with the introduction of Lightning Web Components and Salesforce Functions, the ecosystem will grow faster with developers coming in from outside the Salesforce Ecosystem.

Now let’s dive deeper to what’s coming and use cases for Salesforce functions. Similar to AWS Lambda functions, they will enable us to scale elastically and run on the demand. Amazon and Salesforce announced their partnership some time ago, and we already see its fruits with Service Cloud voice.

For example, there are contact flows you can use and invoke AWS Lambda functions on demand. An example use case is a callback request that can be asked to the caller if they wait longer than expected in a queue.

In Salesforce Functions, there’s more functionality where we will have native access to Salesforce data and can use languages such as Node.js, Java and Apex. The intended use cases support both declarative, low code and code-based solutions.

As the name suggests, you can do heavy processing for financial calculations or work order generation and leverage event-driven approach for file processing to data validation and cleaning jobs (from my experience this used to require custom integrations, AppExchange solutions or to defer this task to middleware).

These will enable us to get around platform limits like CPU and SOQL limits. There’s also security considerations for 3rd party apps that allow these solutions in the first place, luckily functions will also solve this by providing native access to your Salesforce org.

According to the demos and documentation, there are many ways you can invoke functions. Apex first comes to mind, but you can also call them from Flows, Lightning Web Components, Platform Events. Because the functions themselves can be published with platform-agnostic code (Node.js, Java) we will also have access to many libraries for different use cases that otherwise would be difficult to implement in Salesforce. Functions do not count against your Salesforce request limits and automatically scales will load as well. 

Also, Mohith Shrivastava from Salesforce has a great demo on Apex Hour's YouTube channel, which you can find here.

I’m personally excited the amount of overhead functions can reduce by providing all security and compliance, without limits and without security tokens, identity management and so on.

They will also be supported for easier deployments through Salesforce CLI. Here’s a small sample of commands you can run on the CLI. Functions can be created from CLI and are located under the functions' directory of your project folder. 

The steps to use and setup functions are as follows: 

1.  Enable function development on VSCode from settings
2. You can either use Java or JavaScript at the moment, so you can install their dependencies regarding your choice.
3. Docker Desktop for running functions manually (for testing) 
4. Develop functions with the language of your choice, you can test functions locally and validate them with scratch or sandbox orgs.
5. Deploy them after creating compute environments to manage their application lifecycle. (a computed environment is where your Salesforce functions run, separate from your org infrastructure. Your org can be connected to multiple compute environments).
6. Invoke deployed functions through Apex, Flows or Platform Events etc. 

One tip from documentation stands out where for larger transactions, you can use an SDK that provides a UnitOfWork class to handle them. A UnitOfWork represents a set of one or more Salesforce operations that need to be done as a single atomic operation. This reduces the number of requests back to the org, and is more efficient when working with larger data volumes.

Transactions are helpful in making sure all related data changes are made at the same time, and in a way that can be undone if necessary. UnitOfWork also lets you manage data operations in your transactions. However, currently when using Node.js SDK, you should always have a new instance of UoW after each transaction.

Another thing to consider from the Apex side and Salesforce strongly recommends invoking functions async to get around generous timeout limits. Whether you’re invoking a function async or not, you must commit any DML in Apex so that you do not get a Callout Exception error. Functions run in a different context than Apex so their DML operations are not considered part of the Apex transaction.

Here’s the list of cases where you would get a Callout Exception: 

  • For the Salesforce Functions beta only, the Function is being invoked on an unsupported org type. For beta, scratch, sandbox, and trial orgs are supported.
  • Salesforce Functions isn’t enabled on the current org. For more details on enabling Functions, see Configure Orgs for Functions in the Functions Developer Guide.
  • The Function is being invoked in an Apex test. Functions can’t be invoked in tests.
  • The “Functions” permission set is missing or has incorrect permissions for Function-Invocation-Request. For more details on the correct permissions for Function-Invocation-Request see Function Permissions in the Functions Developer Guide.
  • The provided payload isn’t valid JSON.
  • The Function hasn’t completed deployment to a computed environment or invocation request returns a 404 HTTP error.

There are also a few limits to consider: there’s a 2-minute timeout for response from a non async invoked function, but this limit is increased to 15 minutes for an async invocation and there’s no limit on the total number of them.

As we are learning more about functions, I suggest teams to try out Functions to give feedback and upskill in technologies like Node.js which can solve many problems we used to find ways to get around while developing in Salesforce. Thanks for reading, and I’ll see you in the next post!


Atlas Can

Salesforce Developer
Salesforce Partner EMPAUA

Do you need Salesforce support?

Book a demo and let our team implement smart solutions for your business.

Want to join the team?

Take a look at our job openings and be part of our mission.

Related posts

Ready to start your digital transformation?