Goodbye Common Data Service, Hello Dataverse
Earlier this month Microsoft announced that Common Data Service, the sophisticated and secure backbone that powers D365 and Power Platform, would become Microsoft Dataverse. Bringing terminology mappings and basic concepts in-line with existing systems, this fresh name is just one part of a broader initiative to introduce the true potential of what Dataverse to organisations around the world.
In addition to driving the adoption of Dataverse across first-party D365 applications, another key part of the strategy is Microsoft Dataverse for Teams, the realisation of Project Oakdale, a project focused on the delivery of a built-in low code data platform for Microsoft Teams.
But before we dive into the differences between Dataverse for Teams and Dataverse, let's look at the terminology changes that will take effect as part of the rebrand;
Dataverse will see the alignment of naming conventions with standard terminology used across the Microsoft ecosystem.
|Legacy Term||Current Term|
|Entity / Entities||Table / Tables|
|Field / Fields, Attribute / Attributes||Column / Columns|
|Record / Records||Row / Rows|
|Option set / Multi-select Option Sets,Picklist / Picklists||Choice / Choices|
Despite a change in name and terminology Dataverse continues to act as the central repository for business data across the entire suite of D365 applications. This enables you to focus on building apps directly against this core data without the need for custom integration. Some key components available out of the box include;
A central store for data held within your D365 business applications, Dataverse allows effortless data integration from multiple sources. This single data store can then be used to turn business data into insight and action through the use of Power Apps, Power Automate, Power BI and Power Virtual Agents, all without the need for complex coding.
Designed to maximise security without increasing complexity, the Dataverse has security built-in at the platform level, meaning that once you define security roles and field-level security profiles fora particular user or team, these will apply to the authenticated user no matter what application or service they are accessing Dataverse from.
The Dataverse features a series of configurable logic engines that are used to build applications. Advanced logic can be implemented to further support out of the box calculated and roll up columns or classic workflows, with a full-featured SDK or custom plug-ins written in .NET
Dataverse for Teams
As part of their Microsoft Teams' licence, users can now harness the potential of their business data without leaving the Teams platform thanks to Dataverse for Teams. A "lite" version of Dataverse, Microsoft Dataverse for Teams is designed to enable users to build relatively simple Power Apps apps, Power Automate lows and Power Virtual Agent bots without the need to leave MS Teams.
The biggest difference between Dataverse and Dataverse for Teams lies in the functionality available, for example;
Dataverse has non-relational storage (logs) and Dataverse for Teams does not
Dataverse features API access and plugins that Dataverse for Teams does not
With Database for Teams, access is restricted to just the Team owners, members and guests, whereas with Dataverse you have additional security features such as hierarchical and field-level security. sharing,