Almost every retailer’s Dynamics 365 integration starts the same way. Customers, products, inventory and orders sync between an eCommerce platform like Adobe Commerce or Shopify and Microsoft Dynamics 365 Finance & Operations on a schedule. Everything looks perfect for a while and seems enough for the businesses.
Once the business starts to expand. More stores open, pickup and delivery options roll out, pricing rules get more sophisticated, and B2B customers want negotiated tiers.
Somewhere in there, the integration that used to feel solid starts straining — not because anything broke, but because it’s being asked to do too many things it was never designed for.
That’s really the core of it: this isn’t a software failure story. It is about a business outgrowing its original integration design, and nothing can be done about it. If your integration hasn’t hit this yet, just because you’re still scoping it or your business hasn’t reached this stage, treat this as a preview: understanding where a standard integration stops being enough will help you design around the problem instead of discovering it after go-live.
A Simple Integration Works, Right Up Until It Doesn’t
Imagine a retailer running Shopify and Adobe Commerce alongside Dynamics 365 Finance & Operations, with a single warehouse fulfilling every online order. Products sync nightly. Orders flow back to the ERP for processing. Inventory updates a few times a day.
At this stage, a standard integration built on OData or Finance & Operations APIs works well because the business itself is straightforward. One fulfilment location, one pricing structure, one predictable order flow. There’s little reason for the architecture to be more complicated than the operation it supports, and if this describes where your business is today, a standard integration is the right starting point, not a mistake to avoid.
The complexity shows up as soon as a second fulfilment location is added, a new POS system, or a real-time pickup option enters the scenario. It now depends on whether it happens six months after your first integration goes live, or it’s already part of the requirements you’ve analyzed. Retailers who’ve not gone through this transition are usually the ones least prepared for it, the original integration simply wasn’t built with any of this in mind. If you’re still scoping yours, you’re in a better spot: you get to see it coming.
What Growth Actually Changes
Opening a second, tenth, or twentieth store doesn’t just add locations. It changes the questions the integration has to answer.
Instead of a single “How many units do we have,” the eCommerce platform now needs real-time answers to questions such as:
- Which store has this item available right now?
- Should this order be fulfilled from a warehouse or a nearby store?
- Can the customer collect it today?
- Does this customer qualify for store-specific pricing or a loyalty discount?
- Will their reward points show up the same way online and in person?
These seem to be simple lookups but are not. Each one depends on inventory reservations, pricing logic, fulfilment rules, and store operations working together in real time, a job fundamentally and entirely different from syncing a product catalog once a night.
Why Adding More API Calls Doesn’t Solve the Problem
When gaps like these appear, the instinct is to patch the existing integration. Add an endpoint for pricing. Bolt on another for promotions. Poll inventory more often. Build a small service to check store availability.
Individually, each fix solves the problem in front of the team. But collectively, they create a situation harder to manage:
| What Teams Try | What Actually Happens |
|---|---|
| More frequent inventory polling | Higher load on Finance & Operations, still-stale data during peak periods |
| Custom pricing endpoints | Pricing logic duplicated and drifting between the storefront and the ERP |
| One-off APIs per retail scenario | A growing web of point-to-point connections that’s expensive to test and maintain |
| Manual promotion syncing | Inconsistent offers between online and in-store checkout |
The real issue is not a shortage of API but it is that Finance & Operations which was built to manage enterprise data and processes, such as procurement, financials and inventory records, not to execute real-time retail logic like store-specific pricing or pickup reservations. Ask it to do both, and eventually you pay for it in cost, complexity, and inconsistency.
Business Impact Shows Up with Customers First
Retailers usually notice these limitations through customer complaints long before anyone can trace them back to the integration architecture.
- Inventory visibility: A customer sees a product listed as available online, heads to the store, and finds it’s already sold. Or the opposite happens: the site shows an item out of stock because inventory updates lag behind actual store activity, so a sale is lost for no real reason.
- Pricing accuracy: Retailers with negotiated pricing, wholesale discounts, or loyalty tiers often end up maintaining the same logic twice. Change a price in Finance & Operations, and the storefront won’t catch up until the next sync; which means disputes, manual corrections, and someone on the phone with an unhappy customer.
- Fulfilment decisions: As order volume grows across warehouses and stores, choosing the right fulfilment location becomes a real-time decision involving inventory, distance, and capacity, not something a nightly batch job can figure out.
- Loyalty and promotions: Customers expect points earned in-store to show up online immediately, and vice versa. When loyalty and promotion rules run in different systems, the consistency breaks down quickly.
None of this is an edge case. These are the minimum expectations of an omnichannel shopper, and they’re becoming harder to meet the longer a business relies solely on scheduled ERP synchronization.
Retail Needs Retail Services, Not Just ERP Data
Here’s the distinction that tends to click for solution architects once they’ve hit this wall: Dynamics 365 Finance & Operations remains the right system of record for products, customers, financial data, and inventory records. That doesn’t change.
What changes is the recognition that customer-facing retail experiences, like real-time store availability, personalized pricing, and BOPIS, depend on business logic that ERP APIs weren’t designed to deliver on their own. These are retail services, not data lookups, and they need to be treated differently in the architecture.
This is exactly the gap that Commerce Scale Unit (CSU) was built to close. CSU is a component of the Dynamics 365 Commerce architecture that extends Dynamics 365 Finance & Operations with retail-specific services such as real-time inventory, pricing, promotions, and POS interactions. It doesn’t replace your existing eCommerce platform or your Finance & Operations integration. It gives both a way to access retail capabilities that would otherwise require significant custom development.
Signals It’s Time to Look Beyond a Standard Integration
Not every retailer needs to change their architecture today. If your business runs a single sales channel, ships from one location, and has straightforward pricing, a standard Finance & Operations integration may still be the right fit.
If you’re reconsidering an existing integration or examining requirements for a new one, a few signals worth looking closer-
- You have opened, or planning to open, a second physical store.
- Customers question (or will ask) if an item is available for pickup, and you can’t answer confidently in real time.
- Pricing rules would need to be duplicated, or already are, between your storefront and your ERP.
- Promotions have to be configured separately for online and in-store.
- Your team is fielding, or expects to field, regular questions about inventory or pricing mismatches.
If two or more of these sound familiar, or you know they’re coming, it’s worth evaluating where Commerce Scale Unit fits into your integration roadmap now, rather than after the workarounds pile up.
Conclusion
A traditional integration between Adobe Commerce/Shopify and Dynamics 365 Finance & Operations isn’t less. It’s simply designed for a specific stage of growth, one where the business operates through a limited number of channels with predictable fulfilment.
When the retail operations expand into multiple stores, real-time pickup, and channel-consistent pricing, the integration has to evolve from simply moving data to enabling retail decisions. Realizing this change early, whether you’re revamping an existing integration or designing your first one, is what separates a scalable omnichannel architecture from one that’s constantly being patched.
