At Astound, we have seen that as clients start to consider placing such an integral “hub and spoke” system into their ecosystem, it causes their eyes to turn toward the other systems within that ecosystem and evaluate whether they are serving the correct role and being utilized correctly within the business process they serve.
The following are three key things to consider as you contemplate adding an order management system to your ecommerce environment.
1. Evaluate your ecommerce ecosystem and processes with your new order management system in mind.
One common example of the sort of evaluation mentioned above might involve looking at transactional emails and what system is responsible for triggering the sending of those emails. We have seen examples where the ecommerce system is sending emails directly, and some in which a warehouse or third-party fulfillment service is sending them. When bringing Salesforce Order Management into the picture, it will likely be appropriate for your order management system to trigger emails through an email service provider (ESP) or marketing platform such as Salesforce Marketing Cloud. Salesforce Order Management should be seen as the master of all orders and their fulfillment statuses and therefore be the “traffic cop” when it comes to customer engagement.
This is one example, but seismic shifts in thinking about processes within the ecommerce lifecycle really become apparent while evaluating integrations to systems such as ERP and accounting, payment gateways, and fulfillment channels. Should the cost of goods sold (COGS) be calculated in the order management system or the ERP system? How about general ledger calculation? Should inventory levels be controlled by an inventory-availability service, or built into the warehouse management system? These mechanisms come in all shapes and sizes and have to be thought of in a holistic manner to avoid additional cost and technical debt.
At Astound, we take the approach of looking at the entire ecommerce lifecycle from beginning to end, beginning with the customer’s browsing experience on the site and continuing all the way through to package delivery and customer review. This might involve more than 15 systems to orchestrate, and each plays a key role.
2. Don’t try to make the order management system something it is not.
Such a drastic change in thinking about the entire order and fulfillment lifecycle across many potential upstream order channels and downstream fulfillment techniques makes for a difficult and confusing process, often causing reconsideration of what the order management system does and what role it should play. It is important, however, to avoid bringing inappropriate functionality into your order management system. Because Salesforce Order Management is built on the Salesforce platform, flexibility and capabilities of the underlying tech stack are ready to tackle things like financial reporting, inventory control, and custom product data models. We usually do not recommend that the order management system serve these roles, however. Instead, something like calculating COGS for each product in an order should be determined by the ERP system, or determined by an integration layer such as Mulesoft that holds that business logic.
Based on these factors, it’s critical that you examine the overall system architecture early on to get a high-level look at what roles each system historically plays and what will change now that there is a new system involved. If Salesforce Order Management is replacing an existing order management system, this might be a bit simpler than if the order management functionality within the organization is spread across many systems and functional areas.
3. Harness the power of Salesforce to power order management.
Building a robust order management system capable of orchestrating complex validation, payment, fulfillment, tax calculation, and more requires a lot of flexibility. This is at the heart of Salesforce Order Management, and it’s why we’ve taken a keen interest in the product and what it brings to the table. Let’s look at some of the flexibility in stages and see how that breaks down.
- Take advantage of declarative platform capabilities. In earlier posts, we’ve looked at Salesforce Lightning Flows and how they bring flexibility to business logic and empower organizations to make changes to business logic without deploying code. We’ve seen that this is especially useful for areas such as order summary generation and fulfillment order generation, especially when you know that something like a remorse period might be turned on or off, or may need to be configured for a different duration. Knowing how to build around this declarative capability and take advantage of things like custom settings, invocable method configuration variables, and so on can help create a powerful environment in which customization and administrative changes can drive flexibility (see Figure 1).
- Know when to bring in Apex for the heavy lifting. Declarative capabilities are great, but sometimes you’ll want to have more control over the execution and flow of the underlying code. This is especially true in high-throughput examples where you may have thousands of orders per second flowing into the platform and requiring calculation. Flows are not necessarily going to be compiling the most optimized code under the hood, so you might want to specifically ensure you’re bulkifying your queries, or queuing your requests to external systems. This is where the Apex programming language comes in, allowing you to carefully craft this logic while still tying it into the declarative flows of the platform.
- Utilize an integration framework such as Mulesoft. As we’ve explored earlier and as you may have experienced yourself, an order management system depends greatly on integrations with other systems to orchestrate the order lifecycle. To ensure you are not taxing the Salesforce platform too heavily with data transformation or business rules, or simply with outbound requests, we recommend that you position yourself for success by using an integration layer between Salesforce Order Management and your external integrations. Of course, if you calculate that the resource utilization of a particular integration is small enough, a point-to-point integration can work and even be preferable—but if you have a large volume of outbound requests or heavy ETL work to do, we do not recommend Salesforce for this workload.
Mulesoft makes a great choice when it comes to an integration platform, because it has some native connectivity via Anypoint Connectors to Salesforce. For example, when you are sending high-throughput messages to a downstream system such as the warehouse, platform events can be published to Mulesoft, which can batch up those CometD messages with its built-in “Subscribe channel listener” and send them down to the warehouse. This provides a lighter-weight alternative to sending lots of REST web service requests to the warehouse and even allows rewind capability, and it’s one example of how you can really boost the performance of the platform and ensure that governor limits are not reached on days like Black Friday.
We’ve had an exciting path so far in our journey with Salesforce Order Management and are excited to see how many customers will benefit from the new product. Hopefully some of our key considerations and learnings will help your organization set up for success as you embark on your own order management journey. You can revisit my previous articles on this topic, “Salesforce Order Management: Three Things to Know” and “Salesforce Order Management: A Closer Look,” and we’ll keep you updated with our findings, recommended approaches, and other things to consider as we continue forward.