Dynamics 365 Essentials: Getting Started with Dynamics 365 Apps in the Common Data Service

© Sarah Critchley 2020

S. CritchleyDynamics 365 Essentialshttps://doi.org/10.1007/978-1-4842-5911-5_1

1. The Common Data Service

Sarah Critchley¹  

(1)

Cambridge, Cambridgeshire, UK

The Common Data Service is a single place for apps. Data is stored in the Common Data Service that is served to many applications to be viewed and updated. Sounds like a basic definition, but really when it comes down to it, that is what is at the core of the Common Data Service, or CDS. The CDS is a data store, but it does more than simply store data in the same way as a SQL database, for example. The CDS reviews what data type is being stored, such as image data, and stores it in the correct type of storage based on the data type. Model-Driven Applications using Power Apps are built on top of the CDS, as the UI layer, or the presentation layer, and are designed for the user of the applications to interact with the data stored in the CDS.

In contrast to Model-Driven Applications, Canvas Apps are applications where the data store and the interface that the user of the apps interacts with are both created by the app maker. Both Canvas and Model-Driven Apps can utilize the CDS as their data store. The Common Data Service also acts as a data store and model for Dynamics 365 Customer Engagement data. Data entered through the user interface of any Dynamics 365 first-party Application gets stored within the Common Data Service. This results in the Common Data Service, or CDS, acting as one data store of information within the Power Platform. Included in the Power Platform are Power Apps, Power Automate, and Power BI. Within Power Apps, there are different types of applications that can be built, including Canvas, Model-Driven, and Portal. This book will focus on Dynamics 365 Apps and Model-Driven Apps. There is also a new chapter to introduce the new Power Platform Portal App type.

Model-Driven Apps utilize the Common Data Service as their default data store in the same way Dynamics 365 first-party Apps do. Dynamics 365 Apps are actually, at their core, Model-Driven Apps themselves that include extensive business logic and customizations created and managed by Microsoft. They have been designed so organizations don’t have to create these apps themselves, which cover familiar industry-agnostic scenarios, accelerating the app’s implementation time and increasing return on investment (ROI) value.

It is important to note that while Dynamics 365 Apps are Model-Driven Apps, Model-Driven Apps are not Dynamics 365 Apps – they are not mutually exclusive. A Model-Driven App uses the Unified Interface (UI). The UI is the presentation layer that is included in a Model-Driven App, prebuilt, so makers do not have to create it themselves and instead define the data (the model) and add the required data to forms which are contained within the app. The scaffolding, such as navigation, sitemaps, basic CRUD operations, and responses to mobile and tablet, is already there ready to be put together based on whatever the essential need for an organization. A Model-Driven App is still classified as custom as the process behind it is a custom process being built and the app is simply the facilitator.

External data sources can be integrated with the Common Data Service so that the CDS can serve business applications of an organization with all the data stored and secured in a single space. The Common Data Service allows for a centrally controlled area to add and modify the structure (which reflects within the Dynamics 365 CE user interface) and for users to create canvas-driven applications that can utilize the data stored within the Common Data Service. Users would use Canvas Apps created in the Power Apps designer to link the Common Data Service as a data source so the users could retrieve and add new data. Changes in this data are always reflected in Model-Driven Apps without any integration or user intervention, as they are both using the same data store, the Common Data Service.

Organizations can begin with just the Common Data Service, which includes a core set of entities, such as Account, Activities, and more. The principal design of the Common Data Service is that the entities (record types) are added to the model based on other Model-Driven Apps being subscribed to them. An example of this would be that an Application using a custom Event entity would then allow this entity to be used by other Apps using the CDS. The Common Data Service is increasing in functionality every month, so this chapter aims to give an introduction to the service.

Power Automate is covered more extensively in Chapter 14, and can also utilize the Common Data Service from triggers when a record is created, deleted, or updated and then perform actions within the Common Data Service, such as creating new data. Power Automate and Canvas Apps are two of the core tools that can help construct automation and integration in the Common Data Service to enable organizations to benefit from a loosely coupled architecture of many different sources that form one operational database.

To summarize, no integration is required for the Common Data Service and Dynamics 365. Both applications use the same database. Users enter data, normally from a model or canvas-driven app, and the data is stored in a single common database that is visible in both Dynamics 365 interface and the Common Data Service.

Starting with the Common Data Service

The Common Data Service maker area, within the Power Platform maker experience (make.powerapps.com), is the same area users would go and make modifications to the Common Data Service whether they were creating a Model-Driven App or modifying a first-party App, such as Customer Service.

At the time of writing, there are two core ways to begin utilizing the Common Data Service, highlighted in the following:∗

Begin with Power Apps that include the Common Data Service, creating a CDS-Only environment and the capability to build Model-Driven Apps.

Begin with a Dynamics 365 license, creating an environment licensed for Dynamics straight away which includes the Common Data Service and the capability to build Model-Driven Apps.

∗Note that this book will not be referencing licensing capabilities.

Before we get started, it would be useful to cover some terminology.

There is a concept called an environment. An environment is a digital space which includes a single CDS data store. This environment is often categorized into a development, test, or production environment, very much like core software development methodology. A tenant is a collection of multiple environments. Dynamics 365 exists in one or more environments depending on if a user is licensed in the administration portal for one or more applications. This will direct if they see the core first-party Dynamics Apps. When Dynamics 365 CE is licensed and set up, the relevant applications are downloaded as solutions within the environment.

The Common Data Service manages the security of those applications using primarily Security Roles and, more recently, Azure AD Groups. There are multiple ways to secure and share an application, and these will be covered in later chapters. Model-Driven Apps can be created in the maker portal in the same way Canvas Apps are created – go to make.powerapps.com and select Apps.

The Common Data Service exists per database per environment. An organization’s sandbox and production Dynamics 365 CE environments will each have a separate database that is utilized and accessed using a different Common Data Service. The different environments can be accessed via admin.powerplatform.com which gives administrators the ability to review the current environments, modify various settings, and create new environments. (At the time of writing, new environments created in the Common Data Service create an XRM-only instance of Dynamics 365 CE, with currently no upgrade path to add the customer service, sales, and other Model-Driven licensed apps into it.) The XRM-only, or CDS-Only, environment can be accessed in the same way via admin.powerpowerplatform.com.

Licensing is managed through the Office 365 Portal via Admins. It is expected that users’ licenses attained through Dynamics 365 CE subscriptions and functionality will still be driven this way. Alternative routes are suggested for those organizations not requiring Dynamics 365 CE, where they can choose Common Data Service–only plans.

Figure 1-1

Accessing the Dynamics 365 CE environment and Common Data Service

All tenants have what is referred to as a default environment. This environment is often a personal productivity environment for all staff within an organization where they can review the features and functionality of the Power Platform. Additional environments are then created to create the dev, test, and production models (and more in some scenarios). The default environment establishes a way to foster adoption and build a community for the technology within the business. To further see what users are doing within this environment, organizations can utilize the (unofficial, open source) Center of Excellence (COE) kit. More information on the COE kit is available at the end of this chapter.

How Can the Common Data Service Be Accessed?

Administrators and customizers often referred to as makers within Microsoft documentation and learning material can access the Common Data Service by navigating to make.powerapps.com.

On the top right-hand side of the website, the environment selector is available for you to switch between accessible environments (Figure 1-2). Environments can contain different types of apps, including Dynamics 365, Model-Driven, and Canvas Apps. Administrators can also create new environments to be accessed from this dropdown at admin.powerplatform.com

Figure 1-2

Changing environments

Once an environment is selected, provided you have the relevant permissions, you can either click Create on the left-hand-side panel and create an app from the screen based on the prompts or navigate to Apps also on the left-hand-side panel and a list of all Apps in this environment will be displayed. You can create new apps by selecting New app and choosing between the options available.

Figure 1-3

Create an App by using the Create button on the sitemap in make.powerapps.com

Figure 1-4

Navigating to Apps and selecting New app will show available apps to be created in make.powerapps.com

Navigation Within the Common Data Service

Navigating the Common Data Service is achieved by using the left-hand navigational pane. The left-hand navigation has the following options:

Home – Can create a new app and review documentation or apps.

Learn – Displays help articles in the Microsoft documentation, especially getting started material.

Apps – Displays a list of Apps and allows new ones to be created from this screen.

Data – Adds to and views the data model for the Common Data Service and Dynamics 365 CE.

Flows – Displays all the Flows in this environment without navigating to flow.microsoft.com, which is the specific Power Automate environment.

AI Builder – Adds flows that are triggered from Power Apps here.

Solutions – Only visible in Model-Driven mode; lists the solutions in the same way as the solutions are listed within Dynamics 365 CE. New solutions can be made and imported from here.

The main area of functionality is the Data option, which allows administrators and customizers to view and modify the schema of the Common Data Service and that of Dynamics 365 for Apps (Figure 1-5). When you click the Data option, more options become available, including the following:

Entities

Option sets

DataFlows

Export to DataLake

Connections

Custom connectors

Gateways

Note that navigation does change on occasion, and this may be different based on latest updates from what you see at the time of reading.

Figure 1-5

The left-hand pane option Data houses the data model for Dynamics 365 CE and the Common Data Service

Under the Data heading, in the Entities section, a list of the entities found in the Common Data Service is available. The entity list is filtered for default entities and can be modified to include custom entities or all entities by selecting the dropdown list in the top-right corner next to the search bar, as shown in Figure 1-6. When navigating the CDS this way, it is important to remember this filter when searching for specific entities.

Entities such as the Case entity, included in the Dynamics 365 Customer Service App, are classified as Custom and will not appear when filtered to Default. New entities can be created here by selecting New Entity and completing the right-hand-side pane that appears, ensuring Save Entity is selected at the bottom. (However, Solutions should always be used to create new entities; see Chapter 10 for starting from a Solution and to know why this is important.)

Figure 1-6

The Entities list is pre-filtered to Default. This can be changed in the filter options in the top-right corner

Click an entity name to open the entity definition. The entity definition contains familiar items covered in this book, such as the fields, relationships, business rules, views, and data. In the Data tab on this view, the data from within the Common Data Service and Dynamics 365 CE can be displayed. Use the view selector in the top right, shown in Figure 1-7, to ensure the views match, to then see the data stored in the Common Data Service. This is the same data that users would see in Dynamics 365 CE. Again, changing the default view is essential as it can appear as if no data is visible in particular views as it is being filtered by default.

Figure 1-7

The views can be changed when selecting the Data tab in the top right of the window

In Figures 1-8 and 1-9, the same view of data for the Account entity is available in both the Common Data Service and Dynamics 365 CE using the view All Accounts.

Figure 1-8

Account view within the Common Data Service with the Active Accounts view selected

Figure 1-9

Account view within Dynamics 365 CE with the Active Accounts view selected

This further reinforces the point that the Common Data Service is a single database where data can be viewed and accessed from multiple places.

A lot more operations can be completed in this area, such as adding new fields under the Fields section of the entity, adding relationships and views, and creating new forms. Creation of this metadata for entities will be reviewed in later chapters in Section 2 of the book where we go into much more detail.

Summary

This chapter has covered the essentials of the Common Data Service. It is a key chapter that describes the underpinning platform of Dynamics 365 within the Power Platform. In doing so, it introduces the Common Data Service, what this is, and the relationship between the Common Data Service and Dynamics 365 Customer Engagement. The core advantage of the Common Data Service is being able to serve multiple data entry points for users, surfacing data in the user-facing application that is relevant for specific users using different types of apps.

There is a great deal of flexibility for organizations using the Common Data Service, especially following the upgrade to version 9 of Dynamics 365 CE. Organizations will utilize the Common Data Service through the Dynamics 365 Customer Engagement interface. Some users would likely never interact with the maker experience that you’ve seen in this chapter and only ever view the data through the relevant app (whether that is a Dynamics, Model-Driven, or Canvas application).

This chapter has covered how to get started using the Common Data Service, including familiarity with the interface and accessing entities and related data through views in the same way as Dynamics 365 Customer Engagement is structured for the user. New metadata can be added, such as fields, relationships, and option sets. Follow the chapter tasks at the end of this chapter to become familiar with this functionality and keep up to date on the latest releases of the Common Data Service, as with time the functionality will continue to grow and improve.

Chapter Tasks

Note: To complete these tasks, you will be required to create a free trial of Dynamics 365 Customer Engagement which can be found at trials.dynamics.com:

1.

Navigate to make.powerapps.com and become familiar with the latest user interface.

2.

Review the data model under the Data heading.

3.

Navigate to the Account entity and filter the view under the Data heading to show All entities.

4.

Navigate to the Dynamics 365 Customer Engagement Sales App, locate the accounts and the same view, and compare the data – it should be the same.

5.

Change environments using the environment picker.

6.

Navigate to Apps and create a Model-Driven App and then a Canvas App. Note the differences between the two creation experiences.

Further Reading

Common Data Service (Microsoft, 2018). URL: https://docs.microsoft.com/en-us/powerapps/maker/common-data-service/data-platform-intro

Solutions in the Common Data Service (Microsoft, 2018). URL: https://docs.microsoft.com/en-us/powerapps/maker/common-data-service/solutions-overview

Restricted Entities (Microsoft, 2018). URL: https://docs.microsoft.com/en-us/powerapps/maker/common-data-service/data-platform-restricted-entities

Center of Excellence (Microsoft, 2019). URL: https://powerapps.microsoft.com/en-us/blog/introducing-the-powerapps-center-of-excellence-starter-kit/

Center of Excellence (GitHub, 2020). URL: https://github.com/microsoft/powerapps-tools/tree/master/Administration/CoEStarterKit

© Sarah Critchley 2020

S. CritchleyDynamics 365 Essentialshttps://doi.org/10.1007/978-1-4842-5911-5_2

2. Customer Management

Sarah Critchley¹  

(1)

Cambridge, Cambridgeshire, UK

This chapter will introduce the Account and Contact records and explain why these are so fundamental within Dynamics 365 Customer Engagement. This introduction will include key things to consider when using these records at the start of implementations and how such records can be customized to suit the needs of the business. It will then move on to email integration options, focusing on installing the latest App for Outlook before moving on to how activities can be utilized and how they are paramount for customer interaction and insight, timeline management, and customizing the timeline. This chapter will set you up with core knowledge about Dynamics 365 CE, allowing you to move forward with confidence into the next chapters.

Accounts and Contacts

Accounts and Contacts are two fundamental record types within Dynamics 365 CE. Record types are often referred to as entities within Dynamics 365 CE. Entities are used to categorize the types of a record and in database terms are the same as a table within a database. Users and processes create records of a type within the user interface or programmatically, creating rows within that table. Entities have related metadata linked to them, such as fields, views, and forms. Fields are columns within the database linked to the entity and are the descriptive information that is stored within the row. Dynamics 365 CE comes with many entities already pre-created and used within defined business processes, such as Accounts and Contacts. There is also the ability to create custom entities that can be used to support existing processes or, instead, to create entirely new processes.

Most interactions within the rest of the system center around these records. Because of this, they are often the most customized or renamed entities in the standard system. The name is often changed to People or Organizations to represent the terminology of a specific implementation. Changing the name of these entity types can often lead to more work than originally anticipated as a result of having to change any reference to the original names, such as in views and dashboards. In some areas, the original names cannot be changed, which then leads to further confusion as an organization has to be familiar with both terms.

To avoid renaming these fundamental entities, it helps to understand these records’ potential within an organization and how they are represented. Despite changing the name of these entities within an implementation, people will often still find that the name is only representative of a department or a section of the company, while a different department would refer to them with another name. Understanding the potential of these records and looking at the different scenarios they are used in is so important for all projects and will lead to a greater appreciation of how they can fit within the organization using Dynamics 365 CE.

What Are Accounts and Contacts?

Accounts are fundamentally a collection of related records that are related to a specific engagement or business relationship. A contact represents how to contact a person. I have chosen my words very carefully here for good reason. Accounts often get used specifically as organizations or companies; however, using them in this way is fine only until you start getting into a few different scenarios. An example would be when using Fourth Coffee as the company:

Is Fourth Coffee the legal entity, or is that a different company? Will that different company be its parent company?

Is Fourth Coffee the one that invoices go to, or could another record deal with the invoices?

Is Fourth Coffee a contractor that also is a contact and a company at the same time? What if a contractor utilizes subcontractors who belong to a different company?

Once these questions start to be asked, one might think they can be resolved by adding new fields to the entity, which becomes problematic. Data starts to become only important in specific scenarios, and these records become packed with fields that will not be relevant for all records.

Another consideration for the Account record is deciding where this would sit within the counterpart finance system structure. A Contact record would be linked to an Account record in CE, and other information would be held in the finance system. The front- and back-office systems often have different users, creating a requirement to open up the integration between the two systems so they display information from both systems. In finance and operations, a Vendor is a separate record type to that of an Account, which has a totally different meaning.

Returning to the definition of an account, as it is a collection of related records that are related to a specific engagement or business relationship, it’s easy to see an account differently based on different perspectives. So, for those instances where you wish to add organization data or contractor data, an option would be to extend the Account record with custom entities specific to the type of data you’re holding. This would abstract the data from the core record information.

The same challenges appear for contacts. Contacts often get described as customers, but could refer to internal contractors and not necessarily an individual whom the business treats as a customer. The terms individuals and people are also a challenge, as these come with the assumption that only one of that record would exist, as only one exists within the world in which they do business. Within Dynamics 365 CE, uniqueness in relation to Outlook Integration (which will be discussed in a later chapter) is based on email address. This functionality underpins the creation of new contact functionality and links email activities to the contact. For this reason, it is then easier to approach the definition of a contact as being how to contact a person.

Ensure that your definitions of what an account and a contact are within a business system are clearly defined and are discussed early on in your project. This could help with enhancing the system through customizations if required and aid in resolving any problems created later with terminology misunderstandings.

Parent Accounts

Dynamics 365 CE provides the capability to associate one account with another account as its parent. A parent can have many child accounts; this structure is easy to see in a visual format by clicking the Hierarchy icon on a view within the legacy Classic UI application. Figure 2-1 displays the field this is referencing within the form.

Figure 2-1

An account with the Parent Account field set, making this a child account

You can then visualize the hierarchy of accounts by clicking the Hierarchy button on the list view (next to its name). This is shown in Figure 2-2.

Figure 2-2

Visual hierarchy view available in the Classic UI application version 9.02

Associating an account as a child or a parent of another doesn’t just give helpful reporting capabilities. It also automatically rolls up associated activities, such as appointments and emails, from the child account and makes them visible within the parent. This is especially helpful when a parent account has multiple child accounts, so that all activities will be visible at the parent level, without users having to individually find those activities within the children.

This relationship is especially useful when an account is responsible for invoices, as they can normally be associated with a parent account (which is the case for local authorities in the United Kingdom in a specific region; normally one is invoiceable). By associating these relationships, it means any further customizations done within this area to automate functions can be easily achieved.

Standard Features Associated with Accounts and Contacts

There is standard functionality available on the Account and Contact records that is useful to be aware of when using Dynamics 365 CE.

Like the account and parent account rollup functionality, activities from an associated contact automatically roll up to the contact’s associated account. This is especially useful in instances of Outlook Integration where a user is using Outlook to communicate with a customer; for example, when investigating a case, those emails can be automatically tracked to the Case record within Dynamics 365 CE using the Outlook Integration feature. When that record is viewed within Dynamics 365, those email activities can be seen not only in the Contact record but also in the associated Account record, giving a single record within the system the ability to see all communication from all associated Contact records.

To use this feature, ensure the relationship between Contact and Account records is set using the Account Name field within the Contact record; the associated activities will automatically roll up.

In Figure 2-3, the phone call was scheduled on a Contact record.

Figure 2-3

A Contact record with an upcoming Phone Call activity

The phone call can be seen within the Account record in Figure 2-4, as it has rolled up to the associated account.

Figure 2-4

The account associated with the Contact record, showing the Phone Call activity, despite it not being directly associated

Within the Account and Contact records, there is a standard feature that allows users to control whether emails and bulk emails are to be sent from within Dynamics 365 CE to those contacts. This feature is particularly useful when automated emails are being sent from within the system and an organization needs to prevent these from being sent. It doesn’t, however, prevent a user from sending a contact an email directly from within Outlook.

The fields that can restrict this process are included in the section called Contact Preferences within the Details tab, which can be seen in Figure 2-5. The Email field will prevent any email from being sent from within Dynamics 365 in both the context of an individual email activity and bulk emails. Emails are classified as bulk email when they are sent from quick campaigns, campaign activities, or customer journeys (using the Dynamics 365 Marketing) or are sent using the Send Direct Mail feature available on a Contact record. Individual emails are single email activities associated with individual records. The Bulk Email field will prevent emails from being sent out only when considered a bulk email.

Figure 2-5

The Contact Preferences section within a Contact record holds the Email and Bulk Email fields

These fields are often utilized within marketing add-ons to the Dynamics 365 CE platform through marketing lists or segmentations. Subscription lists are a common feature underpinning how contacts are contacted to be able to tailor the marketing experiences they receive. A part of this is where a user can unsubscribe from a list so as to no longer receive messages using a specific channel, such as email. A contact can also ask an organization to not contact them again regarding any sort of message and to withdraw any sort of service from the contact. These examples are where Contact record preference fields hold a high value, as they then prevent automated messages from being sent and assist in segmentation within queries.

Lastly, there are some fields to be aware of before you begin any sort of customization that come as part of the native Dynamics 365 CE product. These include the fields within the Billing and Shipping sections of Account and Contact records, highlighted in Figure 2-6. These fields, while not holding any functionality, are often also found on other records, such as Quote, Order, and Invoice. This means, with some relative ease, by using relationship mapping, covered later in the book, you can automatically populate these fields with the