Demystifying CDM, CDS, Power Apps and Dynamics 365

I frequently find myself asking people “Do you mean a model-driven or canvas-based Power App?”  The blank stare that follows leads me into a level setting conversation to get everyone aligned on some common terms before we proceed.  I finally decided to get the gist of this conversation down in a blog post, that if nothing else, will help provide a visual for future conversations.

And hey, I understand this stuff has all been around for years.  But maybe you are just approaching the Power Platform offerings for the first time, or you’re still just calling everything “CRM” and don’t want to ask any questions that might show you haven’t been keeping up.  I’m closer to the latter camp myself and am expecting (and welcoming) some feedback that I have oversimplified one of the following definitions.

Table of Contents

Common Data Model

The Common Data Model, or CDM as it is more commonly called, exists to help align common business concepts into a unified data model.  By itself, it is just a contract for entity and field definitions.  For example, it includes the definition of an Account entity representing a company.  The Account entity includes fields like name, industry, address, etc.  Different systems can implement CDM and provide storage and services to access data that conforms to the CDM definition.

When building business applications, it makes sense to take a look at CDM and see how much your future data model aligns with something defined there.  If there is significant alignment to concepts like Accounts and Contacts, it might make sense to adopt CDM as your baseline data model.  This will allow you to more easily map your data model to other systems you may wish to integrate with down the road.  CDM is extensible, so it allows for custom fields to be added if there is nothing applicable in those defined out of the box.

To see the specification, visit the CDM repository on github:  Once you dig in, you will notice that there are different domains of entities such as Sales, Service, and Marketing as well as other initiatives that provide industry-specific data models like Automotive, Banking and Higher Education.

Microsoft provided Common Data Model poster

Common Data Service

The Common Data Service (CDS) provides a collection of services on top of a CDM implementation.  These services include:

  • Data storage
  • A powerful security model
  • APIs for schema definition, data access, and workflow management
  • Extensible business logic (via .NET code) and data validation rules
  • Data change auditing 
If you think of a traditional web application as having a data layer, a business layer, and a user interface layer, CDS provides the first two of those layers.  If you have worked with Power Automate, Logic Apps, Power BI, or Azure Data Factory you have probably come across a CDS Connector that allows data integration with CDS.

Note: If you are one of those people that have been around for a while and think this sounds pretty familiar – you are right.  CDS was originally just embedded as a part of Dynamics but has been extracted so it can be leveraged by other applications in addition to Dynamics 365.

You might be thinking “a data and business layer is great, but what about the user interface?”  Glad you asked…

Power Apps

Power Apps provides a platform to build no-code/low-code applications for both professional developers and citizen developers.  They come in two flavors: canvas-based or model-driven.  Let’s talk about the things they have in common before we dive into the details of each:

  • No coding required
  • User interface is responsive HTML
  • Can be opened in a native mobile app (shared by all Power Apps installed)


Canvas based Power Apps were created to unlock mobile app development.  As the demand for mobile apps exploded, the staff and budget companies had to implement them were quickly exceeded and the wait time to get new mobile apps developed grew longer.  Canvas based Power Apps help attack this problem by providing a drag and drop experience to layout common UI components and use Excel-like expressions to bind those UI components to different data sets.  Initially, these UI components were limited to what was provided out of the box, but in more recent versions, developers can provide custom controls through the Power Apps Component Framework.

While canvas-based Power Apps don’t provide their own data storage, they can easily connect to a variety of sources to solve that.  It is common to see them use CDS or SharePoint for their back-end data.  That’s right – you don’t need to use canvas-based Power Apps with CDS, but it does provide a great option for a relational data model if you don’t already have something in mind when building a canvas-based app.

Canvas Based Power App
Example of a canvas based Power App


In much the same way that CDS was extracting the data and business logic layers from Dynamics 365, model-driven Power Apps are the extraction of the user interface.  Model-driven Power Apps cannot exist without CDS and have a more defined user interface that revolves around the relational data model they represent to the user.

When setting up a model-driven app, you pick which CDS entities you want to include and then define Views and Forms to display and edit them.  The CDS security model is understood by model-driven Power Apps and will filter the user interface displayed based on the current user’s permissions with very little effort.  The user interface can be customized in certain areas and also supports fully customized controls using the same Power Apps Component Framework that its canvas-based sibling does.  You can even embed canvas-based Power Apps within model-driven Power Apps.

Example of a model driven Power App form

This is usually the point where I see people’s eyes start to glaze over, so let me bring it home quickly…

Dynamics 365

So where does all of this leave D365?  The variations of Dynamics 365 you know today (Sales, Marketing, Field Service, Customer Service, and Talent) are all essentially model-driven Power Apps built on top of CDS.  

This means that if Sales does 90% of what you need, you can start with it and then layer custom entities, logic, and user interface to fill the gaps using the same core platform technologies that you would with a custom Power App.  If you don’t need any of that out of the box functionality, you can start with a custom model-driven Power App and save some licensing costs and have a more streamlined data model.

It is worth noting that there are some features included with D365 off the shelf apps like the new kanban boards that you won’t have access to as a custom Power App.  In this case that is a control that is only included with the Enterprise Sales application.

Bringing it All Together

Now that we’ve gone through all of the pieces of the puzzle, the following image should make sense and help to visualize everything.

All the puzzle pieces snapped together

This was a pretty high level and quick run through of CDM, CDS, Power Apps and D365.  There was a lot to digest and you might be left wondering when to use what.  I’d start by looking at the out of the box D365 applications and then deciding if any of them align well to your requirements.  If so, great – you probably found your starting point.  If not, I’d do some quick prototyping in both model-driven and canvas-based applications.  The fact that they are low code means you can mock things up pretty quickly and get a feel for which is going to be the right fit for your needs long term.

I hope this whirlwind tour helped at least sort out some of the different options using Microsoft’s Power Apps platform.  If you have any questions please feel free to comment below or reach out to us.