Identify the core components of Microsoft 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 Microsoft Dataverse 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:

• Skill 2.1: Describe Microsoft Dataverse

• Skill 2.2: Describe connectors

Skill 2.1: Describe Microsoft Dataverse

Microsoft Dataverse 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 Microsoft Dataverse 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 F0rules when creating new content in Power BI, Power Apps, and Power Automate.

Introduce Microsoft Dataverse

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 Microsoft Dataverse

Depending on the nature of the app they are building, it is common for developers 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. Microsoft Dataverse 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 Microsoft Dataverse 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 Microsoft Dataverse can be more convenient than connecting to each one repeatedly every time an app is revised or updated. When importing data into Microsoft Dataverse, 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, Microsoft Dataverse can synchronize with the data sources at regular intervals to keep the stored data updated. The apps that use the Microsoft Dataverse data can then be updated with the latest information as well.

Using Microsoft Dataverse with canvas and model apps

As mentioned in Chapter 1, “Describe the business value of Microsoft 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 Microsoft Dataverse. 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 Microsoft Dataverse 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 the difference between databases and Dataverse

Microsoft Dataverse is frequently referred to as a database, in documentation and even in this book, but it is actually much more than that. Dataverse is often compared with SQL Server, as though the two are equivalents, but while the actual databases the two products create are similar in structure, Dataverse is fully integrated into Microsoft’s cloud infrastructure. Hosted by Microsoft Azure, Dataverse utilizes many of Azure’s services, not just to store data but also to provide data modeling, security, and integration with Microsoft 365 services. To implement in SQL Server what Microsoft Dataverse includes as standard features would require a substantial integration and development effort.

Figure 2-2 illustrates the many capabilities that Microsoft Dataverse provides to Power Platform developers and consumers.

The diagram divides the Dataverse capabilities into five categories, as follows:

• Security—Azure Active Directory (AD) provides identity services, including authentication, authorization, and accounting, for Microsoft Dataverse and all of the Power Platform tools.

• Logic—Dataverse can apply business logic at the data level so that the rules are enforced no matter how users and apps are accessing the data.

• Data—Dataverse and Power Platform provide data modeling, transformation, and reporting tools, enabling users to alter the presentation of the data as needed.

• Storage—All Dataverse data is stored in the Azure cloud, with all of the security, protection, and fault tolerance that entails.

• Integration—Dataverse is integrated with the Microsoft 365 services hosted by Azure, including Office, SharePoint, Exchange, and OneDrive.

While SQL Server and other database management products might provide some of these services to a degree, none of them can provide the same capabilities as Microsoft Dataverse “out of the box.”

Describe the differences between Dataverse and Dataverse for Teams

When a user creates an app or flow within Microsoft Teams for the first time or installs an app from the app catalog, Teams creates a Dataverse for Teams environment to support it. Dataverse for Teams is a separate implementation of Microsoft Dataverse that performs the same basic functions for that particular team as the Dataverse does for a Power Platform environment. Dataverse for Teams stores the team’s data, apps, flows, and bots and makes them available to other team members. Dataverse for Teams is provided with most of the Microsoft 365 licenses that include Microsoft Teams

The environment that Microsoft Teams creates appears on the Environments page in the Power Platform admin center, as shown in Figure 2-3, with Microsoft Teams listed as its type. However, the apps and flows that users create in Teams do not appear in the Power Apps portal or the Power Apps mobile app.

The apps and flows stored in a Dataverse for Teams environment are accessible to team members using links from within Teams or, when outside of Teams, through a web browser, as long as the user has a standalone Power Apps license. Team members can also invite guests and provide them with the ability to discover and run the apps, flows, and bots in the Database for Teams environment. However, the guests cannot create or modify apps and flows.

The Dataverse for Teams environment has no application programming interface (API) access and is available only to apps, flows, and bots within that environment. Storage is limited to 2 gigabytes per team, with up to one million table rows. The license supports up to five teams, with one additional team for every 20 licenses purchased.

If API access is needed, or if the environment’s storage limit is reached, or if users need to access the apps, flows, and bots using the standalone Power Platform tools, it is possible for a tenant admin to upgrade the Dataverse for Teams environment to a standard Microsoft Dataverse environment using the Power Platform admin center portal.

Describe tables, columns, and relationships

Microsoft Dataverse 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, Microsoft Dataverse uses Azure Active Directory (AAD) for user authentication and authorization. Organizations that are Microsoft 365 subscribers can use their same user accounts to access Microsoft Dataverse data; Dynamics 365 subscribers are already accessing their Microsoft Dataverse data with their AAD user accounts.

Power Platform developers can create multiple Dataverse 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 tables

When a developer creates a database instance in Microsoft Dataverse, it consists of a standard set of tables, with each table having a standard set of columns. A default Microsoft Dataverse instance has a base set of standard tables, some of which are shown in Figure 2-4, any of which the developer can select and populate with data from an outside source.

In addition to the standard tables created with every Microsoft Dataverse instance, developers can create custom tables to suit the requirements of specific business applications, assuming that none of the standard ones are suitable. It is possible to rename a standard table if that makes it more suitable to the application that will use it.

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

Aside from the Standard table type, the developer can also choose the Activity table type, which is a table 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 table type is its ownership, which has the following options:

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

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

Using columns

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

Just as a standard set of tables exists in every database instance, a standard set of columns exists in every table, as shown in Figure 2-6. Depending on the table, there can be just a few standard columns or over a hundred.

Developers can often use the standard columns for most purposes, but when they cannot, it is possible to create customized columns. Clicking the +Add column button on a table page in the Power Apps portal opens the Column properties dialog box, as shown in Figure 2-7.

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 tables to hold different types of data, rather than store many different data types in a single table.

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 table would be complicated at best.

To better organize the data for the app, it would therefore be preferable to create multiple tables and establish relationships between them. If the developer creates separate tables 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 tables. The invoice table would be the one (or the parent), and the products table could contain as many product records (or children) as are needed for each invoice.

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

Microsoft Dataverse also supports many-to-many (or N:N) relationships between tables, in which many records in one table are associated with many records in another table, in what are known as peer relationships.

As mentioned earlier, the standard tables provided by Microsoft Dataverse are sufficient for the needs of most developers and their apps, and the relationships between the tables are already in place. Selecting any table in the Power Apps portal and selecting the Relationships tab displays the existing relationships and their types, as shown in Figure 2-8.

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-9.

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

As mentioned earlier in this chapter, creating a Microsoft Dataverse instance in an environment automatically populates the database with a collection of standard tables that are 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 tables represent people, places, and things, elements that many businesses use on a daily basis when communicating both internally and outside the organization. Each table includes columns appropriate to its subject, as shown in Figure 2-10. The standard tables are all customizable, making it possible for developers to add new columns or modify existing ones as needed.

Describe business logic uses, including business rules, real-time workflows, and actions

Power Apps provides several mechanisms that developers can use to implement business logic in their apps, including business rules, workflows, and actions. These mechanisms are described in the following sections.

Business rules

Business rules enable developers to implement business logic on data stored in the Microsoft Dataverse. 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 a table 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 US 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 opens a table in the Power Apps portal and selects New > Business Rule, a New business rule canvas appears, as shown in Figure 2-11.

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 US 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, or either one of the conditions, must be met for the actions to apply. 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.

Real-time workflows

Real-time workflows are a means of automating repetitive processes on tables that do not require user interaction. Workflows, like business processes, are organized into stages, each of which has a series of steps. The steps can cause the workflow to create, update, and assign table rows, as well as launch other workflows. Another type of workflow, the background workflow, is run by Power Automate.

Actions

Actions, also known as custom actions or custom process actions, are similar to real-time workflows in that they are divided into stages and steps and consist of conditions and actions. Custom actions expand the native capabilities of Power Platform by creating custom messages. Power Apps has built-in messages that use verbs such as Create, Update, and Delete. With custom actions, users can create additional messages that consist of multiple steps, resulting in new verbs, such as Approve, Escalate, or Convert.

Describe dataflows and their uses

Dataflows are Power Apps features that enable developers to gather data from multiple sources, combine and transform the data, and store it in a table, either in the Microsoft Dataverse or in Azure Data Lake Storage. Once stored, the data is accessible to Power Apps apps and refreshed according to a schedule specified by the developer. Other developers in the organization can then make use of the dataflow with assurance that it is up to date and organized into a useful form.

Describe solutions and their purpose

One of the basic design principles of the Microsoft Dataverse is the ability to customize the database to suit specific applications. The extensions that developers create, package, and deploy to the Dataverse are called solutions. A solution consists of all the customizations made to the Dataverse, 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 Dataverse tables. 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-12.

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-13. 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.