Omnichannel Retail Data and Dynamics 365 F&O: How Teams Discover the Commerce Scale Unit

Six weeks into scoping a new Adobe Commerce integration, a home goods retailer's implementation team was already deep in the design work when the business added a requirement: a third physical location, opening in four months, with a mandate that the storefront show real-time stock by store instead of a single warehouse total, and with the retailer also fielding buy-online-pickup-in-store (BOPIS) requests. 

In reaction, the team's first idea was to extend the OData integration they'd already scoped. They would add a custom endpoint for store-level inventory and poll it more frequently than the standard nightly sync.

Then they mapped out what that endpoint would actually need to know beyond quantity: which units were already reserved and which were mid-transaction at a register at that exact moment. But they also found a problem: a custom build could technically be made to work, but it would mean attempting to reinvent the kind of purpose-built retail layers already in the market.

OData for F&O, and its limits

OData is Microsoft's standard framework for exposing Dynamics 365 Finance & Operations business entities. It's reliable, well documented, and does exactly what it's designed to do: move stored records in and out of the ERP for an eCommerce platform, whether that's Adobe Commerce, Shopify, or another storefront. Product descriptions, customer accounts, and completed orders are all well suited to OData because they change infrequently and don't depend on what's happening at a specific location in the current moment.

Store-level availability is a different kind of question, one that depends on what's on the shelf, what's already reserved, and what's mid-transaction at the register right now. OData can tell you a warehouse quantity as of the last sync. But understanding whether a specific store can fulfill a pickup order in the next hour depends on reservations and in-progress transactions. Polling more often isn’t a solution because that data lives in the context of retail channel activity.

Other requirements like pricing and promotions raise similar questions in an omnichannel rollout since they also reside outside the ERP. They drift further from D365FO with each release, which spells ongoing maintenance.

The Layer Between the Storefront and the ERP

The Dynamics 365 Commerce Scale Unit (CSU) closes these architectural gaps. For our home goods retailer working with Adobe Commerce, the CSU served as a purpose-built retail layer that they can deploy instead of a new custom endpoint. CSU is a component of the Dynamics 365 Commerce architecture that sits alongside D365FO.