Adobe Commerce Order Management on Hyva: Integrating an OMS for Multi-Channel Fulfillment

Adobe Commerce handles order management natively through Multi-Source Inventory, which assigns stock to sources and routes fulfillment with a source selection algorithm. A dedicated OMS adds distributed order routing for BOPIS, ship-from-store, drop-ship, and marketplaces. On a Hyva storefront, live stock and order status render through section data without breaking full page cache.

What order management means in Adobe Commerce

Order management is the set of processes that take an order from checkout to delivery: capturing the order, deciding which location ships it, reserving and decrementing stock, generating shipments, and reporting status back to the customer and to connected systems. In Magento 2 and Adobe Commerce, most of this lives inside the platform itself rather than in a separate product.

The native order lifecycle is straightforward. An order is placed, payment is authorized, an invoice and shipment are created, and the order moves through states like pending, processing, and complete. What decides the physical fulfillment side is Multi-Source Inventory, the inventory model that has shipped with the platform since Magento 2.3.

There is a common point of confusion here that matters for planning. Adobe once sold a separate SaaS product called Magento Order Management, sometimes branded Magento Commerce Order Management or MOM. That product reached end of support in October 2024, and its documentation is now archived for reference only. So when someone asks about “Adobe Commerce OMS” as a shrink-wrapped Adobe product, the accurate answer is that it no longer exists as an actively supported offering. What you have today is native MSI inside the platform, plus the option to integrate a third-party distributed OMS. Our work across Magento and Adobe Commerce builds starts from that reality rather than the old MOM marketing.

How Multi-Source Inventory works

MSI separates two concepts that older Magento merged into one number. A source is a physical place stock sits, such as a warehouse, a store back room, or a third-party location. A stock maps one or more sources to a sales channel, usually a website. On-hand quantity belongs to sources. What the customer sees on the storefront is the salable quantity, a computed figure that subtracts open reservations from the aggregated source stock.

When an order is placed, the platform does not immediately reduce source quantity. It writes a reservation, a ledger entry that lowers salable quantity so two shoppers cannot both buy the last unit. Actual source quantity only changes when you create the shipment. This reservation system is the mechanism that prevents oversells during the window between checkout and fulfillment, and it is worth understanding in detail because it is where high-volume stores most often see problems. We cover the failure modes in Adobe Commerce inventory reservations explained.

The other half of MSI is the source selection algorithm (SSA), which decides which source or sources fill an order when you create a shipment. Adobe Commerce ships two built-in algorithms:

• Priority. Each source has a numeric rank. The algorithm fills from the highest-priority source that has stock, then falls through to the next. This is the default and it suits merchants with a clear primary and backup warehouse.
• Distance Priority. The algorithm recommends the closest source to the shipping address, calculated either through Google Maps or an offline geocode database. This shortens transit and can lower shipping cost when you have geographically spread inventory.

The SSA is extensible. The InventorySourceSelectionApi module exposes service contracts so a developer can add a custom algorithm, for example one that weighs carrier cost or labor capacity. Adobe’s own Inventory Management documentation covers the source and stock model in full.

Where native MSI is enough

For a large share of merchants, MSI covers order management without any external system. If your operation looks like the following, native inventory is usually the right call and adding an OMS would be cost without payback:

• One to a handful of warehouses under your direct control.
• A single storefront, or a few storefronts sharing the same stock.
• Fulfillment that is you-ship, from your own locations, on your own carriers.
• Order volume that your team processes through the Admin or a light ERP connection.
• No requirement to promise inventory across channels you do not control.

MSI handles multi-warehouse routing, backorders, low-stock thresholds, and per-source shipment splitting through the standard Admin. Displaying that inventory accurately on the storefront is its own task, and we walk through it in Multi-Source Inventory on a Hyva storefront.

When you need a dedicated distributed OMS

A distributed order management (DOM) system routes orders dynamically across many fulfillment nodes, including stores, distribution centers, and suppliers, using rules like cost, proximity, capacity, and live availability. You reach for one when order flow crosses boundaries MSI was not built to manage. The clearest signals:

• BOPIS and curbside. Buy online, pick up in store needs real-time store-level stock, a reservation held for the shopper, and a store associate pick workflow. MSI can model store sources, but it has no native picking app or curbside handoff.
• Ship-from-store. Turning stores into fulfillment nodes needs routing that balances store labor, protects store selling stock, and reassigns when a store rejects a task. That orchestration is a core OMS function.
• Split shipments across independent networks. When a single order draws from your DC, a store, and a drop-ship vendor at once, and each needs its own tracking and status, a DOM coordinates the pieces.
• Drop-ship and marketplace supply. Routing lines to third-party suppliers, sending purchase orders, and ingesting their shipment confirmations is vendor-network work an OMS specializes in.
• Selling on marketplaces and multiple storefronts. When Amazon, a B2B portal, and your DTC site all draw from shared pooled inventory, you need one system that owns available-to-promise across every channel.
• Complex sourcing economics. If you route by margin, carrier SLA, or minimizing split shipments rather than simple priority or distance, the OMS rules engine goes well past the two built-in SSAs.

The pattern is consistent. MSI answers “which of my warehouses ships this.” An OMS answers “across all my locations, stores, suppliers, and channels, what is the best node to fulfill each line, and how do I keep every channel’s promise honest.” B2B operations tend to cross that line early because of split fulfillment, drop-ship, and account-specific sourcing, which is why it comes up often in our B2B and integrations practice.

Native MSI vs dedicated OMS capability matrix

Third-party OMS options

Several established platforms integrate with Adobe Commerce. Positioning below reflects each vendor’s stated focus; confirm current capabilities and fit against your own requirements during selection, and do not treat any of these as an Adobe-endorsed default.

• Fluent Commerce. A cloud-native distributed OMS that treats every store and warehouse as a peer fulfillment node, with a stated strength in BOPIS and ship-from-store at high volume.
• Kibo Commerce. A unified commerce and OMS platform covering BOPIS, ship-from-store, curbside, and a fulfiller UI with pick-wave and substitution handling, positioned for both B2C and B2B.
• IBM Sterling Order Management. A long-tenured enterprise OMS with deep B2B and retail roots, delivered as SaaS, covering real-time inventory visibility and omnichannel orchestration.
• Brightpearl and Linnworks. Retail operations and multichannel listing platforms often chosen by mid-market merchants that need inventory, purchasing, and marketplace sync more than heavy store-fulfillment orchestration.

Vendor fit depends on where your complexity actually sits: store fulfillment, supplier networks, marketplace breadth, or B2B account rules. We size that against the commerce platform during evaluation rather than starting from a preferred badge, an approach that carries across our full technology partner relationships.

Integration patterns that hold up

Connecting an OMS to Adobe Commerce is a systems integration problem, and the patterns that survive production are the same ones that survive any high-throughput integration.

Own the boundary with an anti-corruption layer. Do not let OMS data models bleed into Magento or the reverse. A translation layer keeps each system’s schema independent so a vendor change does not ripple through your storefront.

Move events, not polling loops. Adobe Commerce raises events across the order lifecycle. Publish order-placed, invoice-created, and shipment-created events to a message queue the OMS consumes. Push inventory and status updates back the same way. This decouples the two systems so neither blocks the other during traffic spikes.

Make every message idempotent. Networks retry, queues redeliver, and a shipment confirmation can arrive twice. Every handler must key on a stable identifier and safely ignore duplicates so a retried message never double-decrements stock or double-ships an order.

Decide who owns inventory truth. The most common failure is two systems both claiming authority over available-to-promise. Pick one. Usually the OMS owns cross-channel availability and pushes salable figures to Magento, while Magento keeps the reservation ledger for its own checkout. Write that contract down before any code.

Reconcile on a schedule. Event streams drift. A periodic reconciliation job that compares OMS and Magento stock and flags variance catches the small gaps before they become oversells or phantom stockouts.

For Adobe Commerce specifically, API Mesh and GraphQL can consolidate these connections behind one endpoint the storefront queries, which keeps integration logic off the frontend.

Rendering order status and live stock on Hyva without breaking full page cache

This is where a fast storefront and a live back end usually collide. Full page cache exists so a page renders without touching PHP. Anything customer-specific or fast-changing has to arrive separately, or you lose the speed that made a Hyva theme build worth doing.

Hyva’s model makes this cleaner than Luma. Customer-specific values ride on customer section data, loaded by a single Ajax call after the cached HTML renders and kept in browser local storage. It refreshes when data ages past an hour, when the private_content_version cookie changes, or after a POST action, and you can force a refresh by dispatching reload-customer-section-data. Adobe’s approach and the theme’s simplification are documented in the Hyva sectionData guide.

Apply that model by matching each data type to how fast it changes:

• Slow-changing status such as “In stock” or “Low stock” can sit inside the cached page with a sensible invalidation, since it does not change per request.
• Live figures such as a per-unit salable count, an account-specific price, or an order’s current fulfillment state belong in a section or a lightly cached block that loads after the shell.
• BOPIS availability by store should be a small Ajax query against the OMS or the salable-quantity endpoint, triggered when the shopper picks a store, never baked into the cached product page.
• Order status on the account page reads from Magento’s order record, which the OMS keeps current through the event stream, so the storefront never calls the OMS directly on a customer request.

The rule of thumb: cache the page, deliver the person’s data on top. Keep the OMS out of the synchronous render path, and it can be as busy as it needs to be without slowing a single page. This same separation is what makes Hyva a good frontend for other platforms too, and we apply the pattern on BigCommerce, Shopify and Shopify Plus, and Shopware storefronts as well.

A phased approach

Order management projects fail when a team tries to switch everything at once. Phasing lowers the risk.

1. Map the current order flow. Document every path an order takes today, every location, channel, and manual step. You cannot route what you have not mapped.
2. Exhaust native MSI first. Configure sources, stocks, priority or distance SSA, and low-stock rules. Many merchants find MSI covers more than expected once it is set up properly.
3. Name the specific gap. Write down the exact capability MSI cannot deliver, whether that is store picking, drop-ship, or cross-channel ATP. That gap is your OMS requirement, and it keeps selection honest.
4. Pilot one flow. Integrate the OMS for a single scenario, for example ship-from-store in a handful of locations, using events and idempotent handlers. Prove reconciliation holds before expanding.
5. Expand by node and channel. Add stores, suppliers, and marketplaces one group at a time, watching reservations and stock variance at each step.
6. Wire the storefront last. Only after the back end is stable do you surface live availability, BOPIS, and status on Hyva through section data.

That sequence protects the storefront speed and the accuracy of every inventory promise. It reflects how we approach the work overall at Bemeir: we build it, you sell it.

FAQ

Does Adobe Commerce still offer its own OMS product?

No. Adobe once sold a separate SaaS product called Magento Order Management (MOM), which reached end of support in October 2024 and is now archived. Current Adobe Commerce order management runs on native Multi-Source Inventory inside the platform, with third-party OMS integration available when distributed fulfillment demands it.

What is the difference between MSI and an OMS?

MSI is Adobe Commerce’s native inventory model. It assigns stock to sources, protects against oversells with reservations, and routes shipments by priority or distance. An OMS is a separate system that orchestrates fulfillment across stores, warehouses, suppliers, and channels with a rules engine, handling BOPIS, ship-from-store, drop-ship, and cross-channel available-to-promise that MSI does not cover natively.

How does the source selection algorithm decide which warehouse ships an order?

The source selection algorithm runs when you create a shipment. The default Priority algorithm fills from the highest-ranked source with stock. The Distance Priority algorithm picks the closest source to the shipping address using Google Maps or an offline geocode database. Both are extensible through the InventorySourceSelectionApi for custom sourcing logic like cost or capacity.

Can I show live stock and order status on Hyva without slowing the site?

Yes. Keep the OMS out of the synchronous render path. Slow-changing status like “In stock” can sit in the cached page, while live salable counts, account pricing, and order state load through Hyva customer section data after the cached shell renders. BOPIS availability loads as a small Ajax query when the shopper selects a store.

Which OMS should we choose for Adobe Commerce?

It depends on where your complexity sits. Store fulfillment and BOPIS point toward platforms like Fluent Commerce or Kibo. Deep B2B and enterprise orchestration point toward IBM Sterling. Mid-market inventory and marketplace sync point toward Brightpearl or Linnworks. Confirm current capabilities against your own requirements rather than picking by reputation alone.