Salesforce B2B Commerce: The Path Forward
Prior to being acquired by Salesforce, the explosive growth of CloudCraze – a premier SaaS B2B commerce solution – could be explained by its Salesforce-native applications and its speed to market. Users could launch a Default Storefront in as little as 12 weeks and tap into the incredibly lucrative B2B eCommerce market.
If you are unfamiliar with the CloudCraze Default Storefront, it is a base storefront that can have its user interface (UI) and base B2B Commerce storefront experience logic, i.e. product entitlement, payment storage, buying on behalf of, etc., be modified and extended to fit a wide range of business requirements.
As a part of several CloudCraze, now called Salesforce B2B Commerce, implementations, the main gripe has always been about front-end development: the UI is awkward and heavy. Don’t get me wrong, I love working on Salesforce B2B Commerce, but the path forward won’t be just simply extending the Default Storefront. Users will either need to build their own reference storefront with Lightning Communities, or create an integration with their Salesforce instance and leverage a different technology stack.
Why Was Visualforce Used as the Front-End Framework as opposed to Salesforce Lightning?
Note: If you are unfamiliar with Visualforce pages and Lightning pages, see the following articles before you continue reading:
First and foremost, it’s important to understand that a lot of functionality is built around Salesforce Community Cloud. The “Salesforce Tabs + Visualforce Community” is a base Community offered by Salesforce Community Cloud, and all of its pages in the community use Visualforce pages. The Salesforce B2B Commerce managed package has a series of Visualforce pages that take the place of the out-of-the-box “Salesforce Tabs + Visualforce Community”.
When Salesforce B2B Commerce was being developed, “Salesforce Tabs + Visualforce Community” was the standard. Visualforce provides the same HTML, CSS, and JavaScript framework that many Front-End developers are accustomed to, but its UI is a bit cumbersome and restrictive. In addition to a familiar front-end framework, Visualforce will be supported for years to come, as the Classic Salesforce view was built using Visualforce, and older browsers can render Visualforce. On the other hand, Lightning cannot be rendered in older browsers.
Furthermore, though Salesforce Lightning has become more prevalent with its strong UI framework, the Lightning community types still can’t support high-data volume and external data like the “Salesforce Tabs + Visualforce Community” version.
For a more complete list of Visualforce vs Lightning Community capabilities, see the following article:
How do we develop a path forward if we are stuck using Visualforce Communities for our Front-End?
This has been the crux for some time for developing with Salesforce B2B Commerce, but this is where you need start to lean on your Technical Architects and Developers.
Salesforce has robust REST and SOAP API documentation, and Salesforce B2B Commerce is growing its documentation around its REST APIs. Salesforce B2B Commerce has a series of Custom Objects that were built to manage most use-cases of B2B Commerce business logic that can interact seamlessly with Salesforce sObjects. With a strong warning, a “Headless” Storefront can be developed using Salesforce on the front-end, and the Salesforce B2B Commerce managed package for the data and service layers.
The reason for the big warning is that when you go “Headless”, there are several questions you will need to answer:
- How will you and/or the client support the storefront after completion?
- How will you and/or the client manage user authentication and accessibility in scale?
- How can the storefront be managed administratively as opposed to brining in a developer for every fix or upgrade?
Each person and organization will answer these questions differently and create their own unique questions, but it goes back to the fact that the Default Storefront is a reference architecture and just a starting point for most development. The real path forward is what YOU and your organization need, and utilizing your partners and resources to get it done. Salesforce Core and the Salesforce B2B managed package provide the freedom to allow you to build beyond Visualforce Communities if you so choose.
Are my options only Visualforce or “Headless”?
Previously in this article, I discussed the reasoning behind a Visualforce Community being used versus a Lightning Community, and that even though, from a UI perspective, Lightning is absolutely superior, it can’t quite keep up with Visualforce for high-data volume and external data exposure applications.
With that said, Lightning can still be set-up to work with a moderately large volume of data, and there are possible set-ups for exposing external data. For example, though you can only expose external object data with Lightning Customer Service Community, you could write a batch apex class that can map external object data to standard Salesforce Objects, and/or up to 10 Custom Objects, based on Customer Community Licenses.
Lightning is also significantly easier for administrators to design on, develop, and maintain through standard Salesforce configuration and the use of “drag-and-drop” Lightning Web Components. Developers can create Lightning Web Components (and/or Aura Components) that use B2B Commerce-managed package logic classes that have their methods extended to be AuraEnabled.
Though development on a Lightning Community is an avenue, it won’t necessarily be easier in terms of implementation compared to the “Headless” option. Salesforce B2B Commerce’s pages don’t translate to these Lightning Communities, so you will be starting from scratch from a UI perspective. Also, you’ll be connecting your components and pages to the extended or overridden methods in the Salesforce B2B Commerce Logic and Service Classes.
The benefit of going to Lightning as opposed to “Headless,” though, is that Salesforce offers significantly more support in your development journey versus creating, maintaining, and supporting your own custom architecture.
In your opinion, what should be the path forward for Salesforce B2B Commerce?
Start by extending the Default Storefront to the absolute max and having a reference architecture around this model first. Though it is clunky and uncomfortable to develop for the Front-End, the Salesforce B2B Commerce managed package’s Back-End solution more than makes up for it. You can still bring in all of your custom CSS and JS libraries, with some caveats. For example, SASS needs to be compiled into its corresponding CSS file before it’s deployed, each static resource containing your library or libraries must be less than 5 MB in size, and to identify each resource, you will need to extend the B2B Commerce User Interface class or create a JavaScript method that adds these references to the Head element tag on page load, but you can extend the UI to your needs.
The next step is your organization opting to either build out a new Default Storefront in Lightning or go “Headless”. Salesforce B2B Commerce is great with how storefront data and logic is handled for a B2B Commerce implementation and these aspects are available as REST APIs, along with being native on Salesforce.
This article has outlined key considerations for both routes along with some potential next steps, but the reliance for a Front-End framework should not be on Salesforce B2B Commerce, but on how YOU and your organization want the direction to go.
