At this point, I’m sure most of us have had exposure to what “headless” means in the context of a commerce application, at the very least you’ve likely seen reference to it!
The intent of this article is to set the understanding of why you’d utilize headless in Salesforce B2B Commerce applications, understand some of the harder concepts you might face, and finally, to talk about how you can apply this general headless concept in real life.
What Is Salesforce Headless Commerce?
In its simplest form, headless commerce is a separation of the front end and back end of an eCommerce application. This architecture offers a brand the freedom to express themselves whatever and however they want. Most importantly, it enables brands to enrich the customer experience. Jon Feldman, Salesforce 360 Blog
In recent years this trend has primarily been popular on consumer facing websites (B2C) such as Adidas and other high volume, high performance commerce applications. These brands want a very specialized experience for their customers, and typically have several different applications/interfaces that need to interact with commerce capability – i.e. the main website, an app, and other applications.
Ever since the pandemic and the surge of focus on the customer experience by B2B brands, we’ve seen this trend of headless start to weave its way into the B2B Commerce space.
What Makes B2B Commerce Different?
While on the surface it may seem like building a Salesforce B2B Commerce application is the same as a B2C application, as you get deeper into the requirements you begin to understand that due to the direct tie between businesses, the needs are quite different.
Yes, both applications have the same base requirements of product detail pages, showing images, showing prices, adding to a cart, etc. However, as shown in the table below, there are a few common B2B Commerce requirements that are different from B2C.
| Feature Requirements | B2C | B2B |
|---|---|---|
| Basic Commerce Pages |  | |
| Account Level Product Visibility | |
|
| Account Level Pricing | |
|
| Volume Discounting | |
|
| Various Payment Methods* |  | |
*Some common payment methods include Credit Card, PO, ACH, Check, Call In CC, Bank Accounts, Credit Memo
Due to these requirements revolving around accounts and the ability to treat each account potentially in a unique way, we have the concept in B2B Commerce called a ‘Buyer Group’ which gives the ability to control a lot of this information.
If you’re curious about learning more about these differences, check out this video that does a deep dive on the subject.
Why Go Headless With Your B2B Commerce Site?
The reasons for going headless with your Salesforce B2B Commerce site really aren’t all that different from a B2C site, it’s the same culprits:
- I need more control over aspects of the front end experience.
- I want my commerce solution to be more composable.
- I already have a headless commerce site and I’d like to replace my current engine with Salesforce.
- I have multiple applications that need to deal with my commerce engine.
If any of these reasons resonate with your situation, you’re probably going down the right path. If you’re looking for a more out of the box solution, I’d encourage you to first check out the standard Salesforce B2B Commerce templates. You can get really far with those templates with very minimal changes.
Degrees of Headless-ness
Now that we’ve established some of the foundations of headless and B2B Commerce, plus the reasons you might consider going down this path, we can get into the fun part.
Before deciding to go headless, you’ll want to figure out how headless you need to be? The more headless you go, the more initial work it’ll take to set up your commerce site and overall architecture.
With that said, let’s get into what each of these degrees of headless-ness entails…
Typical Commerce
We’re going to start with the basics!
A typical B2B Commerce implementation means there is no headless aspect. The out-of-the-box Salesforce B2B Commerce solution provides a comprehensive solution for all the data, visualization, and configuration needs.
| Pro’s | Con’s |
|---|---|
| Pre-built functionality. | Must build UI within Experience Cloud capabilities (Aura / LWR). |
| Quicker Setup. | Will likely be slower than a headless site. |
The diagram below shows what this looks like from an architecture perspective:
- In the top yellow box, you have Experience Cloud, which is where you start with a template and standard components to build your commerce site.
- In the next layer down, you have your core data model, which is used as the source of truth in most Salesforce environments.
- Lastly you have the backend capabilities of Commerce Cloud, which fuels the data and interaction layers between your UI and data.
Partial Headless
In this partial headless option, the concept is that we’re using a combination of the pre-built solution and the headless solution. There are dozens of different ways to slice this up because it largely depends on which parts you intend to have headless, and which parts you don’t.
| Pro’s | Con’s |
|---|---|
| Utilize pre-built functionality for the most challenging aspects of the solution. | Must deal with authentication between the headless site and Salesforce. |
In the example I’ve prepared (below) we’re using a combination of the B2B Commerce platform and a Heroku app which could use a React frontend with Node.js as the backend (or really any other technology you’d like there).
In our example, the Heroku app is doing quite a bit, so let’s break it down:
- Heroku is our headless site, so this is where the home page, product category page, product detail page, and any other supporting pages would be hosted.
- In our example, we’re using Heroku Connect to synchronize data between Salesforce and a Postgres DB in near-real time. Our pages are then pulling data from the local DB for the product details. This is only one option though, if you’d like a more API driven approach, you could substitute out that local DB and Heroku Connect with synchronous calls to Salesforce utilizing the Commerce Cloud Unified APIs. We’ll talk more about this in the Full Headless section!
- In order to reduce the complexity of this solution, we’ve kept the “Cart” and “Checkout” functionality in the standard B2B Commerce solution. In order to do that though, you’d need to create a service that can dynamically manage the cart for you between what you’re doing within Heroku and the data that lives in Salesforce.
- Lastly, when I’m finally ready to view my cart or checkout, we’ll need to handle the SSO between Heroku and Salesforce. This can be done in multiple different ways, but it’s important to consider JIT (Just In Time) provisioning so your users never get stuck on an unauthorized page.
At the end of the day, this type of solution provides you with the flexibility you need on the vast majority of pages, such as Product Detail, without taking on the technical requirements to build a full checkout and order process.
Note: This option could be a good idea if you’re looking to do a phased approach to a headless commerce implementation!
Headless
We’re finally here! We’re at the pinnacle of the mountain we talked about earlier in this article – a full headless commerce site.
| Pro’s | Con’s |
|---|---|
| Full flexibility and composability to the commerce solution. | Longer time to go-live and potentially more work to maintain the site long term. |
We’ve kept the basic structure of the example we used previously, but you can tell there are some changes to the solution to tilt it towards a full headless commerce site:
- Heroku is now managing the full lifecycle of the product → cart → checkout → order.
- We’re managing all of the users’ interactions through the Unified Commerce API. These APIs allow us to retrieve product details, add to cart, move a cart into checkout, and eventually place an order for the user.
- On the Heroku side, we’ll need to manage lightweight Node routes that allow us to facilitate the interaction between our React frontend and the Salesforce API.
- In this example, there is no synchronizing data, all of this is happening immediately by using the Salesforce API, so the source of truth remains 100% Salesforce.
Typical, Partial, or Full Headless?
Now that we’ve gone through all of these options, you should have a better understanding of the pros and cons of each. There is no right or wrong way, just what makes sense for your business based on the needs you have.
If you want to learn more about how to get started on a solution like I mentioned, keep reading! We’re going to dive into the nuances of the commerce API and provide a few examples.
Want to Get Started Developing a Headless Site on B2B Commerce?
One of the first things you should do before diving into developing is map out the features and pages you’ll need commerce data to support. This could include product information, searching, adding to cart, checkout, etc.
This diagram gives a partial representation of pages and interaction points you’d need to support. You’ll notice that depending on the pages or interaction it sometimes may require several APIs to connect your headless site.
Let’s answer the questions now, where do I get started?
- Identify the use cases.
- Begin to map the use cases to the available APIs.
- Setup your storefront so you can begin testing (See this video for a quick start).
- Build a postman collection to test each API and the data you receive (See this video and postman collection for a starter on how to do this).
- Begin to connect these APIs into your choice of technology (for example, Node.js / React.
Summary
After reading this article, I hope you understand why you’d utilize headless in Salesforce B2B Commerce applications, some of the harder concepts, and how you can apply this general headless concept in real life.
Interested in a live example of this with B2B Commerce and a Node.js / React app? If you’re attending Trailblazer DX, stop by my session “Going Headless with B2B Commerce”, or stay tuned for a follow up session on my YouTube channel!
Comments: