Common Data Model - what is it and how does it relate to your Microsoft 365 Developer Program Environment

?

Are you new or relatively new to 微软 and have noticed that you have two Solutions available to you in your Microsoft 365 Developer Program environment:

?

And are wondering, what's the difference between them? ??

?Wasn't the Common Data Service replaced by ? ??

?

Doesn't that mean that:

• ?Common Data Services Default Solution

and

• Default Solution

are actually the same thing and this is just some holdover legacy thing that Microsoft haven't tidied up yet? ??♀?

?

?Well, there are some truths here, but there's also layers and branches which are important for you to understand from this article, as you start to explore designing your own Solutions.

??Let's start with…

What is a Common Data Model

?The good people at Wikipedia, the Free Encyclopedia define a Common Data Model () as:

Wow! ?? - there's a lot going on here; far too much for this one article.

?Fortunately, the same page goes on to give us examples of Common Data Models, including:

That's more like it.?Let's unpack this a bit. ???♀?

?

微软 's Common Data Model originated from its Microsoft Dynamics 365 CRM Apps.?They're shown as in GitHub with over 260 standard entities split between two sub-folders: applicationCommon and operationsCommon.

?

Within each of these sub-folders are further sub-folders, providing you with a great resource to explore and learn about all the available Common Data Model entity definitions, their attributes, and semantic meanings.?

The span several business concepts and activities, and provide a unified definition of data in different applications and integrators, enabling interoperability through a unified definition of data, which helps make creating enterprise solutions simpler.

Multiple systems and platforms currently implement a Common Data Model.?Internally to 微软 , this includes:

• Microsoft Azure data services
• Power BI dataflows
• Microsoft Dataverse
• and more…

?

Speaking of Dataverse…

?How does the Common Data Model relate to Microsoft Dataverse

?When you provision a Dataverse environment, the core Common Data Model is used to create the tables, columns, and relationships in the Dataverse database. Some of these core tables include Account, Contact, Lead, and Task.

?You can see this if you add a Dataverse data store to any new environment you create under your Microsoft 365 Developer Program and then look at the that are provisioned.?All of these align to the core Common Data Model schema:

As we noted earlier, Microsoft's Common Data Model is influenced by data schemas that are present in Microsoft Dynamics 365 . If you're a customer or a partner using Dynamics 365, you're already using its Common Data Model. ??

?

Again, you'll see this in your Microsoft 365 Developer Program environment if, when you created your Dataverse database, you also selected the option to Enable Dynamics 365 apps.

?This will have given you sample apps and data with which to experiment, such as Microsoft Dynamics 365 Sales and Microsoft Dynamics 365 Customer Services.??The tables that are created for these apps come from the core schema, the CRM base schema, and the Sales and Customer Services schemas respectively.

How does this relate to the Common Data Service (CDS)

?When I did a search for "Common Data Services" on Microsoft Learn , every article I looked at included the following at the top of each page:

So, what's going on here? ??

?In November 2020, the Microsoft Common Data Service was renamed Microsoft Dataverse ,

?This was part of a bigger rebrand by Microsoft at that time, which also saw the formerly named Project Oakdale get rebranded as Microsoft Dataverse for Teams and be made generally available.

?I've included a link in the comments to the Power Apps blog from 微软 's VP Ryan Cunningham from that time, announcing these changes.

?

The core functionality didn't change - Dataverse does the same thing that CDS did; but, some of the terminology in Dataverse was updated to "be more intuitive and make its usage more productive", with these updates being rolled out across Microsoft Power Platform .

? Note:

These?terminology updates aren’t applicable to any APIs or messages in the Dataverse web services.

?

?The other thing you'll notice is that whilst the URL's haven't changed and still reference Common Data Service as with this example from one of the PL-900 modules:

https://learn.microsoft.com/en-us/training/modules/introduction-common-data-service/

?

Solutions-wise we also see a synchronous rebranding to all things :

How does this relate back to Microsoft's Common Data Model Schema

?Which brings us back to , and those questions those of you who are new, or relatively new to Power Apps, may have over why there are two Solutions available in your Microsoft 365 Developer Program Environment:

Out of the box, Power Apps provides you with two default unmanaged?solutions:

? Common Data Service Default Solution - this solution is identified as available for Makers to use by default for their customizations in an environment, and is noted as "useful when you want to evaluate or learn Power Apps".

At the same time, however, Microsoft Learn Documentation also recommend that App Makers work in their own unmanaged solutions, especially if they're planning on deploying their Apps for Flows to other environments.

? ? Default Solution - this is a special solution that contains all components in the system, and is useful for discovering all the components and configurations in your system.

? As a relatively new developer, my Default Solution currently contains 9526 Objects:

Why you need to think carefully before you start to make customizations in either Default Solution

?As we've seen from the above, 微软 recommends as part of its Application Lifecycle Management () guide that you create a solution to manage your customizations.

?Why does it do this? ??

?

Well, the advantages of using your own solution are that:

? By using a custom solution, you can easily find just the solution components you've customized

? You can consistently apply your solution publisher prefix

?and

? You can export you’re your solution for distribution to other environments.

?

?Hang on a minute, I can hear you think ??, why can't I do all this with the default solutions, in particular the Common Data Service Default Solution? ??

?

The ALM guide provides us with a few reasons why you shouldn't create Apps / Flows or make customizations in either of the default solutions:

? When you use either default solution to create components, you'll also use the default publisher assigned to the solution. This often results in the wrong publisher being applied to some components.

? The default solution can't be ; therefore, you can't distribute the default solution to another environment.

? If you aren't consistently using the same solution while you're configuring the environment, you may accidentally leave behind that are necessary to deploy your application to another environment.

?

It also goes on to provide the following explanation of how the default prefix works in the Common Data Service Default Solution:

Which helps to explain why under the Default Solution we see the default publisher prefix of msdyn_xxx for the solution components that are used as part of the Microsoft Dynamics 365 Apps we chose to instal when setting up the Microsoft Dataverse database.

?Whereas each instance of the Common Data Services Default Solution will have a prefix something along the lines of crxxx_xxx.

? Microsoft Power Platform Solutions is a topic in its own right and has a detailed area under the ALM guide:

It's not something we have room to cover here, so I've included a link to the Microsoft Learn Documentation article on Solution concepts in the comments below, which I recommend you read as a minimum.

?I also recommend you read Craig White 's excellent Platforms of Power blog on Power Platform Solutions.?His analogy of solutions being digital rucksacks really resonated for me.

?Does it for you? ??