“We run Dynamics” is the least informative sentence in ERP integration. Microsoft sells several very different products under the Dynamics 365 banner, and the ecommerce integration story is different for each of them, different APIs, different data models, different risks, different timelines. Most of the generic “Dynamics ecommerce integration” content online ignores this, which is how projects get scoped against the wrong product and priced wrong by a factor of two.
We integrate Dynamics with Shopware and Adobe Commerce for B2B companies, and the first question we ask is never about the storefront. It is: which Dynamics, exactly?
First, identify which Dynamics you actually have
- Dynamics 365 Business Central (the NAV lineage): Microsoft’s mid-market cloud ERP and the most common answer. Good news: it has the cleanest integration story in the family.
- Dynamics 365 Finance and Operations (the AX lineage, now Finance + Supply Chain Management): the enterprise product. Deep capability, formal data management, and integration work that resembles an SAP project more than a mid-market one.
- Dynamics GP: the on-premise veteran. Microsoft has announced the end of the road for it, which changes what kind of integration is worth building at all.
- Dynamics NAV on-premise: the pre-cloud version of Business Central. Integration is possible through older interfaces, but most NAV shops are better served planning the Business Central move alongside the storefront.
- Dynamics 365 Sales / Customer Engagement: not an ERP. If this is what you have, the ecommerce integration conversation is actually a CRM conversation, and your order-of-record question is still open.
Business Central: the clean path
Business Central exposes standard REST APIs with OData, plus custom API pages via AL extensions when the standard surface is not enough. Items, customers, prices, inventory, orders, and invoices are all reachable, and the API behaves like a modern cloud product: predictable authentication, sane limits, good documentation.
Where the effort actually goes on BC projects:
- Customer-specific pricing. BC price lists and customer discount groups map well to B2B storefront pricing, but the resolution logic (which list wins, when) has to be reproduced faithfully, not approximated.
- Dimensions. BC’s dimension model is how finance slices the business. Orders arriving from the storefront must carry the right dimension values or month-end reporting quietly breaks, this is the most common thing we fix in rescues.
- Multi-company. Separate BC companies per legal entity is common; the storefront needs an explicit map of which website sells for which entity.
Finance and Operations: respect the machinery
F&O is a different animal. Integration runs through OData entities and the Data Management Framework (DMF) for batch, often with Dataverse and dual-write in the architecture when CE workloads are present. It is all documented and all workable, but it is enterprise machinery, and the integration has to respect it:
- Batch is a first-class citizen. High-volume flows (catalog, inventory positions, price recalculations) belong in DMF batch jobs on a schedule, not chatty per-record API calls.
- Environment discipline. Dev, test, and production environments with formal promotion. The integration needs the same discipline, hotfixing sync logic straight into production is how outages happen.
- Entity complexity. Released products, trade agreements, and party records are richer and stricter than their mid-market equivalents. Field mapping takes real analysis, not an afternoon.
The queue-and-reconciliation discipline from our ecommerce ERP integration guide applies to both products unchanged: local queue, per-record failure isolation, idempotent order creation, and an ID chain finance can audit.
GP and NAV: build bridges, not monuments
For Dynamics GP the strategic fact outweighs the technical ones: Microsoft has signaled the end of the product’s life. We still integrate against it, eConnect and direct database patterns are well understood, but we design those integrations to be disposable: thin, documented, and built so the storefront survives the inevitable ERP migration intact. The expensive mistake is a deep GP integration built as if the ERP were staying. On-premise NAV gets the same reasoning: if the Business Central move is within your planning horizon, sequence the storefront so it lands once.
Which storefront pairs best with Dynamics?
Both of our platforms work well against every Dynamics ERP; the choice follows your operation rather than the ERP. Adobe Commerce’s B2B module brings the deepest native account/quote machinery for complex B2B catalogs; Shopware brings faster cycles and lower operating weight, which mid-market BC shops in particular tend to value, the pairing keeps total cost of ownership proportionate. Our comparison of Shopware vs Magento for B2B covers the decision in depth, and our platform-by-platform ERP guide puts Dynamics next to its alternatives.
Running Business Central specifically? Our Business Central ecommerce integration guide goes deep on the REST API and OAuth, Microsoft API throttling, and dimensions.
Who we are
Web Solutions NYC builds B2B commerce integrated with the ERPs mid-market manufacturers and distributors actually run, Microsoft Dynamics, NetSuite, SAP, Epicor P21, Acumatica, and Sage, with 50+ implementations since 2008 and a senior-only team in US time zones. We are a Shopware Platinum Partner (the first Shopware agency in the US) and an official Adobe Commerce partner.
Frequently asked questions
Yes, and well, once you know which Dynamics product you are running. Business Central integrates through clean REST/OData APIs; Finance and Operations through OData and its Data Management Framework, often with Dataverse in the middle; legacy GP and NAV through older interfaces that usually justify middleware. The storefront side (Adobe Commerce or Shopware) is rarely the constraint.
Business Central is the mid-market product (the NAV lineage): faster to integrate, cleaner APIs, fewer moving parts, and the right target for most companies under a few hundred million in revenue. Finance and Operations is the enterprise product (the AX lineage): far deeper capability, and an integration that behaves more like an SAP project, formal data management, batch frameworks, and environment management that the integration has to respect.
Microsoft has put GP on a path to end of life, so any integration built against it is a bridge, not a destination. If a storefront is urgent, a thin, disposable integration against GP can make sense, but design it so the storefront survives the ERP migration. What we push back on is a deep, expensive GP integration built as if GP had a future.
Not necessarily. Dataverse and dual-write matter when you run multiple Dynamics products (F&O plus a CE/CRM workload) and want one synchronized data layer. For a single ERP integrated to one storefront, a direct API integration with a proper queue is simpler and easier to operate. Adding Power Platform because it is there is how integrations acquire an extra system to babysit.
Business Central integrations on an existing storefront typically run 6-12 weeks. Finance and Operations projects run longer, 10-20 weeks, because data management, environment promotion, and testing are heavier. Both stretch when customer-specific pricing and multi-entity structures enter scope, which in B2B they usually do.
Running Dynamics and planning a storefront or portal? Tell us which Dynamics product and version you are on, how pricing works, and what your entity structure looks like. We will tell you what the integration actually involves before anyone talks about a build. Let’s talk.