XRM without Dynamics (finally!): here comes the Common Data Service

It's been a long time wish from myself and many others with a Dynamics CRM background to get our hands on the core of the XRM Framework, without too much Dynamics weighing down the implementation.

ℹ️
Update (Nov 2020)
Common Data Service has been rebranded to Dataverse. Other than than, it remains pretty much the same in functionality and licensing.

Dynamics CRM (now Dynamics 365 of course) has always been a fantastic toolset to create tailored business solutions even far beyond the scope of the included Sales and Service processes.

Most of the implementations that I've done and still do are CRM without CRM; implementing a business process, leveraging Dynamics CRM as the foundation but, ignoring all that CRM stuff like lead and opportunity management.

Internally Dynamics CRM runs on something Microsoft calls the XRM Framework which is responsible for managing all the entity metadata, security roles, workflows, forms, view, etc. This framework essentially is the beating heart of the Dynamics CRM application.

Wouldn't it be great, if we could leverage this XRM Framework but, only have custom entities? Now, it looks like we can!

Common Data Service v2 (CDS)

Forget about Common Data Service version 1, which was previously launched by Microsoft. This endeavor has been superseded by the Common Data Service v2 and something called the Common Data Service for Apps.

The Common Data Service for Apps is essentially our beloved XRM Framework, stripped and cleaned of all traditional Dynamics CRM processes and rebranded.

We'll be able to create a new clean instance with only a few core entities and leave the sales and service stuff behind us if we don't need them.

Part of the PowerApps adventure

This is all part of Microsoft's bigger PowerApps adventure. With PowerApps we now have a toolset to rapidly create tailored apps in two styles: canvas and model-driven.

Dynamics 365 Customer Engagement apps are essentially model-driven apps, which have been prebuilt by Microsoft and you can purchase. Using PowerApps we can now also build our own. There's Dynamics 365 for Sales but, no (let's say) Dynamics 365 for Car Rental, so if you need it, build it as a model-driven PowerApps on the Common Data Service.

Licensing

The Common Data Service will be included with your PowerApps license, there's no separate SKU. As mentioned in the PowerApps Spring Update, as long as you have a PowerApps license, you'll be able to create a new Common Data Service for Apps instance.

Read the announcement: https://powerapps.microsoft.com/en-us/blog/powerapps-spring-announce/

Dynamics 365 will also continue to leverage the XRM Framework. Essentially, both PowerApps and Dynamics 365 apps will run on the same underlying framework, they are just licensed different.

When you purchase a Dynamics 365 Customer Engagement license you have a Common Data Service instance with all the bells and whistles you've come to expect from Dynamics 365, with a sales and a service process and too many entities to count.

When you purchase a PowerApps license, you'll also have a Common Data Service instance but, this time all the Dynamics 365 specific things will not be there. It'll be a clean instance with only a few core entities and the rest is up to you!

Common Data Service for... Apps?

I've been calling it Common Data Service or CDS for short mostly but, in full it is the Common Data Service for Apps. This is to distinguish it from something else; the Common Data Service for Analytics.

The Common Data Service for Analytics is the service that comes with a Power BI license. When you ingest data from a data source, to model and store in the Power BI service, that's where it goes, into the Common Data Service for Analytics.

The Microsoft marketing department is notoriously good at creating product names that are either very vague or very verbose. Perhaps they should reevaluate this name which, if our journey through the rebranding of Dynamics has show us, will certainly happen at one point.