10 Common Mistakes When Integrating Adobe Commerce or Shopify with Dynamics 365 Finance & Operations 

Most integration problems between an eCommerce platform and Dynamics 365 Finance & Operations aren’t caused by poor software engineering. They’re caused by decisions that made sense at the time and quietly stopped making sense once the business outgrew them. 

A retailer launching an online store generally needs to sync products, orders, customers, and basic inventory. OData handles that fine. The trouble starts later, once the business adds more stores, BOPIS, a loyalty program, or customer-specific pricing, and the team just keeps stretching the original integration instead of stopping to ask if it’s still the right tool. 

We have listed down ten mistakes we at i95Dev see in majority of the projects, and what to do instead. If you’re building a new integration, treat this as the checklist to get it right the first time. If you already have one running, use it to diagnose what’s worth fixing first. 

Related reading: What Is Commerce Scale Unit (CSU) and Why Do eCommerce Businesses Need It? 

OData is the right starting point for most Dynamics 365 integrations, and for ERP data like products, orders, and customers it stays the right call. The mistake is stretching that same default to things OData was never built for, like retail pricing, promotions, or loyalty. 

Why this matters: 

The reverse mistake shows up once teams get excited about CSU: trying to route core ERP records through it too. Product and category master data, customer records, B2B company and contact hierarchies, customer groups and payment terms, warehouses, exchange rates, posted invoices, credit memos, payment journals – none of that was ever exposed through CSU, and none of it belongs there. Rebuilding access to it on CSU just adds cost for nothing. 

There’s also a third tool worth knowing about: the Data Management Framework (DMF), built specifically for large batch jobs like an initial catalog load or a scheduled bulk price update. It’s not a replacement for OData or CSU, just the right tool when the job is moving a large volume of records at once rather than syncing individual ones or computing something in real time. 

Fix: Use OData or DMF for business data that originates in the ERP – DMF specifically for large batch volumes. Route retail-specific logic (pricing, promotions, loyalty, store inventory) through Commerce Scale Unit. In a typical Finance & Operations to eCommerce connector spanning roughly two dozen functional modules, usually only four or five – inventory, pricing, order capture, and loyalty – are genuine CSU candidates. Everything else stays where it already is. 

Inventory sync is usually one of the first integrations retailers build. It’s also one of the easiest to get wrong. 

A common approach is to poll Finance & Operations every few minutes, or even every few seconds, to pull inventory updates and push them into the eCommerce platform. It sounds like it should improve accuracy. Often it does the opposite. 

Frequent polling can lead to: 

• Unnecessary API traffic 
• Increased processing load on Finance & Operations 
• Longer synchronization queues 
• Delayed updates during peak trading periods 
• Higher infrastructure costs 

Why this matters: 

And the harder problem doesn’t go away either way: not every inventory value sitting in the ERP is something that should be shown to an online shopper. 

ERP Inventory Isn’t the Same as Retail Inventory 

For omnichannel retailers, what’s actually available depends on a handful of business rules: which store or warehouse is fulfilling the order, what’s already reserved, safety stock, channel-specific availability, pickup location, allocations. Expose raw ERP inventory directly, and you’ll show products as available online that can’t actually be fulfilled. 

Fix: Pull inventory through a service built for retail availability – one that accounts for reservations, safety stock, and store-level allocation – instead of just polling harder for a number that was never designed to answer that question. 

Pricing is one of the most complex areas of any retail business, yet many integration projects treat it as a simple data synchronization exercise. 

A common approach is to export price lists from Dynamics 365 Finance & Operations and recreate the pricing logic inside the eCommerce platform. Initially, this may work for businesses with a single price per product. However, as pricing strategies become more sophisticated, maintaining two pricing engines quickly becomes unsustainable. 

Consider the pricing rules many retailers use today: 

• Customer-specific pricing 
• Trade agreements 
• Quantity discounts 
• Catalog-specific pricing 
• Time-based promotions 
• Coupon-based discounts 
• Membership pricing 
• Store-specific pricing 

Why this matters: 

When these rules are duplicated in Shopify or Adobe Commerce, every pricing change must be implemented, tested, and maintained in multiple systems. Over time, inconsistencies become inevitable. 

For example: 

• A customer sees one price online but a different price in-store. 

• Customer service quotes a different price than the website. 

• Promotions overlap unexpectedly because the rules differ between systems. 

• New pricing policies require updates across multiple applications. 

These discrepancies not only create operational overhead but also erode customer trust. 

Fix: Let Dynamics 365 stay the system that calculates prices, and pull those prices through Commerce Scale Unit instead of duplicating the logic somewhere else. 

A lot of integration projects assume inventory is just a number sitting in the ERP. That might be true for traditional B2B operations, retail inventory is far more dynamic. 

Picture a retailer: 

• Running three distribution centers 
• Twenty stores, BOPIS 
• Ship-from-store 
• Endless aisle 
• Regular store transfers. 

 “How much inventory do I have?” stops being the question. 

The real questions are:  

• Which store can actually fulfill this order? 
• Is anything available for pickup at this location? 
• Has it already been reserved by someone else? 
• Should online shoppers see warehouse stock, store stock, or both? 
• Which location fulfills the order at the lowest shipping cost? 

These decisions involve retail business rules that go well beyond ERP inventory quantities. 

Why this matters: 

When an eCommerce platform only syncs warehouse inventory, the cracks show up fast: products marked available that can’t be picked up in-store, inventory shown online that’s already reserved at a physical location, different availability depending on which channel you check, orders routed to a store that can’t actually fill them. Add more stores and this gets harder to patch with custom logic – it needs a different approach entirely. 

Fix: Treat retail inventory as a channel-aware service, not a static ERP figure, and let Commerce Scale Unit apply the rules that determine what’s actually sellable. 

Loyalty is another place retailers tend to overcomplicate things without meaning to. 

Many businesses begin by implementing loyalty apps or custom reward systems within Shopify or Adobe Commerce because they only need to support online purchases. As physical stores grow, they then need to synchronize points, rewards, and customer benefits between the online store and POS. 

Why this matters: 

This creates multiple sources of truth for the same customer. 

Common challenges include: 

• Loyalty points updating online but not in stores. 
• Rewards redeemed in one channel remaining available in another. 
• Different earning rules across online and POS. 
• Customer service teams unable to view a complete loyalty history. 
• Customers receiving inconsistent experiences across channels. 

Maintaining separate loyalty systems quickly becomes difficult as transaction volumes increase. 

Fix: Manage loyalty centrally, and have the eCommerce platform talk to the same loyalty services POS already uses, through Commerce Scale Unit, rather than running a second loyalty system on the side. 

Promotions never stop moving. Marketing runs seasonal campaigns, flash sales, bundles, customer-specific offers, location-based deals – constantly. 

The mistake is maintaining all of that separately in each system: marketing builds promotions in Shopify, store ops configures something else for POS, finance sets discount policy in Dynamics 365, and a custom integration tries to hold it all together in the middle. 

Why this matters: 

It rarely holds together cleanly. A customer sees a promotion online that isn’t honored in-store. A coupon code works on the website but not at checkout in person. Two promotions that shouldn’t combine somehow do, or two that should combine don’t. And every campaign now needs several teams to coordinate changes across multiple systems, which is exactly the kind of process that produces errors under time pressure. 

Fix: Keep promotional rules in one place and expose them consistently everywhere a customer might interact with the brand. Commerce Scale Unit lets Shopify or Adobe Commerce consume the retail promotion engine directly instead of rebuilding discount logic from scratch, which cuts down on maintenance and keeps the offer a customer sees online the same as the one they get in the store. 

“We just need to sync products, inventory, customers, and orders” is a completely reasonable starting requirement, and an ERP-only integration is often the right answer for it at that stage. The mistake isn’t building for today – it’s never revisiting that decision. 

Why this matters: 

 Once stores, BOPIS, or customer-specific pricing show up on the roadmap, the original architecture stops being a foundation and becomes something the team has to work around. 

Fix: You don’t need every capability on day one. You do need an architecture that can add Commerce Scale Unit later without a full redesign. Revisit the integration whenever a major retail capability lands on the roadmap. 

Related reading: 7 Retail Scenarios Where Commerce Scale Unit (CSU) Makes All the Difference 

This is the misconception we run into most often, and it’s a shame, because it talks teams out of evaluating CSU before they’ve even looked at what it does.  

Why this matters: 

The Commerce Scale Unit isn’t a standalone application. It doesn’t replace Dynamics 365 Finance & Operations, and it was never trying to. It’s a piece of the Dynamics 365 Commerce architecture that extends F&O with retail-specific services – nothing more dramatic than that. 

System	Primary Responsibility
Adobe Commerce or Shopify	Customer-facing online storefront
Dynamics 365 Finance & Operations	ERP, finance, supply chain, products, customers, orders
Commerce Scale Unit	Retail services: pricing, promotions, loyalty, store inventory
POS	In-store sales and customer transactions

Fix: Evaluate CSU as something you add to your current architecture, not something you swap in for a piece of it. Your storefront and your ERP stay exactly where they are. 

As requirements pile up, it’s tempting to solve each new one on its own: a custom service for pricing, another for inventory, a separate API for loyalty, custom code for promotions, more integrations for store pickup, yet another service for order status. 

Why this matters: 

Each one solves its immediate problem. Together, they turn into a web nobody fully understands anymore. Business logic gets duplicated across services. Maintenance cost climbs. Every update needs more testing, every new feature takes longer to ship, and eventually a change in one place breaks something three integrations away that nobody thought was connected. This is usually not a plan. It’s what happens when six point solutions get built one at a time over three years and nobody stepped back to look at the whole picture. 

Fix: Route retail capabilities through Commerce Scale Unit as one consistent layer instead of standing up a new point-to-point connection every time a requirement shows up. 

Plenty of integrations run well for the first few months. Products sync fast, orders flow without issue, inventory looks accurate. Then the business grows, and the demands on the integration change in ways the original design never accounted for: more products, more customers, more stores, more warehouses, more regions, higher order volumes, seasonal spikes, more frequent pricing and promotion changes. 

Why this matters: 

An integration built for a single online store tends to buckle under that. The warning signs are usually operational before anyone calls them technical: sync times creeping up, inventory updates lagging, API bottlenecks during peak periods, pricing going sideways during promotions, support teams stepping in manually more often, and new stores taking longer to onboard than they should. 

Rarely is this one bad line of code. It’s usually a sign the original architecture was never built with scale in mind. 

Fix: When you’re planning the integration, think about where the business will be in three to five years, not just where it is now. Can the architecture absorb more stores, more volume, and new fulfillment models without a rebuild? 

Business Requirement	Recommended Approach	Why
Initial catalog load / bulk price updates	DMF	Built for large batch volume with staging and error handling
Product and customer master data	OData	ERP remains the system of record
B2B hierarchies, payment terms, warehouses, exchange rates	OData / DMF	Not exposed through CSU; no functional gain from moving them
Posted invoices, credit memos, payment journals	OData / DMF	Financial documents belong in the ERP’s own reporting surface
Sales order synchronization	OData	Orders need to be processed and accounted for in Finance & Operations
Financial transactions	OData	Finance owns accounting and reporting
Customer-specific pricing	Commerce Scale Unit	Uses Microsoft’s retail pricing engine directly
Promotions and loyalty	Commerce Scale Unit	Keeps rules consistent across every channel; loyalty has no general OData surface
Store inventory availability	Commerce Scale Unit	Applies retail rules instead of raw ERP quantities
BOPIS and ship-from-store	Commerce Scale Unit	Built for real-time omnichannel fulfillment

Not every integration needs to be rebuilt. However, there are certain warning signs that indicate your current architecture may no longer support your business goals. 

If you recognize several of the following challenges, it may be time to review how your eCommerce platform integrates with Dynamics 365 Finance & Operations and whether Commerce Scale Unit should play a larger role. 

Operational Warning Signs 

• Inventory shown online doesn’t always match what’s available in stores. 
• Customer-specific prices differ between the website and POS. 
• Promotions must be configured separately in multiple systems. 
• Loyalty points are inconsistent across online and in-store purchases. 
• New stores require significant integration work before they can go live. 
• Seasonal promotions or flash sales impact integration performance. 
• Customer service teams frequently investigate pricing or inventory discrepancies. 
• Introducing new omnichannel capabilities requires extensive custom development. 

Technical Warning Signs 

• OData is being used for almost every integration scenario. 
• Custom pricing or promotion logic has grown significantly within Shopify or Adobe Commerce. 
• Inventory synchronization relies on aggressive polling intervals. 
• Multiple point-to-point integrations have been created over time. 
• Every Microsoft update requires extensive regression testing. 
• Integration maintenance consumes increasing development effort. 

None of these issues necessarily mean your implementation is flawed. In many cases, they simply reflect the natural evolution of a retail business. An architecture that supported one online storefront may not be the right architecture for a retailer operating dozens of stores with sophisticated omnichannel requirements. 

The important step is recognizing when your integration has reached that inflection point and adapting it before technical debt begins slowing the business down. 

Nearly all of these trace back to one habit: treating every integration requirement as a data sync problem, long after the business actually needed real-time retail logic instead. Dynamics 365 Finance & Operations, Commerce Scale Unit, and your eCommerce platform each do one job well. The integrations that age well are the ones that respect that division of labor instead of routing everything through whatever tool happened to be set up first.

This article is part of i95Dev’s content series on integrating Adobe Commerce and Shopify with Dynamics 365 Finance & Operations for omnichannel retail. 

• Commerce Scale Unit (CSU): The Complete Guide 
• Why Traditional eCommerce and Dynamics 365 Integrations Break Down in Omnichannel Retail 
• What Is Commerce Scale Unit (CSU) and Why Do eCommerce Businesses Need It? 
• OData vs Commerce Scale Unit (CSU): Choosing the Right Integration Approach 
• 7 Retail Scenarios Where Commerce Scale Unit (CSU) Makes All the Difference 

If your integration is showing a few of these warning signs, i95Dev works with retailers on Adobe Commerce, Shopify, and Dynamics 365 to design integration architectures that scale with the business instead of around it.