Let’s Talk: What is the Common Data Service?

Over the last year, you may have heard more than one mention of the “CDS” or the Common Data Service and wondered what was so special about it. What is this mythical beast and why is everyone fawning over it? In this blog I’ll go over the key areas of are some of the backbone of the Power Platform.

At the core of every platform and system is data. How that data is modelled, stored, accessed and utilized is key to all successful business applications. It is vital that applications can speak to each other in the same language, that there is some logic there to ensure proper communication and that a layer of security is implemented to ensure the data is accessed accordingly.

When the Power Platform was built, these key necessities were top of mind and with the introduction of the Common Data Service, or “CDS”, business applications have taken that next step into the future.

The CDS can be thought of, at it’s most basic level, as a relational database. It allows us to store, organise, access and manage data across the four building blocks of the Power Platform. It would be easy to think of the Common Data Service as “just” a relational database, but it actually consists of three major components: Entities, Logic and Security.

Entities

Each time a new environment is created, a new instance of CDS is generated along with a pre-defined set of Entities (tables) and Fields (columns). This standard data schema is called the Common Data Model or “CDM” and the Entities generated within the initial instance of CDS are called the Core Entities. These Core Entities are commonly used record types across business applications that Dynamics users are familiar with such as Contacts and Accounts. The CDM can be thought of as the base language of the platform and allows applications to easily communicate with each other. An Account in Power BI is the same thing as an Account in Power Apps. If I’m using Power Automate to take data from one CDS environment to update another, the CDM makes this a breeze as both data sources are speaking the same language.

As we install and create additional solutions and apps, we build on top of this data model, growing the CDS. As you can see from the diagram below, installing the Sales app gives us access to additional Entities such as Opportunities and Orders. Additionally, we can create custom Entities within the CDS, adding to the existing data model.

Logic

The CDS is not just a relational database with a pre-defined data set. It also comes with some built in logic that will be familiar to Dynamics users such as Business Rules. These allow data to be validated in real time in line with certain requirements. They also can serve as guidance to an end user by displaying messages advising them on what needs to be done before saving a record. Other logic such as Real Time Workflows and Actions also come as part of the CDS logic package.

When I think of logic, I almost always think of another key component of the Power Platform – Power Automate. Power Automate allows us to automate multiple different types of processes across the entire Power Platform and beyond using connectors. Because Power Automate is built on top of CDS, we can use it to communicate between other parts of the Power Platform. As an example, Power Virtual Agents can call a Power Automate Flow to retrieve a specific record from the CDS based on a user’s input. Power Automate can then be used to update a record in CDS which appears in a Power App. Power Automate can be thought of as the glue that connects the Power Platform together.

Security

As long time Dynamics users, most of us will be comfortable with the idea of Security Roles and Business Units. The Common Data Service follows this security model and means that out of the box, security is easily configured and configurable for us.

Records in the CDS have an ownership associated with them. A record can be owned by an individual (A User), a group of users (A Team) or by the system (An Organisation). The security role model below outlines how individuals assigned to this role can interact with records belonging to a specific Entity:

Each circle displays the level of access the user has to that record type. Can they view all records regardless of who owns them? Can they only edit records they own? Do they have any ability to delete records? These little circled determine what a user can and cannot do, and to what level they can action these privileges on.

Conclusion

Now that we have looked at the three major components of the CDS, it’s easy to see why building on such a robust foundation is so attractive. Our foundation is laid for us, data models are generated, security roles are pre-defined and we can use logic framework to validate input and guide users. It is a base that appeals to app makes on all levels and gives us a head start by setting us up for success. Now you’ve uncovered the secrets of what CDS really is – what will you build first?