Support Portal ContactGet in touch

Common Data Service – when is CRM not CRM?

   Words by Paul McQuillan

   on 20/04/2020 17:00:00

Dynamics 365 as Microsoft’s CRM Platform has always had a flexible Database Structure, allowing us to add new Fields, Entities and Forms through a simple user interface.

This is crucial to CRM as every business has its own requirements for how it tracks common Sales, Service and Marketing concepts – particularly as different businesses have different Sales Stages and Processes.

But we can and do use CRM to track whole new concepts outside of the big three CRM Modules.

This was once branded xRM for Anything Relationship Management, and was often used to allow us to use the great low-code functionality in Dynamics to architect and build a range of line of business systems for different clients.

I’ve used Dynamics since 2005 to implement a raft of systems across business sectors, and a good deal of these were very XRM in tackling industry scenarios outside of Sales, Service or Marketing; and am sure many Dynamics Consultants would say the same.

However this did give a problem in how people think of CRM, as its really not just CRM.

To combat this problem, Microsoft examined at how we can build new systems in the Cloud using the Toolset around CRM and restructured how we think of these tools.

This produced the Common Data Service.

Common Data Service

The Common Data Service is the foundation layer of Dynamics CRM in providing a flexible Database that we can extend to track the data and concepts we want, using the same no-code interface as Dynamics.

Tracking data in this common format then allows us to use other Tools in the Microsoft Cloud to put that data to use – be that Workflow, Portals, Machine Learning and any other useful App or Functionality we can connect with our Cloud Database.

We can think of this as:

  • Common Data Service = Cloud Database
  • Common Data Service + Sales 1st Party App = Dynamics 365 for Sales
  • Common Data Service + Service 1st Party App = Dynamics 365 for Service
  • Common Data Service + SharePoint = Document Repository
  • Common Data Service + Sales, Service, Marketing Apps = Dynamics 365 Enterprise
  • Common Data Service + Our Bespoke App = XRM

This separates the concept of the CDS as the backbone for our systems, from the CRM functionality that makes up the Sales, Service and Marketing 1st Party Apps from Microsoft.

In this fashion, we are only buying and paying for the functionality we want – not having to buy full CRM just to actually want to implement an XRM Project.

We can build our Apps that use the CDS, and then potentially connect those Apps to our data in the Microsoft Cloud to start creating fully integrated solutions.

image

The Building Blocks of the CDS

In the Common Data Service, you work with the following concepts as fundamental “building blocks” to create and interact with your data structure.

  • Entity: Developers would refer to an entity as a “data table”, but entities are really just buckets of the data you track in the Common Data Service. Think of an entity as any “type” of data you’ll track in Dynamics 365. Common entities used in model-driven apps are Contact and Account, for example.

  • Record: A record is just one instance of an entity. For example, your Contact entity will have one record representing each contact in your system.

  • Field: You can enter information about each record in fields. On a contact record, you would probably have fields where a user can enter each contact’s first and last name, email address, telephone number, and any other important information about that person.

  • Form: A form is how a record is represented in the user experience. When I look at an individual contact’s record, I am viewing a form. The form includes all the Contact fields where I can enter my data.

  • Relationship: In the Common Data Service, you can create relationships to define how entities are related to each other. (For example, Contacts could relate to an Account, meaning that these contacts probably work for a larger organization that is represented in Dynamics 365 as an Account record.)

Our initial starting point with the CDS includes some pre-built concepts built using these concepts – but only the bare bones, Account, Contact, User and other System Entities.

We can then add our blocks to either existing Entities, or (more likely) create our own Entities and add our functionality into how we use the CDS.

Once done, we will likely group this functionality into Apps that our Users will use to access these concepts and functionality – the Apps being the gateway to our Cloud Database using the CDS.

This describes the process of how we use the CDS to build new Model-driven Power Apps.

Where we use CRM, we use Microsoft 1st Party Apps to immediately gain access to a range of useful functionality rather than building it ourselves.

This diagram illustrates some of the breadth to this in which Microsoft App introduces which concepts to your use of the CDS as way of creating a CRM System for your business:

image

What does this mean for Business Analysis?

When we come to a new Project, we will roll out the CDS and potentially one or more of the Microsoft Apps above – this gives us our starting point.

Our Business Analysis and initial Workshops is then to define the ‘fit’ and the ‘gap’ between this starting point and how CRM should work for your organisation.

We document both the fit and the gap into our Solution Specification for the Project.

  • The Data Dictionary – what custom fields we will add into the CDS for our solution + which system fields we will use from the base 1st Party Apps
  • The Requirements Catalogue – the old favorite!  This describes what the system needs to do, and how the functionality will be provided.  Is this built into one of the 1st Party Apps we are using (Standard Sales Functionality) built into the CDS via an App as Low-Code, or developed entirely using Pro-Code.
  • Business Process Flow – where we have ‘transactional’ entities that model a particular process in our organisation, such as a Sales Opportunity or Service Case, we model the stages that the transaction goes through to track how these will be implemented in CRM using a BPF Flow.
  • Apps – the list of Apps we are planning to build for the organisation, so we can effectively use this as a Lookup in the Specification to specify which Requirements will be met by which App.
  • Queries – when architecting a solution or working with a challenging business model, we will hit queries that we don’t initially know the answer to – here we collect those queries to review with the client, or review with a Solution Architect to see what other area of the Cloud or Functionality might be the right tool for the job.

This collectively gives us a way of recording and then realising the requirements of the business using the Tools we have available in the Microsoft Cloud.

The Practical Bits..

When we come to launching a new CDS/CRM Project for a Client, we will use the following areas of the Microsoft Cloud:

Power Platform Admin – our first step will be to create a new Environment as a new CDS + 1st Party Apps Database

This will typically be the Sandbox Environment to begin with, so we can then use that for Prototyping and Review during Business Analysis.

https://admin.powerplatform.microsoft.com/environments 

image

Power App Designer – the new Designer area for building Apps for both the Power Platform and Dynamics 365

https://make.powerapps.com/

image

If you are working with PoweApps or Dynamics, best to save these in your Browser Favorites as you’ll be coming back to them frequently when building and prototyping your solutions!

Summary

Hopefully the above information gives a good introduction to the CDS as the launching point for Dynamics 365 in the Microsoft Cloud.

It can be initially tricky to get your head round how all this works, as it depends on understanding the layers of abstraction inherent in IT Architecture – that the CDS is a subset within PowerApps which is in itself a subset of the Dynamics 1st Party Apps.  The acronym leaden nature of IT can also be a challenge until each one is well understood!

However it is a logical approach and fine tuned from years of practical experience of how people actually use CRM since the growing popularity of CRM Systems from 2000 onwards.

(it makes alot of sense to me, as the CDS – App – CRM approach solves a lot of challenges we saw in the CRM industry way back when, particularly the use of Apps to ring fence areas of the CDS into manageable chunks for the end-users of our solutions – but is always tricky to know whether having the full back story makes it easier to follow, or in fact makes it more difficult as you bring all your previous baggage to the new concepts!)

CRMCS focuses on providing Services to Clients looking to get the best from the Microsoft Cloud, and Technology to help make the Cloud better, so we have a range of information on this blog to help understand these concepts better.

The Dynamics Community is also a great source of knowledge, tips and inspiration.

Share this Article

Search Articles

Filter Articles

CRM Tech DocMan

Recent Articles

Dynamics 365 Marketing: Lead Scoring and Sales Acceptance Designing and Developing Microsoft Power Apps Portals Thank You for Attending CRMCS’ Webinar - Achieving B2B sales excellence with Dynamics 365 & Microsoft Teams Thank You for Attending Our Webinar - Achieving B2B sales excellence with Dynamics 365 & Microsoft Teams Webinar: Discover How CRMCS Have United Dynamics 365, SharePoint and Microsoft Teams To Create Sales Excellence Ignite your workflow by adding DocDrive365 to Office 365 The CRMCS guide to everything you need to know about integrating Teams with Dynamics 365 Saving Time By Keeping Documents In One Place TDE Database Encryption with On Premise Dynamics The Key to Successful Compliance in 2020 Part 2: Let’s get GDPR Compliant with Microsoft Power Automate Top 3 Essential Tips for Remote Working Dynamics 365 Marketing: Top 5 Best Features Dynamics Day in the Life - Puma Investments Can you use Teams to amplify collaboration in Dynamics? Part 1: Using a Scheduled Power Automate to Trigger Expiry Date Reminders The secrets of successful document collaboration in Dynamics CRMCS launches new AppSource approved DocDrive365 Dynamics Day in the Life - Moneypenny Release Management Add the App to Dynamics DocDrive365 Security: Day One - Getting Started with Dynamics to SharePoint Permissions Building a New Scheduled Process using Flow Why Teams matters to CRM?
  • "Paul has made a real difference to how my team of 24 people record and store valuable customer data and sales opportunities. Highly recommended."

    James, Operations Director

  • "Understanding your business allows us to advise when to implement aspects of CRM and, likewise, when not to."

    Paul McQuillan, Managing Director

  • "Dynamics 365 and CRMCS have made a real lasting difference to our business, allowing us to replace older systems that were holding back our performance."

    Grahame, Chief Operating Officer

  • "James worked well with us to help connect CRM with Outlook and relate how this might benefit our team using CRM for Property Care."

    Natalie, Property Care Supervisor

  • "Matt was really good with helping us run User Testing on the new Compliance Module of our CRM System."

    Tom, Compliance Administrator

Prefer to go old-school?

Write to us using the below addresses.

Head Office
CRM Consultancy
61 Oxford Street
Manchester
M1 6EQ

London Office
CRM Consultancy London
Grosvenor Avenue
London

Content © CRM Consultancy.