Connecting Dynamics 365 CRM and Business Central: An Integration Guide
When sales works in a CRM and finance works in an ERP, the same customer, quote and order are usually recorded twice. Integrating Dynamics 365 CRM with Dynamics 365 Business Central removes the rekeying and gives both teams a consistent view. The technology is the easy part. Most of the value comes from the design decisions you make before building anything.
1. Decide the system of record for each entity
For every shared entity, such as customers, contacts, products, price lists, quotes, orders and invoices, name one system that owns it. A common pattern is that CRM owns the customer relationship and sales opportunity, while Business Central owns the financial customer account, pricing rules, orders in fulfilment and invoices. Where both systems edit the same field, you will spend your time resolving conflicts, so avoid it by design.
2. Choose the right integration pattern
Several options sit between a simple standard connection and a fully custom service:
- Microsoft's standard connection between Dynamics 365 Sales and Business Central, which covers common customer and contact synchronisation and is a sensible starting point.
- Business Central APIs (OData and API pages) for reading and writing data in a controlled way.
- Power Automate flows for event-driven scenarios and lighter workflows.
- Custom integration services, for example on Azure, where volume, transformation logic or reliability requirements go beyond what standard tools offer.
Start with the standard option and add custom logic only where the business case justifies it.
3. Design for failure from the start
Integrations fail in ordinary ways: a record is locked, a mandatory field is missing, a service is briefly unavailable. Build in:
- Idempotent operations, so that a retry does not create duplicates.
- Retry rules with sensible back-off.
- An error queue that a business user can read, with clear messages and a way to resubmit.
- Alerting so that failures reach a named person before a customer notices.
4. Secure the connection
Use modern authentication with OAuth and managed identities where possible, grant each integration the minimum permissions it needs and keep secrets out of code and configuration files. Log what each integration did, so that finance and audit can trace a record from one system to the other.
5. Treat the integration as software
Customisations in Business Central are built as extensions in AL, and integration code deserves the same discipline as any other product. Keep it in source control, build and deploy through CI/CD pipelines, test in sandbox environments with realistic data and release with a clear rollback plan. This is also what keeps the integration maintainable through the regular Business Central release waves.
6. Plan the data that goes in first
Before the integration runs for the first time, the two systems need to agree on the starting data: which customers match, which are duplicates and which codes map to which. Run a matching and cleansing exercise first. It overlaps with ERP data migration, and the same validation and reconciliation techniques apply.
Questions to answer before you build
- Which system owns each shared entity and field?
- What is the expected volume and how quickly must changes arrive?
- Who sees and fixes integration errors?
- How will the integration be tested, deployed and monitored?
- Who owns it after go-live?
Need help with a Dynamics 365 or ERP project?
I advise on architecture, implementation, integration and data migration for Dynamics 365 and enterprise platforms. Get in touch at declan@feelyconsultants.com or find me on LinkedIn.