5.3 Configuring Public Views and Main Forms

Microsoft Certified: Intelligent Applications Builder Associate AB-410

Track your progress as you read

Finished sections get a check mark.

1 Introduction

1.1 About the AB-410 Exam 1.2 How to Use This Study Guide

2 Chapter 2: Designing Power Platform Solutions with AI-Enabled Tools

2.1 Analyzing Requirements and Identifying Components 2.2 Evaluating Built-in Agents for Business Solutions 2.3 Recommending Extensibility Options

3 Chapter 3: Environments and ALM Strategy

3.1 Recommending Environment Types 3.2 Solution and Application Lifecycle Management Strategy

4 Chapter 4: Dataverse Tables and Columns

4.1 Creating and Editing Tables in the Data Workspace 4.2 Configuring Table Properties 4.3 Creating and Modifying Columns

5 Chapter 5: Relationships, AI Data Features, and Data Security

5.1 Configuring Table Relationships 5.2 Configuring Prompt Columns and Row Summaries 5.3 Configuring Public Views and Main Forms 5.4 Configuring Dataverse Security

6 Chapter 6: Model-Driven App Forms and Views

6.1 Creating and Configuring Forms for Model-Driven Apps 6.2 Creating and Configuring Views for Model-Driven Apps 6.3 Creating Generative Pages with Natural Language

7 Chapter 7: Composing, Securing, and Visualizing Model-Driven Apps

7.1 Composing a Model-Driven App 7.2 Configuring Access to Model-Driven Apps, Forms, and Views 7.3 Model-Driven App Charts and Dashboards

8 Chapter 8: Creating and Designing Canvas Apps

8.1 Creating a Canvas App Using Data 8.2 Designing for Accessibility, Performance, Responsiveness, and Usability 8.3 Automating Business Processes from Canvas Apps

9 Chapter 9: Canvas App Components, Variables, and Error Handling

9.1 Reusable Components, Named Formulas, and User-Defined Functions 9.2 Managing Variables and Collections 9.3 Implementing Error Handling in Canvas Apps

10 Chapter 10: Testing Canvas Apps and Creating Agents from Apps

10.1 Testing Canvas Apps with Monitor 10.2 Creating a Copilot Studio Agent from a Canvas App

11 Chapter 11: Cloud Flow Triggers, Connectors, and Approvals

11.1 Recommending Cloud Flow Triggers 11.2 Evaluating and Recommending Connectors 11.3 Managing Approvals with Cloud Flows

12 Chapter 12: Cloud Flow Actions, Control, and Troubleshooting

12.1 Configuring Cloud Flow Actions 12.2 Implementing Flow Control with Conditions and Loops 12.3 Testing and Troubleshooting Cloud Flows

13 Chapter 13: Building Prompts in AI Hub

13.1 Building Prompts from Templates or from Blank 13.2 Adding Inputs to a Prompt 13.3 Adding Knowledge to a Prompt

14 Chapter 14: Prompt Settings, Models, and Consuming AI

14.1 Customizing Prompt Settings and Models 14.2 Consuming Prompts in Apps and Cloud Flows 14.3 Consuming AI Models in Apps and Cloud Flows

15 Chapter 15: Business Rules and Business Process Flows

15.1 Configuring Business Rules 15.2 Configuring Business Process Flows

16 Chapter 16: Calculated Columns and Business Logic Strategy

16.1 Calculated, Rollup, and Formula Columns 16.2 Evaluating Use Cases for Business Logic

5.3 Configuring Public Views and Main Forms

Key Takeaways Explain This Topic AI

Grid search in a model-driven app searches only the find columns configured on the table's Quick Find view — adding a column to a public view does not make it searchable.

Each table has one default public view; makers set it with Set as default in the table's Views list.

Quick view forms render a related record read-only inside another table's form; quick create forms require the table's Allow quick create property and contain no tabs or subgrids.

Multiple main forms per table are controlled by form order and security-role assignment, with an optional fallback form for unmatched users.

Views and forms are table-level assets shared by every model-driven app that includes them — edit once and the change appears everywhere.

Last updated: July 2026

Views: System vs Personal

A view defines which rows and columns appear when users browse a table in a model-driven app. Dataverse distinguishes system views (defined at table level, visible to everyone) from personal views (saved by individual users and shareable user-to-user).

System view types to know by name:

View type Purpose
Public Custom views makers create; every user of the app can pick them
Default Public The one public view shown first when a table page opens
Quick Find Drives grid search — its find columns are the columns searched
Lookup Columns shown in lookup dropdown results
Associated Rows shown when you open a related-records tab from a parent form
Advanced Find The column set returned by legacy advanced find queries

Personal views are created by end users from the grid's view editor ( Save as new view ), appear under My views , and can be shared with specific users or teams. They never change what other users see in system views.

Creating and editing a public view

Go to make.powerapps.com → Tables → [your table] → Data experiences → Views , then select New view (or open an existing public view). In the view designer you can:

Add, reorder, and resize columns , including columns from related tables — for example, showing the Account's Primary Contact email on a view of Cases

Set the sort order with a primary and a secondary sort column
Define filters in the Filter by panel, such as Status equals Active and Created On in the last 30 days
Rename the view, then Save and publish

To control which view users land on, open the table's view list, select a public view, and choose Set as default — there is one default public view per table. In the model-driven app designer , each table page exposes the views (and forms) you include; removing a public view from an app hides it from that app's view selector without deleting it.

Quick Find and find columns

When a user types in the grid search box, Dataverse searches only the find columns configured on the table's Quick Find view ; the Quick Find view's regular view columns control what the search results display. Adding a column to a public view does not make it searchable — a frequent exam trap. Quick Find is also separate from the environment-wide, relevance-ranked Dataverse search , which has its own index and admin setting.

Main Forms and Friends

Model-driven apps use four form types:

Form type Used for
Main Full record create/edit experience — tabs, sections, columns, subgrids, components

Quick create Compact create form launched from the navigation bar + or a subgrid's New button; single-column layout, no tabs

Quick view Read-only summary of a related record embedded on a form via its lookup — for example, showing key Account columns on an Order form

Card Compact rendering of a row inside views and dashboards
Building a main form

Open the table → Data experiences → Forms → open the main form, or edit it directly from the app designer. In the form designer you can:

Drag table columns from the left pane onto sections; set labels, visibility, read-only, and required state

Add components — subgrids for related records, the Timeline (notes, posts, activities), rich text , file , and Copilot/AI elements

Organize the layout with tabs and sections , and show or hide standard elements such as the header , footer , and navigation

Configure form libraries and event handlers (awareness level: JavaScript web resources can run on form events such as OnLoad and OnSave)

Multiple main forms, form order, and security

A table can have several main forms — for example, a streamlined Intake form and a full Investigation form. Form order determines which form a user sees by default, and forms can be restricted by security role so different teams get different forms; you can also designate a fallback form for users whose roles match no specific form. In the model-driven app designer you select which of the table's forms the app includes.

Exam traps:

Quick create must be enabled on the table first (the table property Allow quick create ), and the form cannot contain subgrids or tabs.

A quick view form is always read-only — if the requirement says edit the parent record from the child form, quick view is the wrong answer.

Views and forms live on the table , not inside one app: edits to a public view or main form appear in every model-driven app that includes them.

Where views and forms live

Everything above is table-level metadata managed from the table hub in make.powerapps.com (Tables → open table → Data experiences : Forms, Views, Charts, Keys, Dashboards). The modern model-driven app designer then references those assets: adding a table as a page brings in its views and forms, and the Data pane acts as the app's data workspace for binding additional tables. Because the assets are table-scoped, the same public view can be reused across multiple apps — but a maker editing it from one app changes it everywhere, which is why governance-minded teams document ownership of shared views and forms.