In this series of blog posts, I’m going through the steps to integrate Dynamics 365 Portals and Dynamics 365 for Customer Insights. The use case is that we want to see which knowledge base articles pages were viewed, and which searches were performed on the portal before a customer submitted a case. In this post, I will provide a brief introduction of the Dynamics 365 for Customer Insights service for those who aren’t already familiar.
Dynamics 365 for Customer Insights (DCI) is an Azure-based service that allows you to report on how customers are interacting with your company. Customers don’t interact directly with DCI; instead they interact with other systems and those interactions are consolidated and available for reporting in DCI.
Since customers don’t interact with DCI directly, we need to pull the data from somewhere. As the name implies, this is where Data Sources come in. There are currently four data sources supported:
In this post, we’ll focus on using Dynamics 365 as our data source.
When you go to add a Dynamics 365 data source into DCI, you’ll first be asked for your Dynamics 365 login credentials, which must have administrative rights to your Dynamics 365 instance. Next, you have the option to select which entities you want to synchronize with DCI. When you select an entity, you also get to choose whether the entity will be synchronized as a profile or as an interaction.
There are three main concepts when it comes to how DCI architects the data: profiles, interactions, and links. (There are also KPIs, but we’re not getting into those here.)
I find the easiest way to think about these concepts is to think about one of the most common types of reports in DCI: the timeline. This is a basic visualization that tells you, for a given record, what has happened over the course of a specific period of time. So, for example, you could look at what interactions a particular contact has had, plotted against time. In this case, the contact is your profile. Reports in DCI are created for a specific profile type, and run on one instance of a profile. So, in this case, Contact is one of the profile types, and when we run our report, we select one specific contact to run the report on. The interactions give us the data points we want to see. Commonly used activity records like phone calls or emails are setup as interactions.
So, when setting up a Dynamics 365 data source, you need to determine which entities you want to include and, if included, whether they are profiles or interactions. Choose profiles if you want to be able to be able to create a report for that entity that shows all of the interactions related to it. Otherwise, choose interaction if that record is something that will give you insight into one of your profile records.
Finally, links determine which interactions apply to which profiles. In database terms, think of profiles as one table, and think of interactions as another table. Without additional setup, these tables are not related; links need to be created to accomplish this. A great example of a link would be joining the Regarding field on an Email record (the interaction) with the Contact ID field on the Contact record (the profile).
In our case, we are interested in seeing what a contact did on the portal right before a case is created. So our profile entity will be Contact. In this situation, we won’t use any of the out-of-the-box interactions, since the Portals interactions are setup a little bit differently.
We followed these steps to setup Customer Insights:
In my next post, I’ll cover turning on the integration between Dynamics 365 Portals and DCI.