Dynamic Communities Magazine

This article provides key steps to help work through terminology miscommunication as the foundation for exploring the Microsoft Power Platform and CDM and their roles in today’s Microsoft Dynamics 365 for Customer Engagement projects.

Originally published in H1 2019 CRMUG Magazine

There is a great old sitcom, “Diff’rent Strokes”, where the catchphrase “What’chu talkin’ ‘bout, Willis?” became popular. In the Microsoft Dynamics community, many of us are asking that question. Working as a Microsoft Dynamics consultant for the past seven years has exposed me to a variety of problems to solve: from Microsoft Dynamics 365 for Finance & Operations to Customer Engagement integrations using Common Data Model (CDM) or not using CDM to replacing SOAP services with function apps or logic apps and everything in between with PowerApps replacing separate line of business applications.

No matter the specifics in the scope of work, the root issue was, “how do we make business decisions using data that is located outside of our business platform?” I have determined this is more often a communication issue than it is a technical problem. This does not fall on Microsoft but on the implementers and admins. In any project the vocabulary gets thrown around with terms like API, integration, cloud, web services, and RESTful all being used interchangeably. To technologists these terms are not describing the same thing. In my mind we have begun solving problems with descriptions of the solution rather than discovery of the needs.

This article will take this context as the foundation for exploring the Microsoft Power Platform and CDM and their roles in today’s Microsoft Dynamics 365 for Customer Engagement projects. I will provide some key steps to work through this miscommunication. But first, let’s get some clarity.

What’s in a Name?
The naming game over the past years has really caused some confusion for admins and Users in the Microsoft Dynamics community from 4.0 to CRM Online, to Microsoft Dynamics 365 for Customer Engagement, Talent, Retail, Sales, Field Service, Project Automation, etc. One Microsoft MVP, Jukka Niiranen, has a great blog, survivingcrm.com, and covers this platform advantage in great detail in the post “Top 3 Themes for Dynamics 365 in 2018”. If you want to learn more details about the platform, please review the post at https://survivingcrm.com/2018/12/top-3-themes-fordynamics-365-in-2018/.
For clarity, the current environment vocabulary is as follows:

POWER PLATFORM

•  CDM = Common Data Model for Apps
  (aka Common Data Service/Model, CDM, or XRM) Part of Power Platform providing “Data
  Integrator” tool.
• P2C = Dynamics 365 Prospect to Cash solution
  Provides synchronization of data for accounts, contacts, products, quotes, orders, and invoices.
  However, I am not going to debate any of this or discuss how cool this has become. There are
  plenty of great reviews out there of these tools. We are talking about PRACTICAL application of
  the CDM in a business environment and the reasonable application of the supporting parts of the
  platform that would be useful.

Problem Statements
Here is a list of common statements I hear on projects.

1. Data exists in other systems outside of my business process application.
   1. We need this data available to our Users in a “just-in-time” format.
   2. We don’t want to pay for storage of data in multiple places and keep them in sync.
2. The business application solution is slow, especially when making large queries to custom services.
3. We need to keep our on-premises data secure while opening access to our online business applications.
4. Business needs change too frequently.
   1. Customer needs change too frequently.
   2. IT and internal app support cannot maintain true lifecycle management or traditional project delivery with this rapid changing environment.
      1. Believe it or not, this one comes from IT and tech professionals directly.

Step One – Know the Difference
If you are reviewing and evaluating the need for a common data model, then we are basically talking about exchanging information. Data is exchanged in three ways:

1. Integration – to form, coordinate, or blend into a functioning or unifi ed whole
   1. Synchronize – to happen at the same time, to indicate coexistence
   2. Interface – to provide the capability of intersystem communications
   
   I have heard these terms used interchangeably. They are not the same thing. Get down to the
   true need for the business. Does the User only need to access information to decide then modify
   data in the host system, do they need to only read data, but no updates, or does the data need to
   be owned in both locations?
   We need to know the difference between these types of data exchanges in order to determine
   how to solve the need.

Step Two - CDM or Not to CDM

Each environment in CDM is based on common entities. There are great UI tools for managing
the data model. Environments can share one CDM, or each environment can have its own CDM.

A Model Driven PowerApp is a small core CRM instance provisioned within your tenant. This
includes the core entities, business rules, process workfl ows, actions, security roles, and same
16 D365UG/CRMUG MAGAZINE

SDK as any full DCE instance. Therefore, you could say this creates “xRM lite” as a data Model
Driven PowerApp. The database behind that instance is the CDM for that environment. Open
Advanced Options and see the same solution explorer window you would see from within DCE.
Also, this instance is listed among other instances of Microsoft Dynamics 365 for Customer
Engagement.

WHERE I FIND THE CDM HELPFUL:

1. Multiple systems
2. Variable business needs
   1. Each line of a business has strong demands on the data independent of each other
3. Integration on-premises currently uses staging tables
   1. Think of CDM as staging table for data
4. Access is limited in host system
5. Business admins are citizen developers

WHERE DO I FIND THE CDM NOT HELPFUL:

1. Just trying to exchange between Microsoft Dynamics 365 for Customer Engagement and
   Microsoft Dynamics 365 for Finance & Operations
   1. The data integrator tool handles this without a staging table.
2. Lines of business agree with data structure and end purpose of data elements
3.  Data storage not an issue
4. Existing data policy in an organization can be too rigid to adopt CDM
5. Organization lacks strong internal change management
   1. Management of CDM is going to be a new process and requires effort within an organization to design and implement this new process.

Step Three – There’s an App for That
After determining the need for each exchange, then determining the role of a centralized standard data model, you are ready to determine if PowerApps plays a part in this new design. The need should be answered by building smaller applications which accomplish specifi c business tasks. You can use PowerApps if you have this kind of need. This is only reasonable for small and middle size organizations now that we have the Power Platform.

APP DELIVERY MODEL:

1. Create Model Driven PowerApp.
   1. Develop apps which are common for the business.
   2. App lifecycle management is possible in this instance.
2. Each department can pick up these apps from a central location.
   1. They are solution zip fi les, after all.
3. Synchronize core data elements from their source systems using Azure Function Apps, or Logic Apps, or just Flow. These are listed from most complex to least complex.
   1. Use CDM like a service bus; each department can use Flow to subscribe to the data
      entities that matter.
   2. Why not use service bus?
      1. Easier to teach admins to manage fl ow than to support custom code managing the
         black hole which service bus customizations become.
4. Share apps across departments as each department develops their own solutions.
5. Rinse and repeat.