The first new component of the upcoming Dynamics 365 platform that has reached a stage of public preview is the Microsoft Common Data Model (CDM). Available via PowerApps, CDM can be provisioned in your Office 365 tenant with only a few clicks, so there’s little reason for not having a look an early look at it. In fact, you only need to sit back and relax while watching CRM MVP Scott Durow walk you through a first look at the Common Data Model:
So, there you have it! That’s what CDM looks like when accessed via the PowerApps web management UI. Any questions?
Yeah, I actually do have a couple.
How will this work with CRM and AX?
What we have available in the preview is pretty much the most straightforward part of the very big puzzle to put together, meaning a database on Azure with some preconfigured tables and data model management tools. We do not yet know much about how the Dynamics CRM and Dynamics AX functionality will be linked to CDM as part of the Dynamics 365 cloud platform, so there’s plenty room for speculation, which honestly is mostly what I’m about to do here. In a way I’m just continuing on the theme of my previous post about Dynamics 365 and its potential implications for XRM, to pass the time as we wait for Microsoft’s plans to be revealed in more detail.
Right now the only way to push data into CDM is a Flow. If you’ve ever played with automation tools like IFTTT or Zapier, then you’ll quickly grasp the idea of Microsoft Flow. The application itself shouldn’t be underestimated just because of its current simplistic demo scenarios that usually are along the lines of “when a new row is added to a SharePoint list, send an email to this address”. Built on top of Azure Logic Apps, there’s actually a next generation BizTalk type of cloud integration platform under the hood, which should provide plenty of future potential for advanced messaging solutions to orchestrate business processes across a number of different systems.
Once Dynamics 365 Enterprise arrives and gives us the features of CRM and AX in one seamless cloud environment, there’s naturally going to be a need for something a lot more than a “build your own” type of Flow integration. Keeping the Sales and Operations apps of D365 in sync with the customer and transaction data managed in the process of making an delivering a sale involves a fair amount of business logic. If you’ve ever designed and developed a custom integration for this type of a scenario, you’ll know the requirements can quickly grow a bit hairy. Assuming Microsoft can come along and say “we’ll take care of that hairy part, don’t you worry about it” then who could resist it?
The reason CDM exists is that there will be more than one physical database in the Dynamics 365 suite. It’s not all XRM, which means you can’t find the Operations app entities inside your CRM solution files. For the business processes to work seamlessly, someone needs to keep those database closely in sync with one another. From reading through the Common Data Model tutorials, we can see that at least as of now, Flow is not the system that can handle it:
“Today, when you use Microsoft Flow to import data or export data, it is not a full synchronization service. Whenever an object is added to one service, it will be imported into the other system. However, that means if an object is deleted from one system it will not be deleted in the other system.”
So, the sync part is still in the “To Be Implemented” bucket. So is security, since the passing of a record from CRM to CDM via Flow will not carry over any details about who should have the rights to do some CRUD work on it. Again, it may not sound like such a mission impossible to build. However, if you’ve ever faced the requirement in a Dynamics CRM project to implement SharePoint document library integration with account records that includes not just linking the folders but also enforcing the account access rights on the documents, you’ll know the struggle is real. Sure, a collaboration solution like SharePoint has very different security concepts than a system designed for structured business records management like CRM or ERP. But if Microsoft hasn’t been able to offer OoB synchronization of access rights across Dynamics CRM and SharePoint despite of the clear business demand for it, maybe we’d be foolish to expect that it will all be seamless inside the Dynamics 365 world either.
The thing here is that unless the solution provided by Microsoft is going to be fairly advanced, it might not be an actual solution. It’s like the old saying from the dawn of the internet:
Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.
When confronted with the need to integrate processes across two different cloud business applications, there’s always the danger of someone rushing into thinking “I know, I’ll build a database in the middle to unify the process data”. So we end up with three cloud business applications… Now, I’m not saying that Microsoft wouldn’t have the type of application architecture masterminds working on the Dynamics 365 platform that can solve these complex problems when developing a new product. I’m just afraid that things may still turn out a bit more complex in reality than the marketing pitch for the new product launch might lead people to believe.
What limitations will this impose on customization?
When designing a Dynamics CRM solution for a customer organization it’s pretty rare that there wouldn’t already be a number of other applications in place that also deal with the same customer information on at least some level. ERP is a good generic example of such a system to use when demonstrating the potential pitfalls in planning your integration strategy and why it can have such a big impact on the success of your CRM initiative. From my personal experience over the years, some of the worst Dynamics CRM systems I’ve seen (from the perspective of business value delivered to the end users) have been either:
- Not integrated at all with any operational business information systems
- Way too integrated with an ERP to leave any space for actual customer relationship management
Obviously if the CRM system is completely detached from the physical processes that deliver products/services to the customer or the financial transactions that deliver revenue to the company, it will become an island of its own that needs to be manually updated for every single business activity. In such cases it usually won’t take long before the system is no longer actively updated, which sharply decreases its potential value for managing business processes, which in turn makes it a future desert island.
The other extreme isn’t necessarily a pretty sight either. If the implementation of a new CRM system starts by replicating the exact customer data model of the ERP system and copying over tons of transactional data, this can severely limit the possibilities of delivering new functionality for the business in the areas where it is needed: understanding the customer relationships rather than the ship to/bill to addresses, managing the customer interactions instead of orders/invoices, and so on. Enforce enough external rules and limitations onto a new system and you’ll get a poor cousin of the original system.
It’s this latter option that somehow came to my mind when taking a first look at the contents of the Common Data Model. There’s a 87 page CDM Entity Reference document available for download, which takes you down to the very details of what entities and fields are provisioned into the CDM database by default. Now, having spent a bit over a decade working with the default data model of Dynamics CRM (oh dear lord, what have I done with my life?!?), I expected to see something that I could quickly map to the CRM database in my mind. Perhaps even a kind of V2 of the CRM data model that would address some of the challenges often encountered when attempting to represent the non-hierarchical real world with the relationships, parties and activities of Dynamics CRM.
Well, that’s not exactly what I saw in CDM. It looked all very ERP’ish, with the focus being on things like this supplier invoice ERD, as an example:
Fair enough, we are of course looking at a solution here that aims to bridge the gap between CRM and ERP, so this approach makes a lot of sense from a practical perspective. Still, I find it a little bit troubling that when I look at the contents of CDM, it feels like I’m being taken inside the database of AX. I can also imagine myself being in the role of an ISV coming from outside the Dynamics ecosystem and investigating the logic of how these applications work, so that I could plan how to integrate my own software with these Microsoft applications. Remember: this may well be how the future partners developing the new applications for Microsoft AppSource would approach Dynamics 365.
It’s still a preview of the real CDM to come, of course. It’s also a database that’s been designed to accommodate custom entities and fields, just like XRM is. Nevertheless, I wish I would see something there already at this point which I’d be excited about getting to use in future projects. Instead of a unifying “person” entity to represent the human beings that should be at the heart of any CRM, I just see a number of different entities for spreading the same person into many different database tables: “alumnus”, “employee”, “constituent”, “fan”, “contact”, “tenant”, “contractor”, “volunteer”, “donor”. Ok, great, so I can store the name, address and Twitter handle of a physical person into 11 different entities now. I don’t recall ever wishing for such a possibility to exist, but it’s what’s coming at us now when Dynamics 365 arrives.
What’s the big deal then? Why could’t we just roll our own data model like we’ve done with XRM since forever? Well, of course you could, but the question really is what will the customers want? The reality is that the stack off applications that organizations are deploying to support their information workers and enable fully automated business processes is growing taller every day. What this tends to mean is that there’s less resources available for designing and developing unique solutions to business problems – at least when they are not seen as a clear source of competitive advantage. The trend is moving towards settling for the standard application functionality with no custom code whenever possible, in part to reduce the risk of getting burned when new releases of the product are being rolled out that may not support the unique extensions you might have developed. This will most likely also be a direction we’ll see in the Dynamics 365 market, too.
I don’t predict that we will lose any technical capabilities for designing business app data models with the arrival of CDM. We’ll probably gain much better connectivity between apps from different vendors, but I also believe that some compromises will be needed in order to balance the benefits of platform extensibility and app compatibility. Digital transformation surely won’t make the business requirements more static in the future, but it will certainly make it more critical to plan ahead on how the underlying systems can support the ongoing transformation without causing the wrong type of disruption to the flow of information. Microsoft also recognizes this in the CDM Entity Reference document:
“Schema compatibility between CDM versions 0.1 and 1.0 is not guaranteed. The Common Data Model (version 1.0) will provide versioning as entities change over time. Multiple versions of an entity will be supported at the same time, however, entity versions may be deprecated and removed over time with adequate notice and upgrade guidance.”
Exactly. The only thing guaranteed over time is change. Let’s see if CDM will help us get along with it.
Well, I have never use CRM, and what so ever server from Microsoft, buy I am the initial insider tester for PowerApps.
I started with Excel from cloud and in august, start using CDM, too, with mixture of concept between Excel and CDM.
Apart from stability of the entities connection with PowerApps which Microsoft needs further enhancement, CDM has been tested and used by few of us, with wonderful integration with our existing apps, migrating from excel storage.
I can foresee, that is the future of cloud first Mobile first era with our apps are mostly built for Mobile phone and storage speed is almost instant.
Can’t really understand your long message but your inputs are great for reading.
Thanks for your comment, hpkeong! In a way this is definitely one of the core reasons why CDM is needed: to bridge the gap between all the different cloud apps and make them easier to approach for a much wider audience than just the domain experts of systems like CRM or ERP. I’m hoping that CDM will also give us a quicker way to get products like PowerApps connected with Dynamics CRM, with enough support for the various data types and relationships that form the core of our data models.
Thanks for clarification. Appreciate the paradigm shift of Microsoft CEO. Just wonder, will CDM be free of charge forever or will have special package? This will make us worry of future storage issue. Moreover, nothing was mentioned about the limitation of storage…!
As initial tester/user, I had started commercialise my Apps, using CDM (and Get & Transform features of Excel 2017), customers are “wow” of the efficiency, performance, as well a the most important parts…COST impact. Almost no extra investment because my App is basically Mobile based and all existing user can fully utilise their Smartphone to accomplish data entry (for lower level staff) and instant data analysis (for top management), without having opening PC/Tablet. Moreover, with PowerBI on the way to integrate with PowerApps, that will be another “wow” for productivity apps. (PowerBI can now be used externally to PowerApps, using exported Excel file, but have to do it manually).
Hope my feedback and your professional comments can draw the attention of Microsoft to further upgrade their cloud services and performances.
Really interesting, to be honest every attempt Microsoft have made to easily integrate between dynamics or other Microsoft products in my mind has failed. Easy being the key word. If we consider the out of the box “processes” and automations. Pretty much all can be recreated as you say without a single line of code. As such my recent strategies have been not to use any of the sales pipeline features or product modeling for example as you end up spending time fighting that damn automation (although there have been improvements in that regard) and for cheaper licensing reasons ? With this in mind I have recently been thinking of a business platform that would come out of the box with just a few core entities e.g. Company and person. If you had the cool stuff from crm including all the “configuration capabilities” you could build pretty much anything off that platform. Cloud based and scale able of course, Bundle the solutions, call them apps if you like and there is a single platform that you can use for all your business systems, in a single database (if you want) and with crm security model you can control access. Allow companies to build the apps and merely sell the platform. Allow partners, consultants and third parties to develop their own business solutions on top of the platform and voila! You can have a proper open market place for developing processes and tools that can be freely available and searchable. You can import and modify solutions/apps as you wish, and if you need code well then you can revert to scripts and plugins as per usual and when needed. Develop the API so when customers need to integrate their own systems they can freely. That would be a pretty powerful platform but would totally change how Microsoft would sell the thing. Can this new crm become something like that? Do Microsoft even want it to be? I smell an opportunity ?
Great comment, Daniel! Essentially it all boils down to the platform vs. app debate that has been going on around Dynamics CRM/XRM ever since 3.0 and custom entity support. Looking at the recent announcements on Dynamics 365, it looks to me like the direction is now more towards offering apps built by Microsoft as the primary story around what Dynamics (formerly CRM) is about. I wouldn’t be surprised if we’ll see some other, simplified application platform launched with less on-prem and CRM app legacy and more of Azure supported agility for the “citizen developers”/power users out there.
For an excellent post on some of the practical challenges that integrating CRM and ERP via the Common Data Model may present to Dynamics customers, go and read the article “Dynamics 365 and the hopes for the Common Data Model” by CRM MVP Gustaf Westerlund: http://gustafwesterlund.blogspot.com/2016/10/dynamics-365-and-hopes-for-common-data.html
Thanks Jukka … please suggest if there is an On-Prem version of CDM is available or if there is a roadmap for this?
Thanks for your time.
Amir, CDS (Common Data Service) is built for Azure and it’s cloud only. I don’t expect to ever see it in on-prem.