Let’s continue our discussion on extending the Health Accelerator through the Common Data Model. This is part two of our series and part two of extending the Data Model. If you missed the first part of this series please find the link here. At this point you should have an instance of Office 365, a Trial of Dynamics 365 for Customer Engagement and have installed the accelerator from AppSource. If you have not please follow the instructions in this link here.

Extending the Accelerator’s Common Data Model

In this blog we are going to be focused on how to extend the Common Data Model for the Health Accelerator leveraging Power Apps. There are a few points that I would like to make before we get started, basically to level set folks understanding of how our platform is currently enabled.

At its simplest you should consider CDS 2.0 for Apps, the Common Data Model 2.0 for Apps and the Data Layer for Apps as the foundation of all the services and UI’s that the product has to offer. In the past if folks were using Dynamics CRM you would be thinking in terms of XRM. XRM was the previously platform and API stack for Dynamics CRM or as we call it now Dynamics 365 for Customer Engagement. The services for Customer Engagement and the Data Layers were tightly coupled together. That is no longer the case. In addition, Power Apps and CDS 1.0 for Apps and the CDM 1.0 for Apps was also separate from Customer Engagement. This is also no longer true.

Today, if you are a customer who is leveraging Power Apps and CDS 2.0 for Apps, the Common Data Model 2.0 for Apps and Customer Engagement it is now the same thing. There are little nuances here and there but it’s still semantically the same. In our previous example we are leveraging Customer Engagement and now we are going to continue that but via the Power Apps UI.

A Quick Review of Rebranding and Interrop between Power Apps and Customer Engagement

As just explained we are going to use the Power Apps UI to perform our model enhancements. Once again, I want to give a small follow up to that statement.

When you leverage Power Apps, or our newly branded Power Suite of tools, you are effectively leveraging components that sit on top of CDS 2.0 and the Common Data Model 2.0 for Apps. Power Apps itself as a UI creation tool has become our standard branding for all UI work. When you log into your Customer Engagement instance, you are doing two things. First you are leveraging the Dynamics 365 Container that is rendering inside of your browser. Second you are rendering the application solution layer that you have told the container to render. In our case we are telling it to render Customer Engagement. That initial set of screens is effectively the legacy UI for Customer Engagement or as many know it “CRM”. This is now all branded as a Power Apps set of Applications or solutions.

This is what it looks like

In this case you can see the legacy UI Menu or “Site Map” and all the applications that are installed, including the Dynamics Health 365 application (or solution). As I mentioned however this is really Customer Engagement Legacy rendering inside of the Dynamics 365 container for the browser. In the previous blog post we created a new solution which had components that showed up under Settings in this legacy UI. While it was a legacy application (or solution) you should have noticed that the actual Solution Explorer was branded as Power Apps.

Within the Dynamics 365 Container you can also see the following by clicking on the arrow next to the words Dynamics 365. Please note that the apps you installed effects what you see.

What has happened is that the Dynamics 365 container now allows you to both select Legacy Customer Engagement applications and our New Power Apps Model Driven UCI (Unified Client Interface) applications. So now you can easily swap between different types of applications across the Dynamics 365 stack as long as they are enabled and designed to render within the Dynamics 365 container. Each of these applications, whether they are legacy model driven apps or UCI apps they are branded as Power Apps.

Question: So how does this really enable the interrop you are speaking about?

Answer: The data store that is being used by Customer Engagement, whether model driven legacy or UCI is a CDS 2.0 data store. That same data store exists in a shared Power Apps environment. When you go to Power Apps you can select the Environment in the drop down (if you have access), that is directly tied to the Customer Engagement Instance.

Question: Isn’t this the same as using a CDS data store and connecting to a Customer Engagement Instance?

Answer: No. When you have a shared data store the power apps and model driven apps you build directly in Customer Engagement and the Power Apps UI are 100% available to both platforms because of CDS 2.0 and the shared data layer. In the old days that is different than using the connector to either pull data into a Power App database instance that you create or creating Apps that point directly to Customer Engagement (which you can still do)

Let’s Start Extending using Canvas based Power Apps

Make sure you have opened a new tab and go to powerapps.com. If its your first time, click the Sign In button at the top right. If you already have Customer Engagement and an Office Tenant logged into tabs on the same browser instance, you should just get logged in directly. At the top right click the down arrow in the Environments list. Select the Environment that matches up with your Customer Engagement Instance. We will talk more about how instances appear and how you can create other environments later. It should look like this.

I have multiple environments. Some that are CDS 2.0 only, meaning I only needed the data model, not a Customer Engagement instance, and some are actual shared Power Apps / Customer Engagement instance / environments. In my picture I have merely deleted some of the others to show you that I am picking my Customer Engagement Environment.

Next to demonstrate how these are shared, I will not setup any connectors. I will merely click on Data to open that sub-menu on the left and then click Entities. After I do that you should see something like this.

These are entities that exist inside of the Customer Engagement Instance. You can also see the Option Sets that exist in the data store as well. You merely have to click on Option Sets.

Before we start extending there is one specific thing that is important to understand.

• When creating Entities in the Canvas based mode (please see the bottom left corner or the UI, its where you select the mode), you cannot select the Solution that the entity will reside in. Therefore, it will go into the default base system solution. To see it you would have to select Settings \ Customizations, versus Settings \ Solutions, and then double clicking your solution.

• There are also a few features such as Charts which are not available as part of the entity definition, as they are with Model Driven Applications.

Create a New Entity for your Canvas based Application

Let’s create a new entity and review how it is configured.

• Click on Entities and then + New Entity near the top left corner. Once you do this you should see this

• Notice that everything else greys out. Also notice that there are 4 starting fields. This process acts like a wizard

  • Give it a Display Name and Plural Name if one is not auto-generated or you do not like what was generated. This is just like when you create entities in the Model Drive Customer Engagement UI

  • Look at the Name. It should be auto-populated. You will also notice that the prefix is not something you can change. The prefix was auto generated for this environment and does not match the prefix of a solution that you can see in Dynamics Customer Engagement. This is purely so that you can import, and export entities created in this environment and be able to know what environment created them for tracking purposes.

• Click Next You will now be given the opportunities to create new fields, relationships, keys, views and Business Rules. Again, this is a bit less than if you created the entity in model driven mode. Because the expectations on how you use them is different. This represents that base functionality that will work in both Canvas and Model Driven environments across Dynamics 365.

Adding New Fields to Your New Entity

Initially you can see that there are no fields except for the Primary Field. In this case you didn’t get asked what you wanted the Primary Field to be. It is a Text Field named Primary Name. We are going to add a couple of fields to this entity to help extend the model further.

Adding fields is just like adding fields in the model driven world.

• Click Add Field and you will be asked for the following

• Display Name

• Name

• Data Type

Just like our previous exercise, give it a display name, which will default the name for you. Then select the data type. Some types will have other abilities, like Whole Numbers will let you select the min and max values. Here is what it looks like while I add the Description field.

Once I click done it will show up like the below. I also added a Date field, so you see them both. We now have a new entity with two fields.

Now we can see the full list of fields that we have added to our Illness History entity. Now we need to add a relationship between Illness History and some entity in our Model to extend it further

Adding Relationships between Entities

We want to enable the scenario where a single Patient (contact) can be assigned multiple illness history instances. To create this relationship, follow these instructions

• Click the + Add relationship

• Select Many to 1 and you will see the following

• For Primary entity select Contact

  • Note: This is the opposite of what you would see in the model driven UI in Customer Engagement. In that UI you would be selecting the Primary entity, not the Related entity. We are currently working with the team on this discrepancy

• Click Done

• Click Save Entity

• You can see the new relationship. In this case in the top right I selected the Custom view to make it easier to see

• Now let’s look and figure out how this all fits together

Show Me the Interrop

I talked about the fact that this based on CDS 2.0 has provided a great interrop between what you do in the Power Apps Canvas UI and what you do in the Customer Engagement Model Drive UI. Let’s look and verify. In our previous example we created a new Patient Travel History entity from within our sample Customer Engagement Application model driven ui. If we go back into our Power Apps UI and select our Customer Engagement Environment (remember environment and instance are the same), and if you select Data, then Entities. In the Search box, to the top right, type Patient. You should see the following

Extending Entities Created in Customer Engagement from Power Apps UI

Now that we demonstrated that you can see the entity from the Power Apps Canvas UI

• Click the entity link to open it up

• Add a new field, just like we have done above. In my case I added a new Whole Number that represents the Days Travelled. After typing in the information, click Save Entity. You may receive an error that the entity already exists. It does not mean your field(s) we not saved, merely that the entity already existed in the database. I received this error myself. After creating the entity, you should see this

• Now that you have added this field go back into the Customer Engagement instance. Go back into your sample applications, so in my case MGHI Patient Care. Looking at the entity Patient Travel History I now see the following

• You can see the Days Travelled field. Consider that the Name and Schema Name are based on the prefix cr76a_ and not based on mhgi_. This is because each environment & publisher has unique prefixes. This is on purpose. In Power Apps for that specific “environment” it generates the prefix for you, versus you creating a “Publisher” with a prefix. This way you can easily track every extension that occurs from each environment.

Viewing entity Illness History in Customer Engagement UI

Previously I created a new entity in the Power Apps Canvas UI, called Illness History. We also created a new relationship between Illness History and Contact.

• Go back into the Customer Engagement UI

• Important Note: In Power Apps Canvas UI, when you create a new entity backed by a CDS 2.0 environment with an attached Customer Engagement instance, you are not able to select which solution the entity should be associated to. Because of this, the entities will be associated to the base solution. For this reason, you must go directly to this solution

• Select Settings \ Customizations (versus Solutions)

• Expand Entities

• Click on Illness History

• Click Fields

• You can see that the entity is listed there and that the fields we created are also there

• Now click on N:1 relationships. You will see the relationship that we created that enabled you to associate many illness history instances to a single Patient (Contact)

You can now see how entities that you create in the Power Apps UI, as well as their relationships, can show up in the Power Apps Model Drive UI of Customer Engagement. Applications build on either platform can leverage these entities and relationships.

Summary

In this blog post we reviewed how the Common Data Service 2.0 provides a straight forward integration strategy between extending Customer Engagement applications directly from Power Apps Canvas and Model Driven applications, while at the same time extending Power Apps Entities in Customer Engagement. The ability to cross interrop between the two technologies enables us both high code, low code and no code opportunities across the Business Application Platform.

Coming Up Next

In our next blog post I will start building new Power Apps Canvas based applications which interact with our CDS 2.0 environment. Because of this any data used by this new application or created by this application can be used by Customer Engagement.

Links for Review

• Announcement of the Dynamics 365 Health Accelerator

• Basic Configuration for the Dynamics 365 Health Accelerator

• Common Data Service for Apps

• Common Data Model

• Building Model Driven Applications

• Building Canvas based Applications

• Developer Guide for Dynamics 365 for Customer Engagement

• GIT for the Microsoft CDM (Common Data Model)