CRM and ERP Integration: Dynamics 365 Customer Engagement with Business Central and Finance and Operations

What is CRM and ERP integration on the Microsoft stack?

CRM and ERP integration on the Microsoft stack means Dynamics 365 Customer Engagement and a Microsoft ERP, Business Central or Finance and Operations, sharing customers, products, prices, orders, invoices and stock through Dataverse rather than through exports, overnight files and somebody in finance retyping order numbers. Sales sees credit limits and open invoices without asking accounts. Service sees what the customer actually bought. Finance stops discovering at month-end that the CRM and the ERP disagree about who the customer is.

Many companies run CRM and ERP with two suppliers and end up reconciling the two by hand. Solzet scopes the CRM, the ERP and the data flow between them as one design, so customers, orders, invoices and stock mean the same thing in both systems. The integration is usually where a two-supplier setup breaks down, because each side builds to its own half of the specification and the gap in the middle belongs to nobody.

Solzet works on both sides of the Microsoft business stack. We know Dataverse and Dynamics 365 Customer Engagement deeply, and we implement Business Central and Finance and Operations. That means one team designs the CRM, the ERP and the integration between them: Customer Engagement with Business Central through the Dataverse connection and virtual tables, Customer Engagement with Finance and Operations through dual-write and virtual entities, and Power Platform across both. The ERP side is covered on our Business Central and Finance and Operations pages, the CRM side on Dynamics 365 Customer Engagement consulting, and everything else on the services page.

Who is this for, and who is it not for?

This service is for organizations where the customer lives in one system and the money lives in another, and the people in between are tired of being the integration. The common cases are below. In all of them, the integration is a design problem first and a mapping exercise second.

It is the wrong page in three cases. If you only need a handful of ERP fields visible on a CRM form, a virtual table or a small Power Apps screen may be the whole answer, and we will tell you that rather than sell a programme. If your ERP is SAP, Oracle or another non-Microsoft system, the Dataverse routes on this page are the wrong tool: those systems are integrated through their own APIs or middleware, and if you are planning to leave them, we migrate you to Business Central or Finance and Operations. And if the CRM itself is the problem, fix that first with Dynamics 365 Customer Engagement consulting, because integrating a CRM nobody uses only moves the bad data faster.

• Companies on Dynamics 365 Sales or Customer Service that are implementing Business Central or Finance and Operations and want the integration designed with the ERP, not after it.
• Organizations already running both systems with a fragile integration: duplicate customers, orders that never arrive, or a nightly job only one person understands.
• Groups moving off Dynamics NAV, Dynamics GP or Dynamics AX that want to replace old point-to-point interfaces with the Dataverse routes Microsoft supports today.
• Teams building Power Apps, Power Automate flows or Copilot Studio agents that need ERP data such as stock, prices or invoices alongside CRM data.
• Microsoft partners delivering one side who need the other side and the integration built to the same standard, on a white-label basis.

Business Central or Finance and Operations: which integration pattern applies?

The ERP decides the toolkit. Business Central and Finance and Operations both meet Customer Engagement in Dataverse, but through different mechanisms, with different trade-offs between copying data and reading it in place. The table below is the short version; the sections after it go into each side.

In both cases the same rule applies: synchronize the data that the CRM needs to work with offline from the ERP, such as customers and products, and read in place the data that is only ever looked at, such as posted invoices or stock levels. Copying everything both ways is the most common design mistake, and the most expensive to unwind.

How does Dynamics 365 Customer Engagement integrate with Business Central?

Business Central connects to Dataverse through the Set up Dataverse connection assisted setup, with one-way or two-way synchronization, and that connection is the route for integrating with Dynamics 365 Sales. Records such as customers, contacts and items are coupled between the two systems and kept in step, and each table can synchronize in the direction that matches which system owns it. Getting the ownership right per table is the design work; the assisted setup is the easy part.

The Business Central Virtual Table app exposes Business Central data in Dataverse as virtual tables without copying it; the data stays in Business Central. It is built on API v2.0, and custom APIs can be exposed too, so an AL developer can publish exactly the view of the ERP that a sales or service app needs, for example open invoices or stock by location, without duplicating it in Dataverse. That is usually the better answer for data people look at but never change in the CRM.

A typical Solzet design for Business Central and Dynamics 365 Sales: customers and contacts synchronized with a clear owner per field, items and prices flowing from Business Central to Sales, orders created in Sales and fulfilled in Business Central, and invoices, payments and stock read through virtual tables. The AL side, including custom APIs, is covered on Business Central AL development.

How does Dynamics 365 Customer Engagement integrate with Finance and Operations?

Dual-write keeps Dynamics 365 Customer Engagement and Finance and Operations in near-real-time, two-way sync through Dataverse. Microsoft describes it as an out-of-box infrastructure that provides near-real-time, bidirectional integration between customer engagement apps and finance and operations apps. It suits the data both sides genuinely work on: customers, contacts, products and, depending on the process, quotes and orders.

Virtual entities are the other route. Finance and operations apps act as a virtual data source in Dataverse: OData entities are available as virtual tables (virtual entities), and their data does not reside in Dataverse. That makes them the right choice for reference and transactional data the CRM reads but does not own, such as posted invoices, inventory on hand or customer balances, without doubling storage or creating a second copy to keep consistent.

The hard parts are the ones the documentation cannot decide for you: how legal entities in Finance and Operations map to the way your sales and service teams are organized, which system wins when both change a record, how initial synchronization is run for existing data, and what happens to a failed record. Our guide dual-write explained covers dual-write versus virtual entities in depth, and the ERP side is on Finance and Operations implementation.

How does Power Platform work across Customer Engagement and the ERP?

Once Business Central or Finance and Operations data is reachable in Dataverse, Power Platform can use it the same way it uses CRM data. A canvas app for warehouse or field staff can show stock from the ERP next to the customer record from the CRM. A Power Automate flow can start when an order is created in Dynamics 365 Sales and follow it through fulfilment in the ERP. A Power Pages site can be designed to show customers their invoice history from Business Central or Finance and Operations without anyone exporting a PDF.

Copilot Studio agents benefit in the same way: an agent that can see both the open opportunity and the overdue invoice gives a far more useful answer than one that sees only half the customer. The principle is the same as for the integration itself: read ERP data in place where possible, and write back only through the processes the ERP owns, so an app or a flow never becomes a quiet side door into the ledger.

The Power Platform build is described on Power Platform consulting and Copilot Studio. For organizations that want a CRM outside Microsoft licensing, we build custom CRM that connects to Business Central or Finance and Operations through their APIs.

How does Solzet design and deliver a CRM and ERP integration project?

We start with ownership, not mapping. For every shared entity, from customers and contacts to products, prices, orders, invoices, payments and stock, the design names the system that owns it, the fields each side may change, the direction of flow, the route (synchronized or read in place) and what happens when two changes collide. That one table settles most of the arguments that otherwise surface in testing, and it is the document both your CRM and your ERP teams sign.

How long the work takes depends on the number of entities, the volume and quality of existing data, whether either system is still being implemented, and how many custom fields and processes sit on each side. The design phase produces the plan and the estimate with the assumptions written down. Where the CRM or the ERP is being implemented at the same time, the integration is planned into both projects from the first week instead of being scheduled for after go-live.

We recommend the right solution: Dynamics 365 (Customer Engagement, Business Central or Finance and Operations), Power Platform, or a custom-built CRM. One team for CRM, ERP and the integration between them.

• Ownership matrix: one row per entity and field group, naming the owning system, direction, route and conflict rule.
• Mapping and transformation: keys, choice values, units, currencies and number formats agreed across the CRM and the ERP.
• Initial synchronization: existing records matched and deduplicated before coupling, so the integration does not start by creating duplicates.
• Error handling and monitoring: failed records surfaced to a named owner with enough context to fix them, not buried in a log.
• Testing at real volumes: end-to-end scenarios such as quote to order to invoice, run with realistic data, including failure and retry.
• Documentation and handover: the design, the mappings and the runbook for support, kept with the solution in source control.

What if our CRM and ERP integration already exists and keeps breaking?

That is a common starting point. Already live on Business Central or Finance and Operations? Solzet can audit your existing project and give you a stabilisation plan. For an integration the assessment looks at the ownership rules (usually undocumented), the mappings, the error handling, the duplicates already created, the custom code on both sides and the jobs that run outside either system. The output is a prioritised list of findings with an estimate for each, and a target design using the Dataverse routes Microsoft supports.

Old point-to-point interfaces between a CRM and Dynamics NAV, Dynamics GP or Dynamics AX are often the reason a migration stalls, because nobody can say what they do. Our guide to point-to-point integration rationalisation covers how to untangle them, and the broader Dynamics 365 health check and technical audit covers the CRM side in the same pass.