Integrating Dynamics 365 Business Central and Customer Engagement (CRM): Choosing the Best Approach for You

Dynamics 365 / CRM

Powered by LUCK™

You are using Business Central as your master system of records for managing customers, inventory, orders, invoices, and regular ERP duties. You’re also taking advantage of the Microsoft Dynamics 365 stack by incorporating Sales, Customer Service, Marketing, or maybe Field Service or Project Operations modules and/or leveraging the Power Platform by providing a web portal for your business partners or customers. 

Whatever, chances are you want to streamline lead-to-order or customer service processes and avoid the pain of maintaining misaligned duplicate records between systems (i.e., the same customer, multiple times with different data). 

Regardless of being part of the same Dynamics 365 family, fair is to say that D365 Customer Engagement (‘CRM’) and Business Central use different databases to store their data, and out of the box, they’re not synced, not to mention you can’t directly ‘touch’ any of those databases in a cloud environment. 

That’s why if you need to integrate both systems, you may weigh up the different technology approaches that may satisfy your requirements. 

In this article, I’m going to introduce you to three of the most common options available and compare them. 

What to Consider First 

Gathering the requirements for your integration is essential for your assessment and choosing the right technology for the right task. When it comes to BC-CRM integration projects, you’d rather take into consideration these key aspects: 

  • Do you have a multi-environment setup (i.e. Dev-QA-Prod) you plan to configure and test or deploy the integration? 
  • With multiple companies, which need to be synchronized, too?  
  • If yes, do all those companies share the same default local currency? Or not? I.e. you’ve got a US company set up in USD and a Canadian one in CAD.
  • What would be a tolerable time window between each sync? That might depend on the type of records, but it’s relevant to differentiate what must happen in real-time (if any), close to real-time vs every x hours or days. 
  • How customized each system are? I.e. do you have custom tables/entities and fields which you anticipate will need to be present in both systems? 
  • What about security constraints of records once they are copied from BC to CE? How should they be assigned ownership? 

There are other variables for sure, and each project is different, but the above is a good start for your due diligence exercise. 

Let’s move now to see some of the options that we have for a no-code/low-code integration: 

3 Options for Integrating D365 Business Central and CRM

1. Out-Of-The-Box (‘OOB’) Integration 

This might be your first choice to ponder as it’s already ‘there’, ready to go, and does not add extra costs to the project. Microsoft has been investing in evolving this solution and it’s a decent approach as far as your BC and CE implementations are pretty much OOB as well. 

There are a set of Dataverse tables that are created when you import a solution in CE which act as intermediaries between it and BC and synchronization occurs through jobs in BC which run every 30 mins. 

The architecture looks something like this: 

Figure 1 – Dynamics 365 CE and Business Central OOB Integration Architecture 

In the latter, you will be able to visually configure the mappings between both systems, as well as some elemental transformations. 

There are a limited number of entities and fields which are available to configure, and anything beyond that (i.e., any custom field you already have or custom entity/table) requires coding. 

In addition, keep in mind in case you need to synchronize companies with different local currencies in BC with the same CRM instance, that’s not possible at this moment. 

Regarding security, you can configure your records to be assigned to a team (to which you can manually add users later) or to the salesperson associated in BC (assuming that person will be a user in CE too). 

There’s a sister OOB solution as well if you want to display BC data in CE which uses Virtual Tables, but has several limitations inherent to this technology and it’s in preview yet. 

Figure 2 – Business Central Virtual Table 

2. Azure Logic Apps 

If you’re looking at something more flexible that you can fully govern the triggers when to run (i.e., at the very moment a new customer or order record is created in any of the systems) and wholly control the flow of data and conditions, Azure Logic Apps might be a good approach for the overall integration project or some parts. 

It follows a similar pattern as Power Automate (if that sounds more familiar to you), and has OOB connectors for both Dynamics 365 CE and BC with the advantage that´s a much more robust technology for integration projects. 

The architecture looks something like this: 

Figure 3 – Using Azure Logic Apps to integrate Dynamics 365 CE and Business Central 

As a drawback, it of course will require you much more effort, starting from scratch or near from scratch, modeling your integration processes (usually one per entity and/or business action -i.e. approving an order), and you’ll need to pay for an Azure subscription to logic apps, either standard or by consumption. 

In addition, if your project involves moving a high volume of records (i.e., several hundreds or thousands of records), using technologies like SSIS/ADF may be a better approach, while keeping logic apps for some real-time use cases, if needed. 

3. KingswaySoft Connector 

KingswaySoft (KWS) is a proven third-party connector that works on top of Microsoft SQL Server Integration Services, either on-premises or in the cloud through Azure Data Factory (ADF), which is designed to handle high volumes of data. 

You model your integration flows (called ‘packages’, usually one per entity or business process), and you schedule them to run periodically as needed. 

The architecture for a cloud-based deployment looks something like this: 

KWS has been around for many years already, thus one of the main advantages of this approach is that’s a proven technology and will make it easier for you some common tasks like upserting records, mapping optionsets, filtering data, and performing complex transformations, as it leverages the entire SSIS infrastructure. 

You may need to ponder the associated costs though, as you will require a KWS commercial license when going live as well as paying for an Azure subscription for ADF services with SSIS runtime in case deploying to the cloud. 

Comparison

ProsCons
OOB Integration✓ Native, OOB solution 
✓ Easier to configure  
✓Configurable conflict resolutions 
✓ No additional licensing cost 
✕ Cannot synchronize companies with BC local currency != CE base currency 
✕ Requires lots of AL code extensions to add the fields and tables we need 
✕ Deployment requires reconfiguring each environment 
✕ Dataverse storage could be an issue 
✕ Limited. May need to complement with logic apps 
Virtual Tables ✓ Native, OOB solution 
✓ Easy to configure  
✓ Data is not replicated, but leaves in each system 
✕ It’s still in Preview, not supported. 
✕ Does not support multiple companies 
✕ Useful only for BC–>CE so users can see records from BC in CE 
✕ Virtual tables are not supported in Power Pages.  
✕ Virtual table limitations (security, users must exist in BC, limited to 250 records per query, no rollup fields, relationships, etc.) 
Logic Apps✓ Low code approach (‘Power Automate’ like)  
✓ Full control and flexibility to model simple to complex integration logic 
✓ OOB connector for CE and BC  
✓Robust. Leverages the Azure infrastructure, DevOps 
✓ Saves Dataverse capacity. No need of intermediary tables 
✓ Consumes exposed webservices (BC API-type pages) 
✓ Supports real-time integration (if needed for some particular scenario) 
✓ Cost-effective per consumption model 
✕ Requires modeling each integration process (logic app) from scratch 
✕ OOB BC connector is very limited, which will require setting up a new custom connector (low code), and/or using Odata connector 
✕ API-type BC pages will be required (applies to any approach other than 1-OOB) 
✕ Might face some challenges when processing the first full sync (due to API throttling limits) 
KWS Connector✓ Low code approach (SSIS)  
✓ Full control and flexibility to model simple to complex integration logic 
✓ Enterprise-ready, industry-proven robust connectors 
✓ Built-in productivity tools (i.e., optionset mappings, upserts) 
✓ Saves Dataverse capacity. No need of intermediary tables 
✓ Consumes exposed webservices (BC API-type pages) 
✓ Prepared to scale and process massive amounts of records 
✕ Monthly costs for ADF with SSIS runtime, regardless of consumption 
✕ License annual cost for third-party connector 
✕ Requires modeling each integration process (dataflows) from scratch 
✕ API-type BC pages will be required (applies to any approach other than 1-OOB) 

The above options are a good start, though when it comes to integrations, there’s no ‘one size fits all’ solution. Therefore, you might regard a combination of the above and/or exploring other alternatives, such as using Power Platform Data Flows, Azure Data Factory, or Synapse pipelines. However, consider that none of them have a native connector for BC and you should deal with the generic OData connection at the moment of this writing. 

You might also ponder other third-party connectors, or even some custom coding in case you need a deeply customized solution. 

New technologies may emerge regularly in this dynamic space, so you’d better want to remain open and ask for expert advice. 

Get Help By Partnering With C5 Insight 

Want to know the best approach to meet your needs? At C5 Insight, we’ve got proven experience integrating Dynamics 365 CE with Business Central and would be happy to help you achieve your goals! 

Contact C5 Insight today. 

Resources
Interested in how we can improve your customer and employee engagement?
Contact us for a free assessment ►

Powered by LUCK™

Search Posts

Categories

Recent Posts