Components of model-driven-apps

Completed

A well-designed model-driven app consists of several components that are used to build the appearance and functionality of the finished app. The components and component properties that makers use to create an app become what is known as the app's metadata.

To build off the concepts in the previous unit, and to better understand how each of these components relates to app design, we can categorize them into four categories:

  • Data
  • User interface (UI)
  • Logic
  • Visualization components

Let’s examine each of components in more detail.

Data components

Data components refer to elements that are used to manage the data in your application. Data components are critical as they impact all of the other items that follow.

Tables

In Microsoft Dataverse, a table contains records with properties that you track, such as the contact table or account table. Think of an Excel worksheet—rows represent records. Many standard tables are available in Dataverse, and many of tables (nonsystem standard tables) can be customized. You can also create a custom table from scratch.

Columns

A column is a property associated with a table. For example, in the contact table, email address is a column. Each record (row) in the contact table can have its own entry in the email column. Each column has a defined data type (for example, text, number, date, and time, currency, lookup). Formatting options vary by data type. For example, an email column would use the text data type with an email format, making it clickable in the app. Columns are typically used in forms, views, and searches.

Relationships

Table relationships define how tables relate to each other. The two primary relationships that you work with in Dataverse are:

  • 1:N (one-to-many)
  • N:N (many-to-many)

A one-to-many relationship means that one record in the primary table can be related to multiple records in the child table. For example, consider a real estate property table. Each property can be shown to several potential buyers. Each of the showings is stored in the showings table. From a property listing, you would have the ability to see all the showings associated with it. When you add a lookup column to a table, it creates a new 1:N relationship between the two tables and lets you reference the information in the related ("looked up") column.

A many-to-many relationship is where multiple records in one table could be related to many records in another table, For example, imagine table of classes and a table of students. An individual student can take several classes and each of your classes can have multiple students in them. The relationship between the classes and students tables would be a many-to-many.

Choice column

Choice columns are a special type of column that provides the app user with a set of predetermined options (think drop-down menu). Each option has a system-assigned value and label. When added to a form, this column displays a control for the user to select an option.

UI components

As you build out your application, UI components are used to determine how users interact with the app. For example, when a user navigates to the property listings page in the app, you can define how the property listings are presented.

The primary UI elements include:

  • App: The app includes fundamental settings, such as components, properties, client type, and the URL for your app.
  • Site map: The site map specifies the navigation for your app.
  • Forms: A form is a defined set of data-entry columns for a given table. For example, you can create a form where users input relevant information to track a customer's orders. The information entered in the form by users populates the relevant tables' rows and columns.
  • Views: Views define how a list of records for a specific table appears in your app. A view defines the columns shown, the width of each column, the sort behavior, and the default filters.
  • Custom page: This page is a specialized canvas app-based page allowing a more flexible layout, low-code Fx functions, and Power Apps connector data.

Logic components

These components define the business processes, rules, and automations the app has. Power Apps makers use a designer that is specific to the type of process or rule. Some components may be built outside the model-driven application.

Common types of logic:

  • Business process flow: Online process that walks users step-by-step through a standard business process. For example, use a business process flow if you want everyone to handle customer service requests the same way, or to require staff to gain approval for an invoice before submitting an order.
  • Business rule: Used to apply logic to a form, such as to set column requirements (including whether data is required in the column), hide columns, or validate data. App designers use a simple interface to implement and maintain fast-changing and commonly used rules.
  • Power Automate flow: Cloud-based service that lets you create automated workflows between apps and services to get notifications, sync files, collect data, and more.

Visualizations

The last element needed for model-driven applications is visualizations. Visualizations are used to display information in the application. You should put thought into determining what type of data visualizations and reporting the app needs to have.

Common visualizations used in model-driven applications are:

  • Chart: A single graphic visualization (such as a bar or pie chart) that can be displayed within a view, on a form, or be added to a dashboard.
  • Dashboard: A palette for one or more graphic visualizations that provide an overview of actionable business data.
  • Embedded Power BI: Embedded Power BI tiles and dashboards can be added to your app. Power BI is a cloud-based service that provides business intelligence insight.

Screenshot example of visualization components with charts.