2. Working with Microsoft Dataverse

Understanding Power Apps Solutions

Solutions are a great way to package configuration items and customization components to distribute to upstream environments. This ensures Application Lifecycle Management (ALM) for solution components in Power Apps. For example, if you want to develop a custom application and have the same application in other environments or if you want to share your app with source configurations, you can package all the components into a Power Apps solution. Then you can export them from the source environment and import them into the target environment.

Solutions can be exported from one environment and imported into any environment, but you should make sure the required components exist in the target environment. Figure 2-1 shows the solutions components.

Versions in Solution

Versions are important parts of solutions; they define which features are available in which version. The version format of a solution is comprised of four parts—Major, Minor, Build, and Release. In a general way, when you create a solution for a Major release, you increment the first digit; for Minor changes to an existing Major release, you increment the second digit; to prepare builds for a Minor release, you update the third digit; and for any hot fixes or if there are multiple releases to the same build, you update the last digit. The typical version format is shown in Figure 2-2.

Create a New Solution

To create a new solution, you have to navigate to make.powerapps.com and provide the credentials. You will be directed to the Power Apps home page. Choose the environment you want to use to create the solution.

Click the Solutions option from the left navigation, which will display all the solutions that are part of the current environment. Now click the +New Solution command, which will open the New Solution Creation side panel. Figure 2-3 shows a solutions list and how to create a new solution.

Figure 2-3
Solutions view and creating a new solution

Provide a Display name; the Name will be auto-populated. For Publisher, you can choose the default, but this example creates a new publisher by clicking the +New Publisher option. Figure 2-4 shows the solution information.

Figure 2-4
Solution details and information

In the New Publisher panel, provide the Publisher Display Name, the Name without a space, a Description, and a prefix that’s a maximum of eight characters. Click Save.

Every solution requires a publisher to be associated with it. The publisher indicates who developed the app. For this reason, you should create a solution publisher that is meaningful and reflects the ownership of the solution. You can select the default publisher, but it is recommended that you create your own publisher to keep the components consistent in the app. Refer to the Microsoft site to understand the publisher creation process at https://docs.microsoft.com/en-us/power-apps/maker/data-platform/create-solution#create-a-solution-publisher. Figure 2-5 shows the publisher creation panel.

In the Contact tab of the Publisher panel, you can add the contact information of the owner or developer. The prefix is useful to generate the component’s unique name. For example, if you add a table called Student to the solution with this publisher, then the unique name of the component will be school_Student. Once the publisher is saved, you can choose the publisher from the Select a Publisher dropdown. Keep the initial version set to 1.0.0.0. Click Create. Now you will see that the new solution is created and is listed in the Solutions view, as shown in Figure 2-6.

You have successfully created a solution in Power Apps. Solutions that are freshly created are unmanaged by default. You can add components to the solution now.

Solutions are categorized into three types—Default, Unmanaged, and Managed solution—as explained in Table 2-1.

Table 2-1

The Solution Types

Solution Type	Details
Default	This is a special solution that contains all components in the system of the current environment. The default solution is useful for finding all the components and configurations in your system. Default solutions cannot be exported.
Unmanaged	Solutions that are in the development stage. With unmanaged solutions, you can add, remove, and delete components.
Managed	When an unmanaged solution is completed with the development activities and is ready for production or distribution, you can export the unmanaged solution as a managed solution by specifying the managed properties. You cannot edit components inside managed solutions unless the managed property is enabled. It is recommended that export solutions are always managed.

Managed Properties

Managed properties can be used to control which of your managed solution components are customizable in a managed solution. To set a managed property, open the unmanaged solution and, from the list of the components, click the three vertical dots next to the component and choose Managed Properties. Figure 2-7 shows the Managed Properties option.

The Managed Properties panel will open, where you can enable/disable the customization options. Remember that the properties will take effect only after the component is exported and imported as part of the managed solution. Figure 2-8 shows the Managed Properties option list.

Figure 2-8
The Managed Properties option lists

Publish the Solution

Every time you update a solution component, you need to publish the solution so that the changes will be reflected; otherwise, the changes will be just saved, not published.

Solution Patches

A solution patch contains changes or updates to the parent solution, such as adding or editing components. You are not required to add parent solution components to the patch unless you want to edit the component. Solution patches are useful for hotfixes and small changes to existing components of a parent solution.

Solution patches let you choose a new build or release version. You cannot change the Major or Minor version of the parent solution. Figure 2-9 shows some solution patches.

When you clone a patch, the parent solution becomes read-only. You cannot change any components inside the parent directly; rather, you have to work on the patches. Once you are ready for a major upgrade, you can create a clone of the parent solution, which will roll up all patches and create a new major version of the previous parent solution with all the components.

You can use a patch when you want to move a small number of solution component changes from the source to the target environment that’s part of the parent solution. Patches are also used when you want to delete a component from the target environment.

Cloning Solutions

When you clone an unmanaged solution, the original solution and all the patches of the solution are rolled up into a newly created version of the original solution. After you clone, the new solution version contains the original entities plus any components or tables that were added in the patch.

Solution cloning can be used to create a Major or Minor version of an existing solution. Figure 2-10 shows a solution that initially has three patches. When it was cloned, all the patches with the parent solution rolled up to create a new solution clone with a new Major version. After the clone, there is a patch for the newly created, cloned solution. This example also cloned the clone, which creates a new, cloned solution by rolling up all the previous patches and parent solutions.

Export and Import Solutions

Solutions can be exported from a source environment as a managed or unmanaged solution and imported into a target environment. When you import a managed solution into a target environment where an older version of the same solution is imported, you have more options to choose when importing the managed solution.

As a best practice, you should export solutions as managed solutions so that when you import them, they can be rolled back. Unmanaged solutions cannot be rolled back.

Managed solutions are imported and stacked in multiple layers in the target environment. If you uninstall a managed solution, the changes will affect the solution below the uninstalled layer. Read more about solution layers at https://docs.microsoft.com/en-us/power-apps/maker/data-platform/solution-layers.

You can choose the Upgrade, Stage for Upgrade, and Update options when importing managed solutions.

Upgrade

Upgrade is the default option. It upgrades your solution to the latest version and rolls up all the previous patches in a single step. Any solution components associated with the previous solution version that are not in the newer solution version will be deleted in the target environment. This is the recommended option, as it will ensure that your resulting configuration state is consistent with the importing solution, including removing components that are no longer part of the solution.

Stage for Upgrade

This option upgrades your solution to the higher solution version, but does not delete the previous version and any related patches until you apply a solution upgrade. This option should only be selected if you want to have the old and new solutions installed in the system concurrently, perhaps so that you can do some data migration before you complete the solution upgrade. Applying the upgrade will delete the old solution and any components that are not included in the new solution.

Update

This option replaces your solution with the latest version. Components that are not in the newer solution won't be deleted and will remain in the system. This option is not recommended, as your destination environment will differ in configuration from your source environment, which could cause issues that are difficult to reproduce and diagnose. When updating, you can choose from these options:

Maintain customizations (recommended): Selecting this option will maintain any unmanaged customizations performed on components but also implies that some of the updates included in this solution will not take effect.
Overwrite customizations: Selecting this option overwrites any unmanaged customizations previously performed on components included in this solution. All updates included in this solution will take effect. Figure 2-11 shows the options while importing an existing managed solution.

Working with Table Configurations and Settings

In the previous section, you learned how to create solutions in Power Apps. In this section, you see how to configure tables in the Dataverse. In the Dataverse, tables are used to store data. For example, you can create a table to store student data.

Table Types

Tables are classified into three categories—Standard, Activity, and Virtual. Standard tables are best when you want to store transactional or master data. For example, Student, Professor, Time Sheet, Loans and so on, can be considered standard tables. Activity tables represent activities. For example, Letter, Email, Appointment, Booking, and so on. They require a timestamp to complete the activity. All activity type tables have date and time related columns, such as Due Date, Start Time, End Time, and so on.

Virtual tables are special tables that you can create for integration purposes. They are also known as virtual entities and they enable the integration of data residing in external systems by seamlessly representing that data as tables in the Microsoft Dataverse, without replicating the data and often without custom coding. Virtual tables replace previous client-side and server-side approaches to integrating external data. These old approaches required customized code and suffered from numerous limitations, including imperfect integration, data duplication, and extensive commitment of development resources. In addition, for administrators and system customizers, the use of virtual tables greatly simplifies administration and configuration. Read more about virtual tables from Microsoft at https://docs.microsoft.com/en-us/power-apps/developer/data-platform/virtual-entities/get-started-ve.

Record Ownership

While creating tables, you need to determine whether the table will store organization owned data or user/team owned data. If you think that the records require a proper user/team level security, choose user/team owned; otherwise, choose organization owned. For example, tables such as Article, Article Template, Competitor, Currency, and Web Resource are organization owned. Tables like Account and Contacts are user/team owned because these records are owned by a user or team. They’re connected to a business unit and have specific security roles for the business unit. Therefore, these entities participate in role-based security.

Table Configurations

Tables are used to model and manage business data. When you develop an app, you can use standard tables, custom tables, or both. The Dataverse provides standard tables by default. These are designed, in accordance with best practices, to capture the most common concepts and scenarios in an organization. While configuring tables you can enable/disable many features, such as apply duplicate detection rules and enable them to create activity.

A table defines information that you want to track in the form of records, which typically include properties such as company name, location, products, email, and phone.

Types of Tables

Tables appear in Power Apps as one of three different types, which indicate how the table came into the environment, whether the table is managed or unmanaged, and whether it can be customized.

Standard: Several standard tables, also known as out-of-box tables, are included with the Dataverse environment. Account, business unit, contact, task, and user tables are examples of standard tables in the Dataverse. Most of the standard tables included with the Dataverse can be customized. Tables that are imported as part of a managed solution and set as customizable also appear as standard tables. Any user with appropriate privileges can customize these tables, where the table property has customizable set to true.
Managed: Tables that aren’t customizable and have been imported into the environment as part of a managed solution.
Custom: Unmanaged tables that are either imported from an unmanaged solution or are new tables created directly in the Dataverse environment. Any user with appropriate privileges can fully customize these tables.

Create a New Table

You can now create a new table to store student information. Open the solution you created in the previous section. Choose the +New option and then choose Table. Figure 2-12 shows how to add a table inside a solution.

The new table creation side panel will open, where you can provide table information. This chapter builds a school management system, so you see how to design the tables based on these requirements.

Requirements

This school management system must allow users to enter student information such as roll number (auto-number), name, address, father’s name, mobile, email, and qualification. The system should capture course information and the users should be able to record students joined for courses. The app must create payment information with term facility and payment details.

Add a new table with Display Name set to Student (the plural name is automatically populated as Students). Provide a description for the table, such as “Stores student information”. If you want to enable features, click the Advanced options. Choose Type as Standard and Record Ownership as User/Team.

Every component has three names—Display Name (to display on the screen), Schema Name (used for web API calls client-side), and Logical Name (used in server-side code calls). Figure 2-13 shows the table configuration.

In this case, the Student table has three names—Display Name: Student, Schema Name: school_Student, and Logical Name: school_student.

In the Primary column section, define the Display Name, which will be treated as the default column to identify the record. For the Student table, the Name will identify the student name. Figure 2-14 shows the primary field configuration of this table.

Figure 2-14
Primary field of table configuration

After providing these details, save the Student table. The table will be listed under the component list of the solution.

For any table, you can configure Columns, Relationships, Business Rules, Views, Forms, Dashboards, Charts, Keys, Commands, and Manage Data. You learn more about these options in upcoming sections of this chapter.

Working with Columns, Datatypes, Calculated Fields, and Rollup Fields

Click the table to open the table component to add or edit the columns. Columns are fields that store information about the student, such as roll number (auto-number), name, address, father’s name, mobile, email, and qualifications.

System Columns vs. Custom Columns

Every time you create a new table, the system creates system columns that are used by the system, such as createdon, modifiedon, and so on. These field values are updated by the system. Figure 2-15 shows system columns that are automatically created when you create a standard table.

You can add custom columns as per your business needs. The custom fields can be identified by their Name, which is specified with the publisher prefix. The primary key is represented as <prefix>_<tablename>id, which is a 32-bit digit called a unique identifier. It behaves as a primary key of records.

Datatypes

Datatypes define the type of value the column will hold. For example, if you want to store the name of a person, you can use a single line of text as the datatype. Figure 2-16 shows the datatypes of columns in the Dataverse.

Calculated Fields

Calculated fields are the fields for which values can be automatically calculated using conditions and formula in design time. These values will be automatically assigned to the field once certain conditions are satisfied. For example, if you want to store the next renewal date of a student automatically after the student is created, you can use the Feature Calculated field to auto-calculate the renewal due date and store that value. You don’t have to write any custom code,

Read more about calculated columns and their configurations at https://docs.microsoft.com/en-us/power-apps/maker/data-platform/define-calculated-fields.

Rollup Fields

A rollup field contains an aggregate value that’s computed over the records related to a specific record, such as unpaid payments. You can also aggregate data from activities directly related to a record, such as emails and appointments, and activities indirectly related to a record via the Activity Party entity. In more complex scenarios, you can aggregate data over a hierarchy of records. As an administrator or customizer, you can define rollup fields by using the feature, all without needing a developer to write code.

Read more about rollup fields and their configuration at https://docs.microsoft.com/en-us/power-apps/maker/data-platform/define-rollup-fields.

Configure the following columns for the Student table with the corresponding datatypes listed in the table.

Column Name	Datatype
Address	Multiline text
Father Name	Text
Mobile	Phone
Email	Email
Gender	Choice (Male, Female, Other)
Qualification	Choices (MCA, MBA)

Click the +Add Column option to create these columns. Set the Required option to Optional, Required, or Business Recommended, as needed. If the business need is to require a mobile number, choose Required here. If a field value is not mandatory, it can be defined as Business Recommended. That way, a plus sign appears next to the field, indicating it’s recommended. The system will not restrict record creation if you leave the field blank.

To add the Choice datatype field, you need to add items to choose the field by selecting the New Choice option. Every choice field has a Text value to display and a Value option to be used internally. You can change them if you want.

Read more about the Choice field configuration at https://docs.microsoft.com/en-us/learn/modules/working-with-option-sets/3-exercise.

Figure 2-17 shows how to add columns. Repeat this step to add all the new columns and finally save the table.

After adding all the columns, they will be listed in the Columns section of the solution component. Figure 2-18 shows the custom columns in the Student table.

Auto-Number Columns in the Dataverse

The auto-number field is a special type of datatype that’s very useful to generate sequential numbers without writing code. For example, you can generate a roll number for students in a sequential format, such as STD-0001, STD-0002, and so on. You can use a string prefixed number, a date prefixed number, or a custom prefix, depending on your needs. Add a new column with a datatype of Auto-Number and define the pattern as shown in Figure 2-19.

Figure 2-19
Roll Number column auto-number

Set Prefix to STD, Minimum Digits to 4, and Seed Value to 1000. The preview will display as STD-1000, STD-10001, and so on.

Save the column after configuration and then save the table. Now, whenever you create a student record, the roll number will be automatically generated.

Configuring Relationships and Relationship Behaviors

Relationships in the Dataverse are between two tables. For example, a student might have multiple payments, and one student can register for multiple courses. So, for such scenarios, you can associate two tables with a relationship.

There are three types of relationships in Power Apps—one to many (1:N), many to one (N:1), and many to many (N:N). The 1 is the parent and the N is the child.

Configure a new table called Student Payment with Payment ID, Amount, and Terms columns and build a 1:N relationship between Student and Student Payment.

Navigate to the solution and add a new table as you created the Student table. Add the following columns.

Column Name	Datatype
Payment ID	Auto Number
Amount	Currency
Term	Choice (1, 2, 3)

After the columns are added, the solution component for the Payment table will look like Figure 2-20.

Now add a relationship to the Student Payment table. The following diagram defines the relationship between Student and Student Payment.

A pair of tables. Table 1 titled students lists the roll number, full name, address, father name, mobile, email, qualification, and gender with their respective details on its right. Table 2 lists the payment id, student, amount, and terms with their respective details on its right. Tables are connected by arrows named 1 and N.

Navigate to the solution, open the Student Payment table, and select Relationship. Choose many-to-one. Figure 2-21 shows how to add a many-to-one relationship.

Figure 2-21
The many-to-one relationship

The relationship configuration panel will open. Select the Student as Related (One) option. A new lookup field will be created in the Student Payment table because of this relationship. Figure 2-22 shows the setup of the many-to-one relationship.

Figure 2-22
The many-to-one relationship setup

For every many-to-one relationship, a new lookup field will be created in the table, which represents the many; the lookup points to the table record, which represents the 1.

In this case, Student Payment represents the many, so a new lookup column is created called school_Student in the Student Payment table, which holds the student record.

Relationship Behavior

Relationship behavior defines how the parent records behave when you perform an operation such as delete, assign, share, and so on, on their child records.

There are three types of relationship behavior, as explained in the following table.

Type of Behavior	Datatype
Referential	Referential behavior has two actions: Delete - Remove Link: You can delete a parent record and the related child records remain in the system. The lookup field that holds the parent record association will be blank. Delete - Restrict: Any related records can be navigated to. Actions taken on the parent record will not be applied to the child record, but the parent record cannot be deleted while the child record exists.
Parental	Any action taken on a record of the parent table is also taken on the related child table records.
Custom	Custom behavior for each possible action can be selected. You can define custom cascade behavior for operations such as Share, Assign, Un-share, Reparent, or Delete. Cascade All: Any action taken on a record of the parent table is also cascaded to the related child table records. Cascade Active: Any action taken on a record of the parent table is cascaded to the related active child table records. Cascade User-Owned: Any action taken on a record of the parent table is cascaded to the related child table records owned by the current, logged in user. Cascade None: Actions taken on a record of the parent table will not cascade to the related child table records.

Type of Behavior

Datatype

Referential

Referential behavior has two actions:

Delete - Remove Link: You can delete a parent record and the related child records remain in the system. The lookup field that holds the parent record association will be blank.

Delete - Restrict: Any related records can be navigated to. Actions taken on the parent record will not be applied to the child record, but the parent record cannot be deleted while the child record exists.

Parental

Any action taken on a record of the parent table is also taken on the related child table records.

Custom

Custom behavior for each possible action can be selected.

You can define custom cascade behavior for operations such as Share, Assign, Un-share, Reparent, or Delete.

Cascade All: Any action taken on a record of the parent table is also cascaded to the related child table records.

Cascade Active: Any action taken on a record of the parent table is cascaded to the related active child table records.

Cascade User-Owned: Any action taken on a record of the parent table is cascaded to the related child table records owned by the current, logged in user.

Cascade None: Actions taken on a record of the parent table will not cascade to the related child table records.

For the current scenario, use the Referential relationship behavior and the Restrict Delete operation.

This way, you can configure the relationship behavior as one-to-many or many-to-one only. For a many-to-many relationship, this type of behavior is not applicable.

Design the other tables with the relationships shown in Figure 2-23, as per the datatype. You can keep the relationship behavior for other relationship set to Referential and the Delete operation set to Restrict Delete. Figure 2-23 shows the ER diagram overview.

For Professor and Courses, the relationship is many-to-many. Every many-to-many relationship creates an intersect table in the background, which is hidden to the users. You can choose the relationship name and relationship table. Figure 2-24 shows the many-to-many relationship setup.

Figure 2-24
The many-to-many relationship

You have now created all the tables and relationships for the school management system.

Working with Business Rules

Business rules are configuration components by which you can configure rules to validate fields without writing custom JavaScript codes. Using business rules, you can use conditions and perform the following actions.

Action	Explanation
Set Field Value	Use this action to set a value of a field.
Set Default Field Value	Use this action to set the default value of a field.
Lock/ Unlock Field	Use this action to make a field read-only or editable.
Set Business Required	Use this action to make a field mandatory or optional.
Set Visible	Use this action to hide or show a form field.
Recommendations	Use this action to recommend some action to the user.
Show Error Message	Use this action to display an error message.

Scope of Business Rules

There are three levels of scope when setting up business rules in your Microsoft Dynamics 365/CRM system. The scope controls when or in which scenario the business rules will be triggered.

Scopes	Explanation
Entity	This scope ensures that the business rule will work on the client-side and the server-side. The business rule will run when you interact with data using table forms and will be applicable when you are creating records using server-side code, like plugins.
All Forms	This scope will only applicable when you create records using table forms i.e., only on the client-side.
Specific Form	This scope will only applicable when you create records using a specific table form, not all forms.

You cannot use datatype fields in business rules. Business rules are table specific. So, to add a business rule, you have to open a table and select the Business Rule option.

Create a Business Rule

Navigate to the Student table and select the Business Rule option. Click the Add Business Rule button, which will open the Business Rule Designer window. Figure 2-25 shows the Business Rule Designer window, with options like Name, Description, Rule Canvas, Conditions, Actions, and Scope.

Business Requirement: Make the email field mandatory for all mail students.

Provide a Name, Description, and Scope as Entity and then click the condition box on the rule canvas to enable the property window.

In the property panel, choose Display Name for Condition and Entity as Student. In Rule 1, choose Source as Entity, Field as Gender, Operator as Equals, and Type as Value. In the Value field, select Male, as we will run the rule for male students only. Click Apply. Figure 2-26 shows the setup.

Figure 2-26
The business rule condition setup

Click the Components tab to drag the Set Business Required component and then tick part of the condition box. Configure the Display Name, Field as Email, and Status as Business Required properties. Apply these changes. Figure 2-27 shows the components attached to the condition.

Figure 2-27
The business rule components

In the negation part, drag the same Set Business Required component and choose Not Business Required for the status. Click Apply. Figure 2-28 shows actions on the positive and negative conditions.

Figure 2-28
The business rule components using the negation branch

Validate, save, and then activate the business rule to test this in action. Navigate to the solution and open the Student table. Choose the Data tab and click Add Record. This will open a student main form, where you can test the rule. In the form, provide the name of the student and choose male for gender. The email field will show an asterisk symbol, meaning the field is mandatory. Figure 2-29 shows the business rule testing scenario.

Figure 2-29
The business rule testing scenario

Now you can configure multiple business rules for tables, based on your business needs. Make sure to choose the correct scope for these business rules.

Configure Views for Tables

Views are a subset of a table’s records, defined by a filter condition. For example, you can create a view to display students joined this year as a view so that you do not need to build the query every time to fetch data. Instead, you can select the view and get the data. Views come in three types—system views, custom views, and user/personal views.

System and custom views are those views that you configure inside a solution; they are visible or accessible to any user in the organization. System views are by default created by a solution, but custom views are manually created inside a solution. Personal views are created by users and are visible only to the user who created them.

System views cannot be shared because they are available to all users. Personal views can be shared by users, as they are created by specific users. You can use Advance Find to create personal or user views.

There are different types of system views available in the system for a table. You can also create your own custom view for a table. System views are explained in the following table.

System View	Explanation
Active View	This view displays active records.
Inactive View	This view displays inactive records.
Quick Find Active View	This view displays records in the search option.
Advanced View	When you search records in Advanced Find, this view is used.
Associated View	This view is responsible for displaying records in a related table view.
Lookup View	This view is used when you search records in a lookup control.

For the Student table, the views in Figure 2-30 are created. You can also create custom views for any table inside a solution, which will be available to any user. Figure 2-30 shows the different views available in the Dataverse tables.

Create a Custom View

Create a custom view to display only male students. For this requirement, you simply navigate to the solution and open the Student table, select Views, and then click Add View.

Provide a name for the view with a description. Then click Create. Figure 2-31 shows how to create a view.

This will open the View Designer, where you can drag-and-drop columns and add filters. Add Roll Number, Name, and Email to the columns list. Figure 2-32 shows the columns to add to this view.

Click the Edit Filters option on the bottom-right side to open the Filter Editor panel. Add a new row and choose male for the gender. Click OK. Figure 2-33 shows the filter condition of these views.

You can also configure sorting on the view by clicking the Sort By option available on the right panel of the View Designer. Figure 2-34 shows how to sort columns to add a view as needed.

Once you have completed these steps, save and publish the view. You have successfully created a custom view. Now you can test it.

Open the table, go to the Data tab, and click the top-right corner view selector. You will see that the Male Students view is available. The view will display all students whose gender is male, sorted by roll number. Figure 2-35 shows the view selector in the Dataverse.

Table Forms Design and Layouts

Forms are user interface elements by which users can interact with datasource. You can use forms to create new records and update existing records.

There are four types of forms in Power Apps. They are explained in the following table.

Form	Explanation
Main Form	The default form that can be used to interact with table records.
Quick View Form	Can be configured to display parent record information inside the child record form.
Quick Create Form	Used to quickly create records of a table type with fewer data items. This form can be created if you have enabled the table setting for Quick Create form.
Card Form	Used to display information in a card format.

You will find these forms by default and you can edit them, per your business needs. Figure 2-36 shows the forms created for the Student table.

You can edit the form layouts as needed. The main form consists of three parts—header, body, and footer. Inside the body, you can add tabs, and inside tabs, you can add one or multiple column sections. Section can be used to hold one or multiple fields.

Form Security

Every form in the Dataverse is security-role driven. You can select access forms by all users or select a specific security role. For example, if you apply an account manager security role to a specific main form, then only the users having account manager security role can access it unless the form is not a fallback form. You will learn more about security roles in Chapter 8. Figure 2-37 shows the form security option.

Enable Fallback Form

You can enable security roles so that only users with a specific security role can access certain forms. When a security role is not enabled for a form, the form that has been enabled as the fallback form will load for those users. Figure 2-38 shows the fallback option.

Create New Forms

In addition to existing forms, you can create new forms of different types, such as main forms, quick view forms, quick create forms, and card forms. You can create multiple forms of the same type as needed. Form security can be applied as well. Figure 2-39 shows these new form types.

Edit Student Main Form

To edit the main form of the Student table, click the three dots next to the Information Main form and choose Edit Form in New Tab. Figure 2-40 shows this process.

The Form Designer will open. You can use the Components panel on the left to edit the form. Figure 2-41 shows the layout components.

By default, one tab and one column section are available on the form. You can drag-and-drop fields onto the section by using the Columns option. Figure 2-42 shows the form fields.

Once the fields are dropped onto the section, you can save and publish the form. Then users can use the form by providing field values. Figure 2-43 shows the New Student form.

Chart Configuration and Dashboard Pinning

A chart is a graphical representation of table data. Charts can make data interesting, attractive, and easy to read and evaluate, which can help you analyze and compare your data.

In Power Apps, you can create bar charts, pie charts, tabular data, and so on. You can connect to the Dataverse table to display data in graphical images.

Create a Chart

Open the solution, navigate to the Student table, and choose the Charts option. Click Add Chart. This will open the Chart Designer. Figure 2-44 shows the chart option.

Provide a name for your chart and choose the view to use for the chart. Choose Legend entries, which adds Series and Category as labels. Figure 2-45 shows the Chart Designer.

Figure 2-45
Student table chart designer

Choose Name with Aggregation, Count: All, and Gender for the horizontal axis. This scenario creates a chart to display students by gender. The preview of the chart will be displayed on the Designer Screen. Save the chart. The chart can be used in model-driven apps.

You can create multiple charts for a specific table with different scenarios, such as students by payment, top five students with highest payments, students by joined on date, and so on.

Dashboards

To display multiple charts on a single page, you can use dashboards. You can choose a layout like two-column or four-column dashboards. There are two types of dashboards—table-specific and global.

When you create a dashboard in a table, you can only use charts from the same table in the dashboard; these are called table-specific dashboards.

Create a Dashboard

Open the solution and navigate to the Student table to choose the Dashboard option. Click Add Dashboard and choose 2-Column Overview. This will open the Dashboard Designer. Figure 2-46 shows the Dashboard Designer.

Figure 2-46
Student table Dashboard Designer

The dashboard has multiple tiles in two columns, so you will see two tiles on the dashboard. You have to select visual filters to add charts and stream to choose a view that will be used to render the visual filters. Figure 2-47 shows the table dashboard designer tiles.

Figure 2-47
Student table dashboard designer tiles

Name the dashboard and then choose Entity View. You can choose any chart from the selected table by clicking the chart icon from the dashboard tile. After that, click the Stream to choose the view. Figure 2-48 shows the dashboard stream.

Figure 2-48
Student table dashboard stream

Save the dashboard. When designing model-driven apps, you can use this dashboard as an asset of the Student table. Figure 2-49 shows the final dashboard in action.

Figure 2-49
The rendered Student table dashboard

You can configure multiple dashboards for a single table to represent different strategic visual screens. Charts and dashboards can both be added in model-driven Power Apps as entity assets.

To configure global dashboards, you need to create model-driven Power Apps. Then you can add multiple charts, web resources, and insight tiles by connecting multiple tables on a single page.

Configure Table-Specific Dashboards

Dashboards configured inside a table are called table-specific dashboards. In these dashboards, you can only use the charts related to that table. You cannot use multiple tables in a table-specific dashboard.

For more information about dashboards, see the Microsoft site at https://docs.microsoft.com/en-us/power-apps/developer/model-driven-apps/create-dashboard.

Concepts of Alternate Keys

Alternate keys are useful for third-party system integrations. Power Apps store their primary keys in GUID format. However, third-party systems do not use GUID format, so for system integration, you have to configure an alternate key. This is done by combining multiple columns to uniquely represent a row or record. To add an alternate key, navigate to the table, choose Key, and click Add Key.

Name the key (for example, studentkey) and choose one or multiple columns to represent the unique key for third-party systems. When a third-party system tries to create a new record or update an existing one, this alternate key will be required. Figure 2-50 shows how to configure an alternate key.

The alternate key calls the UPSERT command in Power Apps. The UPSERT command will check the record to be inserted or updated, as per the key check.

Working with Data in the Dataverse

The Data option in tables can be used to import data or manually create records for that table. To create a new student, click the Data tab and then click Add Record, which will open the student main form. You then provide the student information and save the record. Figure 2-51 shows the main form of the Student table.

After the data is saved, you can see the data in the view area. Figure 2-52 shows the student records inside the Dataverse.

Business Scenario, Use Cases, and Implementation

In this chapter, you learned how to configure Dataverse tables, columns, relationships, business rules, views, forms, charts, dashboards, keys, and data options. You can perform the following scenarios with the skills explained in this chapter.

1	Systems should be able to combine different configuration and customization components in a package so that they can be distributed to other environments.	Configure Power Apps Solution and add required components to it for packaging.
2	The school management system must allow users to enter student information such as roll number (auto-number), name, address, father’s name, mobile, email, and qualifications. The system should capture course information and users should be able to record students joined. The app must create payment information with term facility and payment details.	Solution components include tables, fields, forms, views, and relationships.
3	The system should display student-level total amount to be paid by student and it should display the next renewal due date of the student after one year of joining.	The solution requires you to configure rollup fields and calculated fields.
4	Mobile number and email should be mandatory when creating students.	Use business rules to solve this business need.
5	The system should allow associate courses for students. One student can have multiple courses and one course can be chosen by multiple students.	Configure relationships and relationship behaviors.
6	The system should have a visualization to display courses by students joined and display students by joining date.	Configure charts for the solution.
7	The system should display a page of all visualizations for the Student table.	Create a table-specific dashboard.

In the next chapter, you see how to work with Power Apps to leverage these Dataverse concepts.

Summary

In this chapter, you learned about the following concepts:

Understanding Power Apps solutions
Working with table configurations and settings
Working with columns, datatypes, calculated fields, and rollup fields
Using auto-number columns in the Dataverse
Configuring relationships and relationship behaviors
Working with business rules
Configuring table views
Designing table forms and layouts
Chart configuration and dashboard pinning
Configuring a table-specific dashboard
Understanding alternate keys
Working with data in the Dataverse
Business scenarios, use cases, and implementation

In the next chapter, you learn about the following:

The concept of Power Apps and a no-code, less-code platform
Working with Canvas apps in detail
Using Power Fx for Power Apps
Working with model-driven apps
Power Portal concepts and designing with deployment
Managing Power Apps
Business scenarios and implementations

Table of Contents for 2. Working with Microsoft Dataverse

Create new playlist

Sign In

Sign Up