Describe Common Data Services Flashcards
Describe the general idea of the Common Data Service
Common Data Service is a cloud-based, low-code data service and app platform, which allows you to leverage the security and connectivity of Microsoft services.
Common Data Service connects easily to all aspects of the Power Platform so that you can fully control, automate, and strengthen your business.
With standard entities and fields, as well as the ability to easily define relationships between your data, Common Data Service was built for powerful, scalable solutions.
How does the Common Data Service comply with your potential data residency?
Managed and maintained by Microsoft, Common Data Service is available globally but deployed geographically to comply with your potential data residency.
Is the Common Data Service designed for stand-alone use on your servers?
No, so you will need an internet connection to access and use it
What is the Common Data Service designed for?
The Common Data Service is designed to be your central data repository for business data and you might even be using it already. Behind the scenes it powers many Microsoft Dynamics 365 solutions such as Field Service, Marketing, Customer Service, and Sales. It is also available as part of Power Apps and Power Automate with native connectivity built right in. The AI Builder and Portals features of the Power Platform also utilize the Common Data Service.
Common Data Service: What’s in the box? (Explain the five categories of features in the Common Data Service)
Security: Common Data Service handles authentication with Azure Active Directory (AAD) to allow for conditional access and multi-factor authentication. It supports authorization down to the row and field level and provides rich auditing capabilities.
Logic: Common Data Service allows you to easily apply business logic at the data level. Regardless of how a user is interacting with the data, the same rules apply. These rules could be related to duplicate detection, business rules, workflows, or more.
Data: Common Data Service offers you the control to shape your data, allowing you to discover, model, validate, and report on your data. This control ensures your data looks the way you want regardless of how it is used.
Storage: Common Data Service stores your physical data in the Azure cloud. This cloud-based storage removes the burden of worrying about where your data lives or how it scales. These concerns are all handled for you.
Integration: Common Data Service connects in different ways to support your business needs. APIs, webhooks, eventing, and data exports give you flexibility to get data in and out.
Define a Common Data Service database
A Common Data Service database is a single instance of Common Data Service which stores data in a set of standard and custom data structures called entities. An entity is a logical set of records that is used to store data. Entities are like tables in a relational database, but there are subtle differences. Records within an entity contain many fields to manage individual pieces of information about a single record.
You can create one or many database instances in Common Data Service to host data behind your business solutions. Each instance of a Common Data Service will start with the same set of entities to store data, but you can always extend and customize a Common Data Service database to meet specific business needs. This means that you can share business solutions that reference standard entities in Common Data Service across your organization or with any other organization by using it anywhere in the world.
Describe the scalability of a Common Data Service database
A Common Data Service database supports large data sets and complex data models. Entities can hold millions of items, and you can extend the storage in each instance of a Common Data Service database to four (4) terabytes per instance. The amount of data that is available in your instance of Common Data Service is based upon the number and type of licenses that are associated with it. Data storage is pooled between all licensed users, so you can allocate storage as needed for each solution that you build. Additional storage can be purchased if you need more storage than what is offered within standard licensing.
Describe the Common Data Model
The standard entity design in a Common Data Service database is based upon an open data model standard called Common Data Model. Common Data Model is a logical design that includes a set of open-sourced, standardized, extensible data entities and relationships that Microsoft and its partners have published in an industry-wide initiative called the Open Data Initiative. This collection of predefined entities, attributes, semantic metadata, and relationships form the basis of the Common Data Model.
Describe the Common Data Service structure and benefits
The structure of a Common Data Service database is based upon the definitions and schema in the Common Data Model. The key benefit of using Common Data Model as the basis of a Common Data Service database is simplified integration of any solutions that use a Common Data Model schema because the standard entities of the solution are the same. You will also be able to take advantage of a rich ecosystem of solutions that vendors have built from using Common Data Model. Best of all, there is practically no limit to how far you can extend a Common Data Service database.
What is a Common Data Service entity? What are the two types of entities?
An entity is similar to a table in a database or in an Excel workbook in the way it stores data. It is a logical structure containing records that are made up of fields or put more simply, rows and columns.
Standard: The base set of entities that are created for every instance of a Common Data Service database. You can add more fields to any entity, but you can only delete fields from a custom entity.
Complex: Entities that contain complex, server-side business logic, including real-time workflows or plug-ins. Some of the entities that are used in Dynamics 365 applications are complex. Care must be taken if you add server-side logic to ensure that users have the proper license to use the complex entity. Additional information about complex entities can be accessed by following the link within the summary unit of this module.
What are Common Data Service fields?
Fields are a way to store a discrete piece of information within a record in an entity. You might think of them as a column in Excel. Fields have types, meaning that you can store data of a certain type in a field that matches that data type. For example, if you have a solution that requires dates, then you would store the date in a field with the type of Date. Similarly, if you want to store a number, then you store the number in a field with the type of Number.
The number of fields within an entity varies from a few fields to a hundred or more. If you need more than a few hundred fields in an entity, you might want to reconsider how you are structuring data storage for your solution because, likely, there is a better way.
Every database in Common Data Service starts with a standard set of entities and each standard entity has a standard set of fields.
Tip: Always use standard entities and fields when possible. You can rename an entity if that makes the entity more understandable in the context of your solution. Always review the list of standard entities and make sure a standard entity will not meet your needs before you create a new entity.
What is the purpose of using Common Data Service relationships?
To make an efficient and scalable solution for most of the solutions that you build, you will need to split up data into different containers (entities). Trying to store everything into a single container would likely be inefficient and difficult to work with and understand.
Splitting the data into multiple entities and relating them means that you build an efficient solution that can scale while maintaining high performance. Splitting the data into multiple entities also means that you will not have to store repetitive data or support huge records with large amounts of blank data. Additionally, reporting will be much easier if you split the data into separate entities.
Describe the relation connection between two entities
Entities that relate to one another have a relational connection. Relationships between entities exist in many forms, but the two most common are one-to-many and many-to-many, both of which are supported by Common Data Service.
One-to-many relationships are also known as parent-child relationships. In the previous invoice example, the invoice entity would be the parent and the line items would be a child entity. An invoice can have zero, one, or many line items (child records), but the line item will always be related to just one invoice (parent record). Typically, the child records will not exist without a parent record.
A field that only allows unique values, such as invoice number, is used to identify the parent record. This unique field is called a key. The same value (the parent key) is stored in the related child records. This field is called a foreign key when the child record is used to store the parent key value. Ingeniously, filtering is used to display child records with a value in the foreign key that matches the key value in the parent record. This allows applications to display the child records (line items in the previous example) that belong to a particular parent record (invoice in the previous example). This concept underlies many business software applications.
Splitting data into different entities makes for an efficient solution design that can scale, but knowing how to split up the data into entities can be difficult. Thankfully, Common Data Service already contains many of the entities that most organizations will need. Using standard entities and extending them will ensure that you are building solutions around a proven, scalable way of storing the data that is used by your solutions.
Describe Common Data Service environments
Environments are used to store, manage, and share your organization’s business data, apps, and flows in the Power Platform. Each environment allows you to provision one Common Data Service database for use within that environment. Common Data Service environments allow you to manage user access, security settings, and the storage that is associated with that database.
Each environment is created under a Microsoft Azure Active Directory (Azure AD) tenant, and its resources can only be accessed by users within that tenant. An environment is also bound to a geographic location, like the United States. When you create a Common Data Service database in an environment, that database is created within datacenters in that geographic location. Any items that you create in that environment (including connections, gateways, flows that are using Power Automate, and more) are also bound to their environment’s location.
You can create more than one environment to manage solution development and data storage by setting up one environment for development, another for testing, and another for production use. Also, you can set up an environment based on a geographical location. For example, you might set up an environment for Europe and another for Asia. Each of these environments will have zero or only one instance of Common Data Service.
What is a Common Data Service business rule? Could you give an example of a business rule usage?
In Common Data Service you can define business rules. Business rules allow you to apply and maintain business logic at the data layer instead of the app layer. Put more simply, if you create business rules in Common Data Service, they are in affect regardless of how you interact with the data.
Business rules can be used by canvas apps or model-driven apps to do the following:
- Set field values
- Clear field values
- Validate data and show error messages
Model-driven apps can also use business rules to:
- Show or hide fields (model-driven apps only)
- Enable or disable fields (model-driven apps only)
