So friends, in this next post as part of my wider series on solution architecture for the Power Platform we’ll take a look at another data topic being the Common Data Model that exists within the platform. We’ll look at what the Common Data Model is, and the considerations we should be making around this during the architecture process.
What is the Common Data Model?
So within the Power Platform we have the low-code data platform we’ve already spoken about within this series called Dataverse. When we create a Dataverse environment we don’t start with a completely blank database with no schema.
When we do this, rather, there is already a pretty large data schema present with tables existing for things like ‘Customers’, ‘Users’, ‘Activities’, and more. This pre-existing data schema that gets deployed for us is known as the Common Data Model and shares a common language for business entities that cover a huge range of processes across, sales, service, marketing, operations, talent and more.
Can we extend it?
So you might be wondering… I now have this database with a pre-existing schema but it doesn’t quite fit the needs of my solution… can I build on it? ? And the answer is yes! The purpose of the Common Data Model is to provide a common template for organisations to put their data into, but to also provide a template they can then shape to fit their needs without completely starting from scratch.
Dynamics 365
So remember those first party solutions we talked about when we were getting to grips with solution design in previous posts in this series? When deploying Dynamics 365 solutions, the data schemas that these rely on effectively slot into the tables and schema that the Common Data Model provides. Dynamics 365 solutions will utilise existing parts of the Common Data Model schema whilst bringing their own tables to add to it.
What’s coming up?
So friends, in my next post, we’ll look at data modelling specifically in more depth keeping the Common Data Model in mind when doing so! Stay tuned 📧