Identify the core components of Power Platform

Microsoft Power Platform consists of primary applications, such as Power BI, Power Apps, Power Automate, and Power Virtual Agents. However, there are also underlying technologies that all the applications can use, including the Common Data Service database, a collection of data connectors, and the AI Builder automation and intelligence engine, as shown in Figure 2-1.

Skills covered in this chapter:

• ■ 2.1: Describe Common Data Service

• ■ 2.2: Describe connectors

• ■ 2.3: Describe AI Builder

Skill 2.1: Describe Common Data Service

Common Data Service is a cloud-based data storage solution that all the Power Platform applications can use to maintain their data in a secure, manageable environment. The Common Data Service was originally designed for use with Dynamics 365 applications, such as Sales and Customer Service. Therefore, Power Platform developers can use their existing Dynamics 365 business data, logic, and rules when creating new content in Power BI, Power Apps, and Power Automate.

Describe the Power Apps user experience

Power Apps and the other Power Platform tools require data for developers to work with, and they are all able to connect directly to many different data sources, including local files, network resources, and cloud-based services.

Storing app data in Common Data Service

Depending on the nature of the app they are building, it is common for developers to have to connect to multiple data sources to gather the information they need. This can mean accessing multiple sites, authenticating with multiple accounts, and updating multiple data points at frequent intervals. Common Data Service can simplify this data gathering model by allowing developers to store the data from the different sources in a single protected place, in an integrated form. The data stored in Common Data Service is then available to any of the Power Platform tools, along with any Dynamics 365 data that is also stored there.

For example, when an organization relies heavily on data stored in many Excel workbooks, importing them one time into Common Data Service can be more convenient than connecting to each one repeatedly every time an app is revised or updated. When importing data into Common Data Service, developers can model and transform the data using Power Query, just as they can when importing data using Power BI.

As with direct connections between apps and data sources, Common Data Service can synchronize with the data sources at regular intervals to keep the stored data updated. The apps that use the Common Data Service data can then be updated with the latest information as well.

Using Common Data Service with canvas and model apps

As mentioned in Chapter 1, “Describe the business value of Power Platform,” Power Apps supports two basic app types for internal users: canvas and model apps. (A third type, portal apps, is intended to create websites for external users.)

Canvas apps are relatively simple and give the developer a great deal of control over the user experience the app provides. Power Apps offers canvas apps with standard functions such as read, write, search, and delete based on the structure of the data used by the app. Developers can use Power Platform connectors to access data sources directly, or they can use Common Data Service. It is possible to create more complex canvas apps, but the configuration process can become time-consuming for the developer.

Model apps are typically more complex than canvas apps, and they always use Common Data Service as a data source. Model apps also have less flexibility as far as the user experience is concerned; they use the Dynamics 365 framework. After the developer has created the data model, Power Apps generates a user interface that is appropriate for it. In fact, some of the Dynamics 365 Customer Engagement modules are essentially model-driven Power Apps. This makes it easier for developers to create more complex apps than it would be to manually create them from a blank canvas.

Describe entities, fields, and relationships

Common Data Service is a cloud-based data storage solution, which means it is available to any users with internet access and appropriate credentials. As with most of Microsoft’s cloud-based products, Common Data Service uses Azure Active Directory (AAD) for user authentication and authorization. Organizations that are Microsoft 365 subscribers can use their same user accounts to access Common Data Service data; Dynamics 365 subscribers are already accessing their Common Data Service data with their AAD user accounts.

Power Platform developers can create multiple Common Data Service database instances to accommodate the needs of various apps and users. Each database instance can support up to 4 terabytes of storage; additional storage is also available for purchase.

Using entities

When a developer creates a database instance in Common Data Service, it consists of a standard set of entities, with each entity having a standard set of fields. An entity is the Common Data Service equivalent of a table in other database management systems. A default Common Data Service instance has a base set of standard entities, as shown in Figure 2-2, any of which the developer can select and populate with data from an outside source.

In addition to the standard entities created with every Common Data Service instance, developers can create custom entities to suit the requirements of specific business applications, assuming that none of the standard entities are suitable. It is possible to rename a standard entity if that makes it more suitable to the application that will use it.

Creating a custom entity is simply a matter of clicking the +New entity button on the Entities screen in the Power Apps portal to open the dialog box shown in Figure 2-3, and supplying a name for the entity. After expanding the More settings header, the developer can specify the entity type and the ownership option. After the developer has created the new entity in the Power Apps portal, they can create custom fields within it.

Aside from the Standard entity type, the developer can also choose the Activity entity type, which is an entity that can manage tasks for which it is possible to create a calendar entry, such as appointments, phone calls, faxes, and emails.

The other option for the Standard entity type is its ownership, which has the following options:

• ■ User or team—Actions that developers can perform on this entity’s records are controlled at the user level. User or team ownership is the only possible option for Activity entities.

• ■ Organization—Access to the data stored in the entity is controlled at the organization level.

Using fields

Fields are the attributes within an entity that contain specific types of data. If an entity is the equivalent of a table, then a field is the equivalent of a column in the table, which contains a particular data point for each record, represented by a row in the table. For example, every entity has an Address field by default, which is configured with a data type called Multiline Text, indicating that every value for that field can consist of one or more lines of plain text. Other fields might have data types such as Whole Number, Date and Time, or Phone.

Just as a standard set of entities exists in every database instance, a standard set of fields exists in every entity, as shown in Figure 2-4. Depending on the entity, there can be just a few standard fields or over a hundred.

Developers can often use the standard fields for most purposes, but when they cannot, it is possible to create customized fields. Clicking the +Add field button on an entity page in the Power Apps portal opens the Field properties dialog box, as shown in Figure 2-5.

Understanding relationships

Depending on the nature of the app a developer is creating and the data that it will use, it might be a good idea to create multiple entities to hold different types of data, rather than store many different data types in a single entity.

For example, in the case of an order entry app, the developer might need to maintain a list of incoming invoices and a list of the products ordered on each invoice. The database for this app would therefore need—at minimum—records for the invoices and records for the products ordered. There would presumably also need to be records for customer information and records for an inventory of products. Storing all of this information in a single entity (or table) would be complicated at best.

To better organize the data for the app, it would therefore be preferable to create multiple entities and establish relationships between them. If the developer creates separate entities for the invoices and the products ordered, there could be said to be a one-to-many (also called a parent/child or 1:N) relationship between the two entities. The invoice entity would be the one (or the parent), and the products entity could contain as many product records (or children) as are needed for each invoice.

In the same way, the invoice entity can have a many-to-one (N:1) relationship to an entity containing customer information. Each customer can have many invoices, but each invoice is associated with only one customer. This type of entity relationship appears as a field type called a lookup field.

Common Data Service also supports many-to-many (or N:N) relationships between entities, in which many records in one entity are associated with many records in another entity, in what are known as peer relationships.

As mentioned earlier, the standard entities provided by Common Data Service are sufficient for the needs of most developers and their apps, and the relationships between the entities are already in place. Selecting any entity in the Power Apps portal and selecting the Relationships tab displays the existing relationships and their types, as shown in Figure 2-6.

From this screen, it is also possible for developers to create new relationships by clicking the +Add relationship button and choosing Many-to-one, One-to-many, or Many-to-many, to open a dialog box like the one shown in Figure 2-7.

Describe use cases for solutions

One of the basic design principles of the Common Data Service is the ability to customize the database to suit specific applications. The extensions that developers create, package, and deploy to the Common Data Service are called solutions. A solution consists of all the customizations made to the Common Data Service, including any modifications that developers might make to an existing solution. The entire solution is packaged as a single file that developers can distribute and import into other environments.

Solutions can contain a variety of components generated by the Power Platform tools, including Power Apps canvas apps and model-driven apps, Power Automate flows, custom connectors, and Common Data Service entities. However, solutions do not contain any business data.

Developers can create two types of solutions, as follows:

• ■ Unmanaged—Intended for development environments in which modifications are being made to the solution. Developers can export an unmanaged solution as either a managed or unmanaged solution. After a developer imports an unmanaged solution, deleting the solution causes the solution file to be deleted, but the customizations applied to the environment remain in place.

• ■ Managed—Intended for nondevelopment situations, such as test and production environments. Developers cannot export a managed solution or edit the components in a managed solution directly; they must first add the components to an unmanaged solution, which is editable. Deleting a managed solution causes all of the customizations included in the solution to be removed from the environment.

The typical progression is for developers to create and refine an unmanaged solution in a development environment and then export it as a managed solution for deployment in a test environment and later a production environment, as shown in Figure 2-8.

To create a solution, a developer clicks the New solution button on the Solutions page in the Power Apps portal to open the dialog box shown in Figure 2-9. After the solution is created, the developer can then create components or add existing ones. Developers can employ solutions in a variety of use cases, including application lifecycle management and business process flows.

Describe application lifecycle management

Application lifecycle management (ALM) is a cyclical paradigm for the development, governance, and maintenance of applications, as illustrated in Figure 2-10. Power Platform supports an ALM strategy that uses Power Apps, Power Automate, and Common Data Service components packaged as a solution.

By packaging the components of an ALM strategy as a solution, administrators can import them into the Common Data Service in other environments. This allows developers in those other environments to access the ALM components when developing their own apps and flows.

Describe business process flows

Business process flows are tools that allow administrators to ensure that users follow specific procedures when performing certain tasks. For example, order entry operators working in a call center might use a business process flow to ensure that they gather all the necessary information from the caller and record it in the correct places.

A business process flow organizes a task by breaking it down into a series of stages, with each stage consisting of multiple steps. When a developer creates a new business process flow, a working canvas appears like that shown in Figure 2-11. The stages run horizontally across the canvas and the steps vertically beneath each stage. The developer can drag and drop flow elements from the Components list in the right pane onto the canvas at any appropriate location.

When users run a business process flow, they see an interface like that shown in Figure 2-12, in which the flow leads them through its stages, providing text boxes and drop-down lists in which they can supply the necessary data. The developer can configure the flow to not permit users to proceed to the next stage until they have completed the present one. This ensures that all the required elements of the business process are completed.

Business process flows, by themselves, do not provide any advanced intelligence. They are designed to guide users through a series of tasks—typically involving data entry—and bring them to a specific outcome, such as the completion of an order entry or a customer interaction.

However, it is possible for developers to use business process flows to apply data supplied by users to forms that initiate automation using business rules, Common Data Service workflows, and form scripts. Business process flows can trigger server events based on the data supplied by the user, such as the generation of email messages.

On the client side, user input can trigger the appearance or disappearance of fields, automatic movement to the next stage of the flow, or a shift to a different flow altogether. For example, when a user indicates in an order entry flow that a customer requires a product installation, the focus can shift to a scheduling flow. After the scheduling of the installation is complete, the focus can shift back to the order entry flow for completion.

There are limits to the size and complexity of business process flows, including the following:

• ■ A business process flow can have no more than 30 stages.

• ■ A single entity can have no more than 10 business process flows activated at one time.

• ■ A single business process flow can involve no more than five entities.

Describe use cases and limitations of business rules

Business rules enable developers to implement logic on data stored in Common Data Service. Because the rules apply to the data, and not to a specific app, they take effect however the data is used. For example, if the value of the Country field in an entity is entered as Canada, a business rule can enable a six-digit alphanumeric Postal Code field and hide the five-digit numeric Zip Code field used for U.S. addresses.

Business rules consist of conditions and actions. Conditions are circumstances that must be met for the rule to apply, and actions are the procedures taken when the circumstances of the condition are met. When a developer selects an entity in the Power Apps portal, selects the Business Rules tab, and clicks Add business rule, a New business rule canvas appears, as shown in Figure 2-13.

As with a business process flow, developers can drag elements from the Components pane to the canvas. Selecting an element on the canvas causes the Properties interface for that element to appear in the right pane. The combination of conditions and actions creates an IF/THEN logic statement that appears in the Business Rule (Text View) box on the canvas.

For a condition, the developer configures one or more rules specifying when the actions should occur. In the figure, the condition calls for the Country field to have the value Canada. When that condition is met, the specified actions occur. The developer can then create actions that cause the U.S. Zip Code field to be hidden and the Canadian-format Postal Code field to be shown.

Conditions can be more complex, with multiple rules that use Boolean and/or operators to specify whether both conditions must be met for the actions to apply or either one of the conditions. The rule can also include multiple actions that execute when the condition is met.

The most common functions of business rules are to simplify the process of supplying data for users and verify the accuracy of the data that users supply. To that end, developers can create rules that set values for fields, clear the values from fields, and validate the data entered into fields. In model-driven apps (only), business rules can also show, hide, enable, and disable fields. For example, when users are required to supply their annual income in a field, a rule can enable additional fields for verification if the income exceeds a specified amount.

Describe the Common Data Model (CDM)

As discussed earlier in this chapter, Common Data Service can function as a database for the Power Platform tools, as well as for Dynamics 365. While Common Data Model sounds similar to Common Data Service, it is not the same thing.

CDM is not a database manager or any sort of data storage technology. Instead, the Common Data Model (CDM) is a Microsoft initiative that defines a shared data language, consisting of a unified system of schemas and metadata. The objective behind CDM is to create a standardized format for data sharing and storage that allows applications and services to share data without the need for custom implementations.

It is common for organizations to have many applications for different purposes, each of which includes its own database. In some cases, users maintain their own databases that are not linked to an application, such as a salesperson’s Excel spreadsheet containing contacts and leads. Problems arise when there is a need to share or transfer data between these many databases. Each share or transfer requires a separate procedure to ensure that individual data points are saved to the correct locations.

As a shared data model, CDM provides a consistent format for data storage. When all of the organization’s databases are based on the flexible CDM format, then the applications can share or transfer data freely without any special formatting considerations.

The primary components of the CDM are a metadata system that provides the means to define data types and a continually updated set of standardized data schemas that define commonly used types of business data. The schemas include predefined entities and attributes for many of the data types that organizations use, including sales, service, and finance, as shown in Figure 2-14.

Many of Microsoft’s applications and services store their information in databases that conform to the CDM standard, including the Common Data Service, as used in Dynamics 365 and Power Platform; dataflows in Power BI and Power Apps; Graph data connect in Office 365; and Azure Synapse. All these applications and services use CDM as their native metadata structure and can freely share the data they store in CDM-based storage technologies. Many other software developers and vendors use the CDM format as the basis for their products as well.

These applications and services store their CDM-formatted data in Azure Data Lake Storage in folders that conform to the standard CDM metadata structures. Folders that contain the following files are Common Data Model folders:

• ■ model.json

• ■ .cdm.json

• ■ *.manifest.cdm.json

Describe how to use common standard entities to describe people, places, and things

As mentioned earlier in this chapter, creating an instance of Common Data Service in an environment automatically populates the database with a collection of standard entities that are based on the Common Data Model and designed to support the most commonly used types of business data, including the following:

• ■ Account

• ■ Address

• ■ Appointment

• ■ Attachment

• ■ Business Unit

• ■ Contact

• ■ Currency

• ■ Email

• ■ Feedback

• ■ Letter

• ■ Mailbox

• ■ Organization

• ■ Phone call

• ■ Position

• ■ Task

• ■ Team

• ■ User

These entities represent people, places, and things, elements that many businesses use on a daily basis when communicating both internally and outside the organization. Each entity includes fields appropriate to its subject, as shown in Figure 2-15. The standard entities are all customizable also, making it possible for developers to add new fields or modify existing ones as needed.