Developer guide
The guide is intended for Salesforce developers with hands-on experience. If you're a Salesforce admin user with very little to zero experience in software development, you might want to check out the Business user guide instead to learn how to manage the Spark integration.
Getting started
Feel free to skip this section If you’re already familiar with developing Salesforce (SF) applications. For those who need a refresher, this section covers the basic concepts of Salesforce development.
There are multiple ways to develop a Salesforce application. The most common method is to use the Developer Console, a web-based integrated development environment (IDE). Alternatively, many developers prefer Visual Studio Code (VSCode), which offers a more user-friendly and versatile experience. Before diving in, review the Get Ready to Develop guide on Trailhead.
When using the VSCode approach, it’s important to understand that your local project directory mirrors the structure of Salesforce components in the connected DevHub or Scratch Org. In essence, Salesforce artifacts—such as Apex classes, triggers, and SOQL queries—are represented as files in the project. While most actions you perform in VSCode are executed directly in the Salesforce Org, some exceptions exist, which is irrelevant for this guide.
This development model differs from traditional software development. Think of it as a convenient way to interact with Salesforce components, manage version control, and bundle subsets of components for packaging and deployment, such as publishing apps on AppExchange.

If this seems abstract now, don’t worry — it will all make sense as you progress through the development process.
At the end of this guide, you will be able to:
Create, edit, and query custom metadata objects.
Create and update Apex classes, including unit tests.
Create and update Lightning Web Components.
Prerequisites
Access to Salesforce DevHub or Org
Access to a Coherent Spark account
Additional tools if you're using VSCode are:
Remember to create a scratch org as your developer workspace to avoid introducing unnecessary and/or breaking changes.
Development process
Your primary objective with this integration is to utilize Coherent Spark's Execute API to trigger and invoke your externalized calculations. In simple terms, this involves invoking callouts using Apex.
You can think of the Salesforce development process as being divided into three main phases:
Backend development: create or update Apex classes to manage your integration logic;
Frontend development: create or update Lightning Web Components for user interaction;
Custom metadata: define your Spark configurations as needed.
Phase 1: Backend development
In the backend phase, you’ll use Apex classes to represent the input and output data required by your calculation engine. Since Apex is a structurally-typed language, your classes must match the JSON structure expected by the version of Execute API you choose to work with.
Apex Classes in VSCode
In VSCode, you’ll need to create two files:
force-app/main/default/classes/SparkClient.clsThis Apex class handles HTTP requests to Spark using the configured settings.
You can either hardcode these settings or use custom metadata to fetch them dynamically.
Keep in mind: these settings may include user credentials, so they must be handled securely.
force-app/main/default/classes/SparkClient.cls-meta.xmlThis metadata file is essential for deploying the Apex class to your Salesforce org.
It provides Salesforce-specific details about
SparkClient.cls, such as its name, description, and visibility settings.
Important Note: If there’s a syntax error in your Apex class—something the IDE might not catch—the deployment will fail. Yes, it’s not the smooth developer experience you were hoping for, but that’s how Salesforce operates. Always remember: changes made in VSCode are merely a local representation of what’s actually implemented in Salesforce.
To harness SparkClient.cls, let's now implement a basic use case simulating a callout to Spark service.
The example above of a callout service implementation uses dummy data to refer to Spark settings needed to trigger the calculation engine residing in Coherent Spark. In a real-world scenario, you would want to collect your input data as a custom object from SF, then feed it into Spark to run complex calculations, and finally collect the output data as part of your business data for further processing.
Below is what you'll need to add more unit tests to your test suite for SparkClient.cls:
An HTTP callout mock class to simulate what the backend service would respond with based on a given request.
Then, the actual unit tests for the
SparkClient.clsandSparkService.cls.
Further readings on Apex classes can be found here:
Phase 2: Front-end development
The frontend phase might feel more approachable than the backend development, mainly because it’s more visual and interactive. That is, you'll be creating user-interactive components to enhance the user experience for Salesforce admins.
If you’re already familiar with web development technologies like HTML, CSS, and JavaScript, you’ll find this phase straightforward. If you’re not a web developer, we recommend starting with the LWC Guide to help you understand the basics of Lightning Web Components (LWC) before you can proceed. Roughly speaking, LWC is a Salesforce-proprietary modern framework for building web components. The following resources can help you grasp how LWC works behind the scenes:
Explore design principles and pre-built components with Lightning Design System.
Learn about individual components like buttons, badges, and cards from LWC Component References.
Access examples of commonly used patterns and components from LWC Recipes on GitHub.
LWC Setup in VSCode
In VSCode, your project should look more or less like this:
The files listed above are usually used to configure the LWC block of the Salesforce project. While some of them aren’t mandatory, they play a crucial role in maintaining code quality and consistency. For instance, they help enforce coding standards such as linting and formatting and facilitate running unit tests locally using Jest.
Here’s a quick recall of key tools you should consider installing:
Prettier: Ensures consistent code formatting.
ESLint: Enforces coding standards and identifies potential issues.
Jest: Enables running unit tests locally.
Husky: Runs pre-commit hooks to enforce linting, formatting, and tests before committing changes.
Here's an LWC example using the existing backend service SparkService.cls:
Phase 3: Custom Metadata
Custom metadata in Salesforce stores reusable, deployable configurations for application logic, such as business rules or integration settings. It’s ideal for static data, as records can be queried in Apex without consuming SOQL limits.
Custom metadata also supports custom fields, declarative setup, and seamless deployment between orgs, making it a powerful tool for centralizing and managing configurations efficiently. Hence, it makes sense to store Spark settings such as base URL, tenant name, API key, or other static resources there.
In the example below, an anonymous Apex script (a more direct way to execute Apex code directly in the SF org) is used to query the defined custom metadata object Spark_Settings__mdt and print its content.
What's next?
This was a brief explanation of how to bring your Excel-based calculation logic to Salesforce. There's definitely more that can be done with Spark within Salesforce. Please reach out to the Coherent Sales team for more information.
Last updated
