Integration between Dynamics 365 For Sales and Dynamics 365 For Finance & Operations
- Reference: https://www.velosio.com/blog/2017/09/19/the-common-a-for-sales-and-dynamics-365-for-finance-operations/
- Common data Services for integrating business apps seamlessly.
- Microsoft PowerApps to build mobile apps and extend business processes easily with minimal or no coding needed .
- Microsoft Flow to automate routing, approvals, event based actions and notifications etc.
- Power BI for incredibly stunning data visualizations and data intelligence.
- Microsoft Azure technology stack, such as Azure functions, Artificial intelligence, Machine learning and much more.
Probably, no other business application platform provides this breadth of technology and functionality that Microsoft Dynamics 365 provides today.
In my last post, I explained the Common Data Service and the capabilities, what is coming etc. In this post today, I will share some of my findings of testing of Prospect to Cash integration scenarios between D365 Sales and D365 Finance & Operations.
One of the most common requirements of every ERP implementation is the integration of the Sales and marketing application with the Finance and operations application, to exchange business data such as Customer accounts, contacts, quotations, sales orders, products, invoices and more, so that the respective team members from different teams can get a 360 degree view of the customer’s data. The Microsoft Common data service aims to make it possible to integrate Dynamics 365 For Sales and Dynamics 365 For Finance and Operations out of the box, with various data project templates readily available for use.
Why Common Data Service?
You may argue why use Common Data Service to build integration between the apps/services Vs. just leveraging OData Service or even Customer services (REST/JSON). Sure, you can always leverage either OData Service or the Custom Services to build your integrations between Dynamics 365 for Finance and Operations with other Dynamics 365 or other 3rd party services if you feel more comfortable with that approach. However, leveraging the CDS will give you advantages such as, voiding significant investments in writing custom integration that you need to maintain at a cost. Additionally surfacing business data from multiple business applications of your organization into CDS provides you the capability to create mission critical business intelligence using Power BI or even build custom apps with ease leveraging PowerApps.
Connection Sets in CDS:
Connection Sets defines what apps/services/systems you are going to connect for data exchange.
In PowerApps Admin center, I have already created my Connection Set, that establishes connection between my D365 For Sales and D365 For Finance and Operations apps. I also have done the Organization(s) mapping between these two apps, so that my data will surface in the required entities/organizations. Screenshot below shows the Connection set I have established. This is the first thing you need to setup, before you actually setup the data integration projects.
Data Integration projects in CDS:
The Data integration projects defines what entities are being integrated/synced between the two apps defined in the Connection set. It contains the following information.
- A template of the project (Predefined list of Data integration projects provided by Microsoft). Note: Currently, when you create a new data integration project, you are required to select a predefined template. This might change in future, where you can create your own mapping.
- Connection Set: Select the connection set you want to use within the data integrator project.
- Organization Mapping: Since you could define more than one organization mapping within one connection set, you will can select a organization mapping that is applicable for the data integrator project.
- Tasks: The data from the source app (D365 For Sales ) flows through the Common Data Service(CDS) to the Destination app(D365 For Operations). The tasks under the project contains the individual data field mapping between the entities in source app, CDS and destination app. It also contains the information such as how frequently the project should run (Manually Vs in Batch).
A default task comes automatically when you use a template to create a data integrator project, however, you can add your own tasks to the project, where you can map additional entities.
Now that the Data Integrator Project and the Connection sets are configured, let us see how the Customer account data automatically flows from D365 Sales to CDS and then from CDS to D365 For Operations. In this case, I will just run the project manually ( I could set it to run automatically also)
Below screenshot shows the new customer I have setup in D365 For Sales.
I ran the data integrator project now manually in CDS admin center. In an ideal scenario, you would set it up to run automatically.
When the project run successfully , you can see the detailed execution history which will tell that the data got successfully transmitted from source to destination (D365 Sales to D365 For Operations in this case). See screenshots below. This execution log helps you identify issues with data sync if any and take necessary actions.
Now that the execution happened successfully, let us go verify if the Customer account got successfully created in D365 For Operations.
This was my testing just for one scenario of passing Customer account data from D365 from Sales to Operations for this blog post. There are other templates that addresses the full picture of Prospect to cash scenario(See screenshot below) such as syncing,
- Contacts from Sales to Operations
- Products Operations to Sales”,
- Quotes from Sales to Operations
- Sales orders from Sales to Operations
- Sales Invoice details from Operations to Sales.
No comments:
Post a Comment