6.1 Creating and Configuring Forms for Model-Driven Apps

Forms define how users see and edit a single record in a model-driven app, and most record-level user experience questions on the AB-410 exam come down to choosing the right form type and configuring it correctly in the modern designer.

The Four Form Types

Every table can carry several kinds of forms, each with a distinct job:

Quick create forms have a fixed, simplified layout: a single column with a limited set of fields, no tabs, and no embedded components such as subgrids. Quick view forms always render read-only inside the host form, even when the user has write privileges on the source record — edits happen by opening the related record itself. Card forms are never opened as standalone editing surfaces; they exist so views can render a richer row.

The Modern Form Designer

You build and edit forms at make.powerapps.com: select Tables, open the table, and choose Forms. The modern form designer is the default experience and the one the exam assumes. It provides a true WYSIWYG canvas with live preview, a columns pane listing the table's columns, a components pane, and a tree view for selecting nested elements. The legacy classic designer is deprecated and is no longer the working surface for new configuration.

Two save behaviors matter and appear in exam scenarios:

• Save persists your changes for you but does not change what users see.
• Save and publish pushes the form live. Until you publish, app users keep seeing the last published version.

A form must also be included in the app itself. In the app designer you choose which forms each table exposes; a perfectly good form that is not added to the app is invisible there.

Tabs, Sections, and Columns

Main forms follow a strict containment hierarchy: tabs contain sections, and sections contain columns (fields) and components. Tabs can use one-, two-, or three-column layouts, and sections support up to four columns each. Every element carries configurable properties — label, label visibility, default visibility, and whether it is locked against accidental removal. When drag-and-drop gets fiddly on a dense form, the tree view shows the whole hierarchy and lets you select, move, or delete any node precisely. Keeping related fields grouped in named sections also matters later, because business rules and scripts can reference sections and tabs by name to hide or show them.

Header and Footer

The form header displays read-only values that stay pinned while the user scrolls through tabs, so makers put the fields users constantly reference there — typically the owner, the status, or a key date. The header shows up to four columns; the high-density header compresses them and provides a flyout so users can still edit those values without losing the compact layout. The footer mirrors the pattern with up to four columns and is a common home for the status reason. Header and footer remain consistent across every tab of the form.

Showing Related Data and Collaboration Components

• Quick view forms surface parent-record data on a child record — for example, the primary contact's details on an account — sparing users a second lookup click.
• Subgrids list child or otherwise related records (contacts on an account) directly on the form and can offer in-place actions such as adding a new row.
• The timeline component shows activities, notes, and posts in one chronological stream and is the standard collaboration surface on main forms.
• The older notes component still exists for simple note-plus-attachment capture, but the timeline supersedes it in new designs.

Form Libraries and Event Handlers (Awareness Level)

Model-driven forms can run custom JavaScript attached as form libraries — script web resources stored in the solution. The exam expects recognition, not authorship, of the three classic events:

• OnLoad — fires when the form loads; used to set defaults or control initial visibility.
• OnSave — fires when the record saves; used for last-moment validation, and it can cancel the save.
• OnChange — fires when a specific column's value changes; used for cascading logic between fields.

Handlers are wired in the modern designer's Events section (or the legacy Form Properties dialog), and the convention is to pass the execution context as the first parameter so the script knows which form and column fired it. Treat this as awareness for AB-410: know which event fits a scenario and that libraries are solution-aware web resources.

Multiple Forms, Form Order, Fallback, and Security Roles

A table can have several main forms — for instance, one for sales and a leaner one for service. The form order ranks the main forms, and each user opens the first form in that order that their security roles permit. Exactly one main form is marked as the fallback form: it serves any user whose roles match no other form, and without it those users cannot open records at all. Security-role-based assignment is a main-form-only capability — quick create, quick view, and card forms cannot be restricted by role and are effectively available to everyone.

Quick Create Prerequisites — a Classic Trap

Three conditions must all hold before quick create appears anywhere in the app: the table's Allow quick create property is enabled, a quick create form exists for the table, and that form (with the table) is included in the app. Quick create then surfaces from a lookup's New record action, the plus button on a subgrid, and the global Create button in the navigation bar. Exam trap: enabling quick create on the table but forgetting to add the quick create form to the app leaves the feature invisible — and remember, role restrictions do not apply to quick create forms, so you cannot fix visibility by assigning security roles to them.