Connecting an online store to an ERP system should remove some of the work people do to keep two sets of records aligned. If the connection produces three new reconciliation spreadsheets, it may have automated the transport while leaving the decisions behind.
nopCommerce’s January 2025 overview of its Microsoft Dynamics 365 integration provides a useful starting point.1 It describes connections with Business Central, an ERP application, and Dynamics 365 Sales, a CRM application. Those are distinct parts of the Dynamics family, not interchangeable names for one enormous dashboard.
The practical question is what each system should be trusted to decide.
A customer can exist in the store, the accounts system and the CRM without meaning exactly the same thing in each place. The store may care about login and delivery details. The ERP may care about an approved billing account and payment terms. The CRM may track a prospective relationship before there is an order.
Simply declaring one system “the source of truth” is too broad. We need to identify which record and which part of it we mean.
For a fictional wholesale store, the ERP might own agreed account pricing while nopCommerce manages the customer’s saved delivery addresses. That split could be perfectly reasonable. It needs rules for how the systems exchange the relevant information without overwriting each other’s responsibilities.
Otherwise the integration can become an extremely punctual argument. One side updates a field, the other restores its old value, and both logs report success. The data is moving beautifully. The business is standing still.
As nopCommerce Silver Partners, we’ve put this into practice. See the nopCommerce store we built for Freddy’s Jewelry.
Follow an order beyond the first successful sync
Start with the important decisions: which prices the customer sees, which stock can be promised, when an order becomes accepted and where its final accounting record belongs.
Stock is a particularly useful test. Physical inventory, reserved inventory and stock available to sell are different concepts. A store showing the warehouse’s total quantity may promise goods already committed elsewhere.
The connection needs a shared interpretation rather than merely a shared field name. It also needs an agreed response when fresh information is unavailable. That might mean delaying a commitment, showing a qualified status or routing the order for review.
Then test the unglamorous sequence. An order is submitted, one system accepts it and the response is lost. The next attempt must recognize work already done rather than create another order.
A cancellation introduces another question. Can it still be honored after the warehouse has begun fulfillment? The integration should reflect the actual business boundary, not assume that changing a web status can recall a parcel through sheer conviction.
Worth reading next: The shipping label is a small PDF with a large amount of responsibility.
Reconciliation remains necessary after the connection is running. Compare expected records with actual records and give mismatches an owner. A failed customer sync, missing order or unexpected stock difference should appear somewhere staff can act on it.
That does not require everyone to become a database detective. A clear exception queue with the relevant identifiers, reason and recovery option can make the work manageable.
I’d define success in ordinary operational terms. Staff should enter less information twice, know which system to use for a change and see when an exchange needs attention.
A connector can provide much of the machinery. The business still needs to settle ownership, meaning and recovery. Once those decisions are explicit, the spreadsheet can go back to being a useful tool rather than an unofficial diplomatic service.