Salesforce Order Management: A closer look

In Part 2, we take a closer look at how Salesforce Order Management can be used in your technology landscape, what customization and setup of the platform looks like, and what to watch out for in your implementation.

Naturally, the most important part of any order management system (OMS) is its ability to track the order lifecycle from the point at which a customer clicks Purchase through to the moment the package arrives on its intended doorstep. But between these two steps, a lot goes on behind the scenes:

• Orders from one or more sources are created in the OMS for tracking.
• Availability of the items in the order are verified, fraud checks are executed, and the customer’s payment might be authorized.
• Typically within a separate warehouse management system (WMS), items from the order are picked and packed, shipping labels are generated (sometimes for multiple shipments), and the orders go out, with the WMS all the while sending updates to the OMS.
• When the order is fulfilled, the customer’s payment is captured, and invoices are usually generated and sent to an enterprise resource planning (ERP) system.
• Throughout the process, the OMS will be keeping the customer informed with email and text message updates.

The OMS is the centerpiece of all of this and is the central recordkeeper for all these statuses. It can be seen as the order “orchestrator,” ensuring that as orders move through the various stages of their lifecycle, internal and external processes can be coordinated, while keeping service agents as well as customers informed of any key steps. Additionally, the OMS is responsible for keeping track of returns and cancellations, which can come in from self-service, external systems, or via Salesforce Service Cloud.

Salesforce Order Management Object Model

Salesforce Order Management adds many new objects to your Salesforce environment as well as utilizing some standard objects that are already within your Salesforce system. Many of these are beyond the scope of this article, but here are a few you should be aware of.

• Order and order items. These are default objects that predate Salesforce Order Management. They represent the intent of the customer to purchase goods and are the first objects created in the process. Order and order items objects are generated from Salesforce Commerce Cloud’s built-in integration, API calls, or integrations with other third-party AppExchange packages. Importantly, after the initial creation of these items, you  never modify them. All downstream changes should happen via change objects (see below).

• Order summary and order product summaries. This is the first place a service agent or a third-party system will look when trying to see who placed the order, its current status, the items that were ordered, total price, and so on. As you might have seen in Part 1, it is the centerpiece of the OMS and where most other data rolls up. When orders are generated (for example, from Salesforce Commerce Cloud), order summaries are not created, however. It is the responsibility of the first key flow in the OMS, the Create Order Summary flow, to create order summaries and order summary items from the original order and order item objects.
• Fulfillment order object and fulfillment order products. The fulfillment order object is the next key object and is responsible for kicking off the downstream processes to fulfill (ship) an order’s items. Fulfillment orders and their products are generated by a flow in the OMS called Create Fulfillment Order. After they are generated, these objects are pushed out to a WMS for further processing, and the WMS returns status updates at various stages. When fulfillment is complete, this is the likely point at which the customer’s payment will be captured and an invoice generated.
• Change objects. Summary objects, described above, are up-to-date, dynamic records of order data. In order to modify order data, for example when an item is returned or exchanged, you don’t modify the original order or the order summary; you create a change order. This allows the various changes in order to be tracked, and the final resting value of the current order summary is calculated from the sum of the original order and all the subsequent changes.

Integrations and OMS Business Logic

Based on the example flows above, you might wonder, “How many integrations must there be from the OMS in order to handle all of this orchestration?” The short answer is “many,” most likely including:

• Order source(s). Sources could include Salesforce Commerce Cloud as well as channels such as Amazon, eBay, and aggregation services like ChannelAdvisor.
• Fraud management systems. Sometimes this is handled within the ecommerce system. Often, however, fraud checks will be done after the order is input into the OMS but before its fulfillment flows start.
• Warehouse management systems. This is where all the fulfillment magic happens, and unless you’re building out a “lightweight” WMS process in Salesforce, which can handle basic scenarios, likely you’ll be sending fulfillment orders downstream and waiting for their messages back with status updates.
• Enterprise resource planning. Often used as a financial system of record, the OMS is generally responsible for sending invoices after fulfillment to the ERP system and sending credit memos after refunds. The ERP system could also serve as the product/pricing master or even be the system of record for customers (accounts). All these cases are potentially necessary for integration.
• Payment providers. At minimum, the OMS will likely need to capture funds after fulfillment, but it sometimes will be responsible for authorization as well.
• Tax systems. Since there are often address changes during fulfillment, you’ll need integration with tax systems to calculate tax rates based on final destination.
• Email service providers. Transactional emails for shipping notifications, tracking updates, return status updates, and so forth all need to be delivered to the customer. Likely, you will not want to rely on Salesforce’s own internal email delivery system for this.

Luckily, there are two advantages to the Salesforce OMS even as a recently released product. First, there is a productized integration between Salesforce Commerce Cloud (B2C only) and Salesforce Order Management that syncs orders, customer data, and products automatically when orders are placed. This is handled by a black-box Heroku system and managed code within both Salesforce Commerce Cloud and the OMS, and is included with Salesforce Order Management. Just open a ticket with Salesforce Support, and you can enable this feature and have data syncing immediately. The second advantage is AppExchange. Integrations with a set of partners at launch time means you can avoid some of the manual integration legwork or middleware implementations by using prebuilt packages certified by Salesforce. Integrations included at launch include:

• Adyen
• PayPal
• Zenkraft
• Avalara

Tying It All Together with the Salesforce Platform

So you have an object model and many manipulations of orders, change orders, fulfillment orders, line items, and more all happening from various integrations. How do you control how and when to make outbound calls to a tax system to calculate rates? Or to an ERP system to post an invoice? This is where the fact that the Salesforce platform powers Salesforce Order Management really shines, with flows, processes, and Apex code.

Salesforce Order Management comes with some prepackaged flow templates you can customize to fit specific needs. As mentioned above, flows such as the Create Order Summary or Create Fulfillment Order offer basic examples of how to generate the necessary objects at the right time. Combined with process builder, these flows can be kicked off when order status fields change, for example, or when a platform event is fired from an external system. It depends on how you choose to architect it, but in many cases, you can take advantage of flows as an editable, easy-to-change way for managing the business logic. Here’s an example:

Flows and the OMS User Experience

The most simple flow that comes prepackaged with Salesforce Order Management is the create order summary, as you can see in Figure 3. It simply runs the action to create the order summary after linking it to the original order’s ID. But what if you want to wait until you authorize payment before you generate the order summary? You can accomplish this by adding an Action to the canvas above and setting it, for example, to make a callout to Cybersource to authorize payment. AppExchange packages can include actions, or you might choose to write your own invocable Apex methods to do any number of custom things.

Flows can be more complex as you start to use screens to capture user input, and can contain more branching logic and fault handling. But this is where the real power of flows becomes evident. Being able to take user input for indicating which items he or she wants to return, the quantity, and the reason, and guiding the user through the entire process, really ties what’s available in the Salesforce Lightning interface into the logic of the OMS. Flows can be launched at various times—by button click, autolaunched when a record in a particular state loads, or even from an external platform event.

To write your own screen flows, you can use custom Lightning components or build screens by using the New Screen builder. This allows you to capture input, do address validation, send SMS messages, or whatever you may want to accomplish in your UI. Examples could include RMA processes, warranty claim processing, or an interface to collect interaction information after a call.

Getting More Advanced with Apex

Apex is the back-end language for customization on the Salesforce platform and is a simplified version of Java. With Apex, you can write custom triggers, batch jobs, REST endpoints, logic controllers for custom components, and more. Within a typical OMS project, these are likely the types of work you will encounter. Where flows might not handle the flexibility or volume needed for a certain case, Apex can definitely become very useful. For example, it’s common for the OMS to “wave,” or send batches of fulfillment orders to a WMS. You can do this by writing an Apex batch job that runs at a specified interval, querying for all the eligible orders, and producing Lightning platform events or API calls to MuleSoft or the WMS directly.

What's Next

Hopefully this overview has enhanced your understanding of Salesforce Order Management features and platform integration. In Part Three of this series, I’ll provide an implementation primer—pointing out the crucial things to be mindful of, such as common integration patterns and key project planning components. The Astound team has been delighted to be able to work on some new and exciting implementations of Salesforce’s latest commerce-related product, and we’ve learned a thing or two in the process.