Get Started with Salesforce Commerce Extensions

Extensions are a mechanism for using Apex to customize the functionality that powers B2B and D2C storefronts. The custom Apex class that implements an extension is called an extension provider. An extension provider can extend or replace the default functionality of a commerce domain. Extensions are available for a wide range of commerce domains, including cart, pricing, inventory, and more.

For the complete list of extensions that you can customize, see Available Extensions.

Extensions represent the next step for Salesforce Commerce extensibility that began with integrations. Extensions allow you to customize functionality in a more targeted way than integrations. Also, extensions are available for more commerce domains than integrations.

Here is a summary of the key differences between integrations and extensions:

Although extensions are now the preferred way to customize Salesforce Commerce, integrations remain fully supported. Currently, payments can’t be customized with an extension.

Extensions can be used by a wide range of developers. An in-house team or a systems integrator can create an extension provider to make small, targeted changes to a storefront to meet a merchant’s unique business needs. For more comprehensive solutions, a vendor can bundle several extension providers together and distribute them as a package on AppExchange.

Extensions unlock new opportunities to integrate Commerce Cloud with other software (such as ERP systems), cut maintenance costs, and deliver great customer experiences.

In the Salesforce Commerce architecture, extensions can interact with many other parts of the system, including other extensions.

This diagram traces how an extension fits into the architecture using Pricing Service as an example.

Let’s look at what’s happening at each stage of the extension flow, as indicated by the corresponding numbers in the diagram:

1. The Pricing Service extension is invoked. An extension can be invoked by a user action, a Connect API request—or even another extension. The extension code checks to see if an extension provider class is mapped to a base class. The code that checks the mapping is called an extension point. The identifier used for mapping an extension point is called an extension point name (EPN).
2. If an extension provider class is registered and mapped to the extension point name, the custom Apex in the extension provider class is executed. The extension provider can optionally make API requests.
3. The extension provider can optionally invoke code from the default implementation using the super() method. The default implementation can also be extended.
4. The extension provider can optionally invoke other commerce domain functionality, which can also be extended.

To show how an extension provider class is constructed, let’s walk through a series of code snippets. The snippets extend the base Apex class for the Pricing Service extension.

Start by extending the base class, which is commercestorepricing.PricingService:

You can override the processPrice method of commercestorepricing.PricingService, which is used on PLPs and PDPs. In this example, we’ve replaced the entire method with custom logic to extract product data, get the price from an external service, and process the pricing response.

The base class has another method that you can override: processTransactionalPrice. Overriding this method affects cart and checkout. For illustration purposes only, we treat this method differently than processPrice. Instead of replacing the entire method with custom logic, we call the base method with the super() method. Although we’re calling the base method, we can still insert custom logic before and after the super() call.

We define a custom private method to get the prices from an external service:

As you can see from this example, you have the flexibility to create extension classes that can:

• Replace the entire default implementation of each base class method with custom logic.
• Add custom logic before calling the default implementation of a base class method.
• Add customer logic after calling the default implementation of a base class method.
• Add custom methods and classes.

To learn how to add your own Apex classes to a Salesforce org, see Adding an Apex Class.

After adding an extension class to a Salesforce org, there are two more tasks required before you can fill an extension slot with a custom extension provider:

1. Register the extension class.
2. Map the extension class to a B2C or D2C store.

The easiest way to register and map extension classes is with Salesforce CLI and the Salesforce Commerce plug-in for sfdx.

To install the plug-in, run sfdx plugins:install @salesforce-commerce.

Example commands:

For detailed installation and usage information, see the plug-in’s README.

You can also register and map an extension provider by inserting custom Apex into sObjects. The setup process for extensions is similar the setup process for integrations. To register an extension provider, modify RegisteredExternalService and to map an extension provider, modify StoreIntegratedService.

Merchants can map and unmap extension providers directly in the administration interface. See Replace a Default Commerce Process with an Apex Class on Salesforce Help.

In this guide we’ve explored how Salesforce Commerce extensions give you fine-grained control over storefront functionality. We’ve examined how extensions fit into the Salesforce Commerce architecture, walked through the construction of an example extension provider, and described the methods for registering and mapping extension providers.

Now that you have a solid understanding of extensions, the next steps are to:

• Explore the Extension Provider Examples.
• Explore the list of Available Extensions and look up the base Apex classes that are relevant to your application.
• Learn more about extension development and testing with other guides, including:
  • Write Tests for an Extension Provider
  • Mock the Base Apex Class