Dynamics 365 Customer Engagement Integration -Way to go!
Businesses are at the helm of maturing their customer centricity initiatives by adopting CRM applications within their existing IT landscape. In order to achieve robust customeroriented processes, we also see businesses transition from their incumbent CRM applications to a different CRM application. Microsoft Dynamics 365 Customer Engagement platform (D365) is no doubt a front runner in the recent times with businesses adopting it via a fresh implementation approach or a migration approach. Every organization moving to D365 CRM comes with a different stack of existing applications, presenting a unique integration. Here are a few best practices one can adopt to ensure a smooth D365 CRM Integration. When Dynamics 365 CRM Implementation replaces an incumbent CRM application Typically, we face scenarios where we need to replace an existing CRM to implement Dynamics 365 Customer Engagement. Our task is to migrate the organization from their current system to Dynamics CE smoothly. Besides the migration and core development activities, there is a separate node for integration in the project plan. Note that this integration can be with multiple different kinds of Applications/ Services/ DBs. In general, there would already be a set of Web Services/ APIs available which were working well with the older CRM. Below are the different integration approaches:
1. Writing Custom Dot Net Application: These are executable commands scheduled to run through Windows scheduler on a server. Developers will write code to consume external APIs. Consumed data is then Inserted/ Updated into D365 CE using OOB services. This will take a separate article to get into details, which we will take up soon. 2. WCF/ Web API wrappers: For exposing CRM data, a WCF/ Web API wrapper layer can be written, which acts as a façade layer and exposes CRM data to external applications. These can be hosted on a separate server or through Azure Web Apps. Security mechanisms are implemented to meet specific organizational needs. 3. Third Party Tools: Third party tools like Kingswaysoft, Scribe come up with either perpetual or yearly licenses and can provide a smooth and configurable integration approach. 4. Azure-based Integrations: Under the Azure framework, there are multiple methodologies available to integrate external applications with CRM. a. Using Azure Functions: Azure Functions are a preferred tool which can be scheduled and called through CRM plugin too. b. Using Logic Apps: Logic Apps (LA) is another way of integration- it offers a connector to D365 CRM and other products and provides integration with low code- node way.
Note that Azure works on pay-as-you-use model and LA connectors are asynchronous. More on this in subsequent articles. 1. Power Apps Data Integrator- Power Apps DI provides another way of integration which can be Synchronous and Asynchronous both. The new Dual Write feature allows direct sync of data from Plugin to external Applications. 2. Connectors- There are products with a readily available connector to D365 CRM. Adobe Experience Manager has Dynamics CRM easy to configure connector which fetches data from Dynamics 365 CRM directly. Many ERP solutions in the market come with a built-in connector for Dynamics CRM.
When It’s a fresh Dynamics 365 Customer Engagement Implementation (maybe a Greenfield implementation) This scenario rarely comes in a typical Dynamics 365 Customer Engagement Implementation. With no legacy applications in the picture, it looks like a blank whiteboard to draw the entire solution landscape. The trick here is to plan the Integration architecture while considering other applications, their usage, their business objects and their data models. Note that Dynamics 365 CRM product road map needs to be aligned with the Client’s IT roadmap somewhere.
Here the integration methodology remains the same as explained above but just a few points to be kept in mind 1. Avoid Custom Solutions Approach: Do not use (or avoid using as much as you can) the custom approach of Integrations which include writing Dot net exe or façade API layer and hosting the same on another server. These come up with maintenance issues of the code apart from the extra cost of the server. 2. Rely on Proprietary Microsoft Tools: Take Azure-based or Power Platform based Integration approaches. Azure provides detailed Dev Ops, and even techno-functional resources can be trained to work by creating Logic Apps. Power Apps Data Integrator is again easy to manage Integration approach, which is ever evolving. Note that any suggestion related to Azure-based platform should be provided with minimum next five years of Azure costing in running those Integration items.
When You are creating additional Integration Point in your existing Dynamics 365 Implementation Practically, this comes with a scope of optimization and revamp of the already running integration touchpoints. Though the general practice is to create these additional touchpoints using already running methodology. It is up to you how you can convince the client on how his additional spending on revamping and redeploying already running items helps the entire Integration landscape by making it more robust and agile. This needs to be presented as aligned with future IT road map as well. Presenting the data on Integration support issues over the past years and how the revamping exercise will considerably reduce their numbers can also be helpful. Conclusion With newer technologies and platform coming into the picture, it is a general question of “which platform/ to be considered”. This needs to be answered considering the set of parameters discussed above. As far as our experience goes, CRM implementation fails when Solution Designing misses the woods for the trees!