Retail chains growing their omnichannel operations hit an inventory visibility wall faster than they expect. Each store's POS shows that store's inventory. E-commerce shows warehouse inventory. Customer service shows a snapshot that's usually yesterday's. When a customer asks "do you have this in my size at the store near me?", nobody has a complete answer.

The fix teams often try doesn't work. The right fix is two D365 components that exist specifically for this problem.

Why batch exports and per-store databases fail

Nightly batch job exporting to e-commerce. E-commerce inventory is 24 hours stale. Customers order "in stock" items that sold out yesterday. Refund rates climb. Fulfillment teams hate it.

POS devices pulling from individual store databases. Each store is its own silo. Cross-store lookups don't exist. Customer calls one store, they don't know what the next store has, and the transfer-and-hold dance is manual.

Advanced warehouse management only for stores. WMS fits warehouse operations but was never designed to be the cross-channel inventory layer. It's too heavy for stores and doesn't expose real-time views to e-commerce.

The pattern that works

Two components working together:

Inventory Visibility Add-in. A near-real-time inventory service that aggregates stock across locations (stores, warehouses, in-transit) into a single queryable view. Designed for high-read traffic - POS devices, e-commerce pages, and customer service agents all hit the same service with sub-second latency. Physical inventory movements in F&O publish to Inventory Visibility in seconds.

Distributed Order Management (DOM). When an order arrives, DOM looks at inventory across all fulfillment locations and picks the optimal source (closest store, cheapest shipping, highest-inventory warehouse) based on configured rules. Supports ship-from-store, BOPIS (buy online pickup in store), split shipments, and inventory reservations.

Together they give the retail chain cross-channel visibility for both the "where is it?" question and the "who fulfills this order?" question.

How Inventory Visibility scales

F&O's native inventory tables can't serve real-time reads at retail scale - they're optimized for transactional integrity, not high-concurrency queries. Inventory Visibility is a separate service (Azure-hosted, managed by Microsoft) that:

• Receives inventory change events from F&O
• Maintains a denormalized, read-optimized view
• Exposes a REST API for external systems to query
• Supports on-hand, reserved, available-to-promise (ATP) calculations

Retail sites pointing at Inventory Visibility can sustain thousands of queries per second without loading F&O's SQL.

DOM sourcing rules

When an order comes in, DOM evaluates candidate fulfillment locations against rules:

• Distance - closest location to customer
• Inventory level - don't deplete stores below safety stock
• Capacity - store can't fulfill more than N ship-from-store orders per day
• Cost - shipping cost per carrier per zone
• Priority - prefer warehouses during peak, prefer stores during slow periods
• Exclusions - some SKUs can only ship from warehouses, some from specific stores

Rules are configured, not coded. The retail team adjusts sourcing logic seasonally without engineering involvement.

E-commerce integration

The e-commerce platform integrates at two points:

• Display - product pages show ATP from Inventory Visibility, cached briefly but refreshed often. "In stock - ships today" rather than "usually ships in 3-5 days".
• Checkout - the order payload posts into DOM via the order-management API. DOM reserves inventory and creates the fulfillment orders in F&O.

Standard connectors exist for Shopify, Magento, and custom e-commerce platforms. The integration is one-time build, then steady-state.

Store-level POS integration

Dynamics 365 Commerce (the retail product) integrates natively. Third-party POS systems integrate via the Inventory Visibility REST API. Store associates looking up "this in my customer's size at any store nearby" hit one service endpoint.

Reserved vs available

A detail the architecture has to get right: what counts as "available"?

• On-hand = physical stock
• Reserved = committed to other orders, not available for new demand
• Available = on-hand minus reserved
• ATP (Available to Promise) = available plus scheduled receipts within the promise window

Inventory Visibility calculates each of these per location and per aggregation level. The e-commerce site probably displays available; the fulfillment team cares about on-hand; finance cares about reserved.

Get the definition right in the architecture, not as an afterthought.

What ships with the architecture

A working omnichannel inventory stack has:

• Inventory Visibility Add-in configured with location aggregations (store, region, global)
• DOM sourcing rules matching the retail chain's fulfillment strategy
• E-commerce integration with caching tuned to display latency
• POS integration (native for Commerce, API-based for third-party)
• Monitoring dashboard on Inventory Visibility query volume and DOM decision latency
• Runbook for adding new fulfillment locations or adjusting rules

The pattern scales. The teams that fail this architecture are usually the ones who tried to make F&O native inventory serve retail-scale reads. That's not what it's built for. Use the components that are.