What is the role of Microsoft Dataverse in the age of AI? With so much focus on AI agents these days, is the platform designed for business applications destined to fade away into the background?

My perspective on this is clear: what we today call Dataverse is a foundational concept that has proven its resilience within Microsoft for over two decades already. It is more likely to keep evolving and adapting to the needs of business process management as new scenarios arise - rather than to be replaced with an entirely new “*something* Copilot *something*” platform from MS.

This article first looks at where Dataverse came from. Then, I present five current use cases of Dataverse that differ quite significantly from what the primary commercial message for it from MS was a decade earlier.

The road to here: history of Dataverse

When Microsoft CRM turned 10 years, I wrote down the history of the product to preserve it for future generations of community blog readers. Today, Dataverse is getting close to that age, depending on how you define it.

Microsoft themselves make it tough to see the evolution of their products, due to how they always choose to communicate only about what is the current state of the day. Obviously, they’d rather not draw too much attention to the many changes in brand names and concepts that come and go. Yet customers and partners must understand it.

So, I drew this diagram to both remind myself as well as explain to the Power Platform newbies how Dataverse came to be:

In 2016, when MS "reimagined" what used to be Dynamics CRM and a bunch of different Dynamics ERP products into a unified Dynamics 365 offering, they needed something to glue those products together. Enter Common Data Model, CDM:

"The common data model is a cloud-resident business database, built on years of experience with our enterprise customers. It will come with hundreds of standard business entities spanning both business process (Dynamics 365) and productivity (Office 365). The standardization and consistency of schema enables partners to build innovative applications..."

That was the marketing pitch. When CDM launched, it had a very ERP'ish schema, built largely on concepts from Dynamics AX (now FinOps). Coming from the CRM side, I had a hard time seeing why anyone would adopt this complexity for their own solutions.

A moment later, it was time for the first rebranding. The actual database was now separated into Common Data Service (CDS) and the schema became CDM. Makes sense, since a model alone doesn't do much when it comes to operating business apps.

Now, CDS instead was such a cool concept that Microsoft decided it should mean more than one thing! Enter "Common Data Service for Apps" and "Common Data Service for Analytics". The first of which was the reimagining of XRM as the foundation for business apps, but for the cloud era.

XRM, “any relationship management”, had been around since 2005. When you created custom entities in Dynamics CRM 3.0, you were leveraging a key part of CDS. Using a GUI to generate not just new tables but also app views, forms, business logic, APIs...

What was CDS for Analytics then? For a brief moment, it was the Power BI part of the CDS vision. It appears that not everyone on the data platform side of MS org was fond of the idea, so CDS for Analytics faded away pretty quickly.

Which left just one CDS. As Power Platform became an actual product MS was selling (or at least via Power Apps & Automate licenses), CDS thrived. It made the XRM idea something that customers could actually understand - without having to be Dynamics customers.

In 2020 it was time to think big again, which at MS means rebranding, of course. Unfortunately, the rebranding of CDS to Dataflex was a blunder we've rarely seen. MS failed to secure the trademark and was quickly challenged by another IT vendor that was delivering products named Dataflex.

Microsoft's Dataflex brand was recalled only 21 days after announcement. The Teams based edition of the service went back to using codename Project Oakdale. And Dataflex Pro was reverted to CDS.

Until Dataverse finally arrived later in 2020. The full low-code application platform was now powered by simply Dataverse (no “Pro”). The lite version bundled with MS Teams was Dataverse for Teams. And that's what they've been called now for over 4 years.

What Dataverse is today

When I think about the roles in which Dataverse gets presented today, both in the cloud and AI story of Microsoft as well as community-initiated discussions, it’s rarely about having a common place or model for the business data of an organization. In 2025, these were the top 5 roles that come to my mind when thinking about Dataverse:

1. “Enterprise data platform for Copilot”

In recent years, the Dataverse brand name might not have changed but the marketing pitch sure has. I wrote a rant about this a year ago:

Sure, Dataverse is also “the enterprise data platform for Copilot”. Up until now, though, I’ve found it challenging to get Copilot agents to use Dataverse as enterprise knowledge. My demo chatbots haven’t become a reliable source for answers when pointing them to a structured, relational data store like Dataverse. LLMs seem to prefer different types of data sources and structures than classic SQL - which is the foundation of Dataverse still.

If we’d remove the word “data” from the marketing slogan and instead call it just “the enterprise platform for Copilot”, we’d be closer to the truth. Copilot Studio is a new product despite its Power Virtual Agent origins, and there’s plenty more administration and governance capabilities needed around Copilot agents to make them mature for enterprise scenarios. I’m positive MS will avoid reinventing any wheels that it’s got under the 18-wheeler business data truck of Dataverse already.

Except that just like with Dataverse for Teams, there is another Microsoft platform for agents: SharePoint. This will ensure the usual confusion for both M365 admins and PP admins that try to figure out why one AI agent acts differently than another agent. Because SharePoint agents are just files, whereas Copilot Studio agents are proper solution artifacts stored in Dataverse.

Unlike Dataverse for Teams, SharePoint agents are bound to be discovered by a large share of M365 users. Whether they get adopted into daily use is not the point - there’s still going to be a massive number of them in customer tenants. Will we at some point see an upsell story that will drive these file-based agents to be converted into Power Platform solution artifacts to become properly governable AI agents for the enterprise?

2. Governance toolkit for IT admins

A lot of administration pain has been felt in organizations that wish to build governance practices for Power Platform and are facing an ever growing pile of apps and automations in their tenant’s Default environment. Based on this recent message in M365 admin center, Microsoft is trying to be proactive and direct at least the Copilot Studio agent builder agents into a dedicated environment.

What this means for customers is another special Dataverse environment named “Microsoft 365” appearing in their tenant - with no editing rights for admins. It remains to be seen if it’s just a new variant of the Default environment in the end.

Subscribe to Plus to read the rest.