How Salesforce pushed the platform boundaries with event-driven architecture and LWCs
In one of my latest project, we used an event-driven architecture and LWCs to provide as much as possible business capabilities on the Salesforce platform. I would like to share my experience and why I think Salesforce pushed the boundaries of the platform.
Creating a complex CPQ solution for an enterprise customer on the Salesforce platform has never been easy. There is always the question of which functionality to offer on and off the Salesforce platform. Many CPQs are characterized by a multi-tool solution. As a result, salespeople frequently have to switch between multiple systems and need to be both process and system experts to get the most out of their digital environment.
To remedy this problem, Salesforce has invested a lot into evolving its core platform recently. They came up with Platform Events and Lightning Web Components, and more recently with Salesforce Functions. All three components allow enterprise architects to evaluate the issue of which functionality to provide on and off the platform from a different angle. In one of my latest projects we had the opportunity to use most of the new features and I would like to share my experience.
End-2-End CPQ Solution for an Enterprise Customer
With the introduction of a new product line, one of our automotive customers want to establish a holistic sales solution. The goal was clear: Covering the whole B2B sales process on one platform, with the following objectives from a management perspective:
- Strategic Pricing (Offering a margin-based deal optimization)
- Transparency (Sales Funnel)
- Improved user experience (Speed, Flexibility, Operability)
These business goals were to be implemented on the Salesforce platform. The core elements of the solution were supposed to cover all aspects of a CPQ solution. A proposal should contain the defined vehicles and enable the sales user to add additional services, parts, and financing products. The Sales Rep should have access to all sales related information in real-time — including the KPIs and figures, as well as a stock (inventory) check to determine whether a similar vehicle is available for their customers.
Solutioning
From an architecture standpoint, we aimed for isolated capabilities and functions. Consequently, we based our solution on the new tools Salesforce introduced to their platform.
Event-Driven Architecture
From previous experience, we knew that CPQ solutions can hit various governor limits, such as SQL query limits or APEX heap size limits. The solution can quickly end in nested logic triggering itself infinitely often. Therefore, we decided on a change in our application design pattern and focused on an event-driven architecture to decouple services. This gave us the opportunity to implement asynchronous logics where we needed them. We dodged governor limits, where business processes allowed us to run the application asynchronous. We had greater flexibility in designing our solution because the new tools gave us the freedom to use many of the delivered capabilities independently, which made it much easier for us to adjust the business logic where we needed to, and last but not least we were able to parallelize the implementation process.
For example, we could call an event specifically each time we needed a re-run of the ‘vehicle feasibility check’ (which is quite complex). If a sales rep changes the configuration of some parts, a re-run is triggered in the background, running asynchronously. In contrast to a ‘classic’ Salesforce implementation, we therefore did not end up with a huge, complicated trigger framework and the question: “When should we fire a check?”
For integration, we used Platform Events based on a fire-and-forget pattern. This lightweight approach helped us to speed up the overall performance on the platform, for example by communicating with various microservices (e.g. document generation) independently.
The system has now been live for 1 1/2 years, and we have not yet noticed any event that was not published as expected. From my perspective, the Event-Driven framework gives a development team much more flexibility and freedom. Should the business logic be executed within a transaction, or can it be executed asynchronously? Similarly, for our architecture team, it was possible to focus much more on the overall performance of the application.
Lightning Web Components
Regarding user experience, performance, and feasibility of the whole project, we spend a lot of time and effort designing and utilizing Lightning Web Components. From an UX perspective, we aimed for a holistic view within Salesforce. A sales rep should have all necessary information available in one view on the screen. Therefore, in close coordination with the customer, we designed a Sales Steering Cockpit containing multiple grids based on the various offer types.
In doing so, we did not only use the UX advantage. Lightning web components (LWC) are custom HTML elements built with HTML and JavaScript. We adopted LWCs at an early stage of the project in 2019. This occasioned us to rethink if the business logic should be executed on the server side or “just” in the browser. This ended up helping us a great deal by giving us the opportunity to add many functionalities into our solution and increase the usability for the end user. We designed the LWCs in the way that the sales rep can remain in the same cockpit view throughout while fulfilling his tasks.
As LWCs dispatch standard DOM events, it allowed us to create an interface based on grids and establish a solution where the grids can interact with each other and share data. In some scenarios, we utilized the ‘lightning message service’, an event-based communication service between the LWCs across DOMs, to pass parameters across our grid-system.
To give a simple example: If you change the service configuration in the service grid, this also influences (and updates) other LWC components in the grid. The LWCs interact with each other — the pricing information updates in real time — without requiring server-side operations all the time. The sales reps always have full transparency of the price, the bundles, and the provision offered to their customers — and what is best: without having to change or update the screen. Everything happens in one cockpit view. From a business perspective, this creates a new holistic view on the sales process and helps the sales reps to prepare an offer much faster. Giving the sales reps the ability to cover complex pricing calculation scenarios in a comprehensive and simple manner was key for the success of the project.
With the introduction of Salesforce Functions, we have already begun to consider which capabilities can be moved to Functions to extend the scope of the solution and increase the overall performance. Therefore, we already started a few proof of concepts to figure out how Functions can be integrated into our solution.
Conclusion
Delivering a large project like this is always intense. Looking at it retrospectively, the experience has been eye-opening: Salesforce has pushed the boundaries of the platform. With the introduction of Platform Events, LWCs and recently Functions, many new business capabilities can now be implemented in the Salesforce platform. What is more, they can now be executed in real-time and thus deliver exceptional performance. This has drastically changed the sales process of the customer: sales reps can now ‘really work’ with various offerings to provide the customer the best possible experience while retaining full transparency of the entire sales process. The project has been a great success story for our customer, and it was showcased at the Dreamforce.
