DEV Community: Baran Çevik

Dynamics 365 Commerce Architecture: The Reality Behind the Polished Slides

Baran Çevik — Tue, 30 Jun 2026 20:11:14 +0000

Most content explaining Microsoft's Dynamics 365 Commerce architecture follows the same pattern: headless structure, Commerce Scale Unit, hub-and-spoke model, single source of truth. The concepts are correct. The diagrams are clean. But these narratives never ask the critical question: how does this architecture actually work, and where does it break?

This article was written to ask that question.

"Headless" Is Being Used as a Sales Argument, Not an Architectural Decision

Headless commerce is genuinely powerful. Separating frontend and backend, allowing each channel to evolve independently, API-first design — these are the right choices in theory.

But here's what goes unsaid about Dynamics 365 Commerce's headless architecture: when you step outside the Microsoft ecosystem, it creates serious friction.

If you want to truly use it headless — meaning you bring your own frontend — you're wrestling with the Retail SDK. Commerce Scale Unit APIs are not well documented. Some endpoints have only been tested with first-party applications. When you try to customize, the extension model turns out to be far more restrictive than expected. It's not a pure headless experience. It's something Microsoft presents as headless but is, at a deeper level, still tightly coupled.

A team that doesn't know this difference sells the client on frontend freedom, and six months later can't explain why they're rewriting everything from scratch.

Commerce Scale Unit: Powerful Idea, Complex Reality

The problem CSU solves is real and important. Reducing internet dependency in retail environments, ensuring continuity of in-store operations — these are critical concerns in the field.

But anyone who actually knows how CSU works also knows this: standing up and maintaining a self-hosted CSU is its own operational burden.

Version updates are tied to Microsoft's release cadence. If you've customized an in-store CSU, you need regression testing before every update. Synchronization mechanisms work smoothly most of the time, but in edge cases — heavy traffic, large data backlogs after a network outage, conflicting transactions — things get complicated.

Articles say "works without internet, then syncs." That's true. But what happens when that synchronization fails, which conflict resolution mechanisms kick in, and what effect that has on business processes — none of that gets explained.

*Hub-and-Spoke Is a Good Metaphor but Creates the Wrong Expectations
*
The hub-and-spoke model is said to scale local operations while maintaining central control. That's correct, but incomplete.

In reality, that central control has a cost: every configuration change made through Commerce Headquarters — price updates, campaigns, product additions — passes through a chain of distribution jobs. When those jobs run, in what order they're processed, and what happens when they fail requires operational maturity.

You want to launch a campaign at midnight. But if the distribution job didn't run at 11:50 PM, the price never reached the store. The customer saw the wrong price at checkout. This isn't an architectural flaw — but it is the operational reality that architecture creates.

Scenarios like this never appear in any architecture overview. But you run into them in the first week on the ground.

*"Single Source of Truth" Doesn't Work Without Data Management Maturity
*
Dynamics 365 Commerce is described as creating a unified data ecosystem through integration with Dataverse, Azure Data Lake, and other D365 applications. That's true.

But for that integration to work properly, the data being integrated needs to be healthy. Are product masters clean? Are there duplicate customer records? Is inventory data real-time, or does it come from delayed batch processes?

In most retail organizations, the answers to these questions are not satisfying. And no matter how well Dynamics 365 Commerce is integrated, it cannot make dirty data look clean. You can summarize this as "garbage in, garbage out," but that simple formula doesn't capture how large a risk it is to start a project without a data quality assessment.

*The AI Layer: Real or Marketing?
*
"Real-time sales analytics, customer behavior prediction, next best action recommendations" — these are the capabilities attributed to D365 Commerce's AI layer.

Some of them genuinely work. Product recommendations, Copilot integrations, analytics through Power BI connections — these are usable. But for concepts like "next best action" to be taken seriously, you need quality historical data. In a newly deployed or low-transaction-volume system, these models produce meaningless outputs. Machine learning models don't work without sufficient data, and models that appear to be working but aren't reliable quickly destroy trust.

There are many projects that sold "AI-powered commerce" without knowing this, and six months later faced the complaint that "the recommendations are never right."

*POS and Store Commerce: The Least Discussed, Most Problem-Prone Area
*
Store Commerce App theoretically puts everything a store employee needs on a single screen. In practice, customizing this application relies on a complex extension model inherited from the legacy MPOS and CPOS architecture.

Even a simple UI change requires writing Commerce Runtime extensions. Adding a POS trigger requires understanding an event lifecycle with minimal documentation. Integrating peripheral hardware like barcode scanners, printers, or cash drawers requires separate testing for each device, and some combinations behave unexpectedly.

A store operations manager or retail IT team that knows these realities responds very differently to the promise of "everything on one screen."

*The Real Issue Isn't the Architecture — It's the Maturity to Execute It
*
Dynamics 365 Commerce is well-designed. The headless approach points in the right direction. The CSU concept solves a real retail problem. The hub-and-spoke model makes sense.

But all of this architecture only becomes meaningful through the organizational maturity of the people running it.

If you're deploying this architecture for a company without a data management strategy, you don't get a single source of truth — you get multiple sources of inconsistency. If you're deploying CSU for a retailer that hasn't defined its operational processes, you don't get distributed architecture — you get distributed chaos. If you're deploying Store Commerce for an organization that hasn't invested in change management, you don't get a unified experience — you get a pile of unused functionality.

Conclusion: Understanding the Architecture Isn't Enough — You Need to Know Where It Breaks

Most content explaining Dynamics 365 Commerce restates Microsoft's own presentations in different words. That content can serve as a starting point for those who want to learn the system. But it's not enough for those who want to build, customize, or scale a real operation on top of it.

The real value comes not from knowing what the architecture does, but from knowing under what conditions and how it fails. That knowledge isn't found in documentation — it lives in field experience.

Dynamics 365 Commerce Architecture: The Reality Behind the Polished Slides
Baran Çevik
Assessments on Dynamics 365 Commerce, Digital Commerce and Technology Strategy

Inventory Display and Messaging Strategy

Baran Çevik — Tue, 30 Jun 2026 19:23:04 +0000

Stock Messaging Isn't One-Size-Fits-All: A Category-Based Approach

"Only 3 left in stock!" This kind of urgency messaging is everywhere in e-commerce, and for good reason, it often works. But applying the same low-stock messaging strategy across every product category can quietly cost you sales rather than drive them.

Hiding vs. Moving: It Depends on Your Restock Cycle

When a product goes out of stock, the right display behavior depends on whether new stock is expected and how soon. If a restock is imminent, moving the product to the end of the list is the more effective approach. Customers who are interested in that specific product can still find it, add it to their cart, and receive a notification when it becomes available. This also opens the door for direct customer inquiries, which can be converted into reservations or pre-orders. For example, a trade customer who needs 400 units of a building material can be handled outside the standard online flow, with stock reserved manually and the system updated accordingly when the order is confirmed.

However, if no restock is planned, keeping the product visible at the bottom of the list creates a false expectation. Customers who notice it may wait for it to return instead of purchasing available alternatives, which reduces overall conversion. In this case, hiding the product entirely keeps the listing page focused on what can actually be purchased and redirects browsing traffic toward in-stock items.

Why "Low Stock" Messages Don't Work the Same Way Everywhere

Low stock messages such as "Only a few left" can drive urgency and push customers toward faster purchase decisions, but their effectiveness depends entirely on the product category.

For unique or handmade products, where customers understand that stock is limited by nature, a low stock message creates genuine urgency and encourages immediate purchases. For commodity or construction products, where customers expect consistent supply and often need to purchase in large quantities, the same message can have the opposite effect. A buyer who needs 50 units and sees "Only a few left" is more likely to look for a more reliable supplier than to place a partial order. In these categories, displaying a low stock message risks losing the customer entirely rather than accelerating the sale.

Configure by Category, Not Globally

Configuring inventory range messages to match your product category and customer expectations, rather than applying a single setting across your entire catalog, leads to more effective outcomes for both conversion and customer trust. Platforms like Microsoft Dynamics 365 Commerce support this kind of granular configuration at the product and category level, which means the limitation usually isn't the platform, it's whether the strategy behind the settings has been thought through.

This article is based on real-world experience managing multichannel e-commerce operations across Shopify, Amazon, eBay, and Etsy, and contributing inventory management guidance to Microsoft's Dynamics 365 Commerce documentation.

Channel-Side Calculation

Baran Çevik — Tue, 30 Jun 2026 17:56:13 +0000

The Hidden Inventory Gap: Why Offline Sales Cause Online Overselling

Here's a scenario every multichannel retailer eventually runs into: a customer walks into your physical store, buys the last few units of a product, and minutes later, someone online orders that same item, which your website still shows as available.

Where the Gap Comes From

In retail operations that combine physical and online sales, inventory discrepancies often originate from transactions that occur outside the online channel. A common example is a walk-in or phone-based sale that is processed at the store level but not yet reflected in the central system due to a synchronization delay.

Consider a retailer with 10 units of a product in stock. A walk-in customer purchases 3 units, which are recorded in the local point-of-sale database. Until the next synchronization runs, often on a scheduled interval, the central system still shows 10 units available. During this window, an online customer browsing the e-commerce site also sees 10 units and places an order for 8. The result is an oversell of 1 unit, which leads to a canceled order, a customer refund, and potential damage to marketplace rankings if the sale originated from a platform such as Amazon or eBay.

Closing the Gap with Local Calculation

When channel-side calculation is enabled, the local POS transaction is factored into the inventory count immediately, without waiting for synchronization with the central system. The online channel reads from the local channel database and displays 7 units available. The 8-unit order is blocked before it is placed, preventing the oversell entirely.

In Microsoft Dynamics 365 Commerce, this is exactly what channel-side inventory calculation does: it shifts the source of truth for stock counts from the central headquarters database to the local store-level database, which is always more current.

Why This Matters for Manual and Offline Orders

This approach is particularly valuable for retailers who process manual or offline orders alongside their online channels. When a manual order is created and confirmed, the stock reduction is reflected in the local channel database right away. Online customers see an updated inventory count before the next synchronization runs, which keeps stock levels accurate across all customer touchpoints without requiring real-time service calls to a central system.

If your business processes any sales outside your primary online channel, whether in-store, by phone, or through manual order entry, this synchronization gap is worth checking. It's a small architectural detail that prevents a surprisingly common and entirely avoidable customer experience problem.

Inventory Availability Checks

Baran Çevik — Tue, 30 Jun 2026 16:26:30 +0000

To Block or Not to Block: A Practical Guide to Inventory Availability Checks

Should your e-commerce platform block a purchase when stock runs out, or should it let the sale go through? This sounds like a simple toggle, but the right answer depends entirely on how clean your inventory data actually is.

When Inventory Checks Prevent Overselling

In multichannel retail operations, stock levels can become inconsistent for reasons that go beyond online demand. Walk-in or phone-based sales that are processed outside the system, delayed stock updates, or manual entry errors can all create a gap between what the system shows as available and what is physically in the warehouse. During high-demand periods such as Prime Day, Black Friday, or seasonal promotions, this gap becomes critical. A sudden spike in orders across multiple channels can deplete actual stock long before the system reflects the change, leading to overselling.

The Real Cost of Overselling on Marketplaces

When orders are oversold, the consequences extend beyond the immediate lost margin on canceled transactions. On marketplace platforms, order cancellations and late fulfillments are penalized by ranking algorithms. A seller who cancels orders due to stock issues loses visibility in search results, which directly affects conversion rates on future listings. Recovery from these ranking drops can take weeks.

Enabling inventory availability checks reduces this risk by blocking orders that cannot be fulfilled. However, this approach only works reliably when stock data is accurate and up to date. If stock counts are not synchronized across all channels, including offline sales points, enabling the check can lead to a different problem: customers being blocked from purchasing products that are actually available.

Accurate Stock Data Is the Real Prerequisite

Before enabling inventory availability checks, retailers should ensure that all sales channels, including in-store and phone sales, update the same inventory system in real time. When this synchronization is in place, enabling checks creates a reliable feedback loop: customers only see and purchase what can actually be fulfilled, returns and cancellations decrease, and procurement planning becomes more straightforward because the data reflects genuine demand.

The Bottom Line

When stock data is consistently accurate, enabling inventory availability checks at both the add-to-cart and checkout stages is the more reliable configuration for businesses that prioritize fulfillment accuracy over conversion volume. The setting itself is simple. Getting your data clean enough to trust it is the actual work.

Out-of-Stock Display Strategy

Baran Çevik — Tue, 30 Jun 2026 14:23:10 +0000

Hide or Show? Choosing the Right Out-of-Stock Display Strategy in E-Commerce

One of the most overlooked decisions in e-commerce merchandising is what happens to a product listing the moment it goes out of stock. Should it disappear from the catalog? Should it sink to the bottom of the list? The answer depends on something most retailers don't account for: customer attachment to specific products.

The Loyalty Problem

For retailers selling products with strong brand or model loyalty, hiding out-of-stock items entirely is often the more effective approach. When a best-selling model goes out of stock, customers who are attached to that specific product tend to wait for it to return rather than switching to an alternative. Keeping it visible on the listing page reinforces that attachment and draws attention away from models that are actually available. Removing it from the list redirects that browsing traffic toward in-stock alternatives, which keeps sales moving and prevents the listing page from becoming a source of frustration.

The Cost of Showing Unavailable Products

Displaying out-of-stock products also risks a negative customer experience. Shoppers who click through to a product detail page only to find it unavailable often leave the site without purchasing anything. In contrast, a listing page that shows only available products gives customers a cleaner path to purchase.

A Practical Implementation

A practical approach for this scenario is to hide out-of-stock products by setting them to draft status when stock is depleted, then reactivating them once inventory is replenished. This keeps the listing page focused on what customers can actually buy, while ensuring that high-demand products return to full visibility as soon as stock is available again.

When "Hiding" Isn't the Right Call

For products where customers are more flexible about which variant or model they choose, moving out-of-stock items to the bottom of the list may be sufficient, as it preserves catalog visibility without disrupting the shopping experience. The key differentiator is whether the product is something customers specifically wait for, or something they're willing to substitute.

Platforms like Microsoft Dynamics 365 Commerce offer both options as configurable settings, which means this isn't a one-size-fits-all decision; it's a merchandising strategy that should be set per product category based on how your customers actually shop.

This article is based on real-world experience managing multichannel e-commerce operations across Shopify, Amazon, eBay and Etsy, and contributing inventory management guidance to Microsoft's Dynamics 365 Commerce documentation.

Preventing Overselling in Multichannel D365 Commerce

Baran Çevik — Tue, 30 Jun 2026 14:20:26 +0000

Preventing Overselling in Multichannel D365 Commerce: The Inventory Buffer Strategy

If you sell the same product across multiple channels at once, you've probably faced this problem: a customer completes a purchase for an item that's already sold out elsewhere. This is overselling, and in multichannel retail it's one of the most common and costly operational issues.

The Problem with Real-Time Inventory Sync

Consider a retailer selling the same product across three channels at the same time: a Shopify storefront, Amazon, and eBay. Physical stock stands at 100 units. Because inventory availability APIs update asynchronously, all three channels display "Available" simultaneously, regardless of orders being placed in real time.

Without an inventory buffer, the following situation can occur. Amazon receives an unexpected bulk order for 90 units. At the same moment, 15 orders come in through Shopify and another 15 through eBay. The system processes all of them against the same 100 units of stock, resulting in 120 committed units and 20 oversold items. The retailer is left canceling orders and managing customer complaints after the fact.

How Inventory Buffers Solve This

With an inventory buffer in place, this situation is prevented before it starts. Setting a buffer of 15 units means the system exposes only 85 units as available across all channels. When the 90-unit bulk order arrives on Amazon, the customer cannot complete the purchase because the system does not have enough available quantity to fulfill it. The remaining stock stays protected for other channels.

In Microsoft Dynamics 365 Commerce, this is configured through inventory buffers and inventory level profiles, which together give retailers control over what customers see at each stage:

In stock: 16 or more units remaining after the buffer is applied
Low stock: 1 to 15 units remaining after the buffer is applied
Out of stock: 0 or fewer units remaining after the buffer is applied

Why This Matters

This setup allows the retailer to catch oversell risk at the point of purchase, rather than discovering the problem after orders are already confirmed. For sellers operating on marketplaces like Amazon and eBay, this isn't just an operational nicety. Order cancellations due to overselling are penalized by marketplace ranking algorithms, which means a single oversold item can have consequences that extend well beyond that one transaction.

If you're managing inventory across multiple platforms, treating your "available" stock number as a buffer-adjusted figure rather than your literal physical count is one of the simplest ways to avoid this entirely preventable problem.

This article is based on real-world experience managing multichannel e-commerce operations across Shopify, Amazon, and eBay, and contributing inventory management guidance to Microsoft's Dynamics 365 Commerce documentation.