6.1 Canvas App Architecture, Screens, Containers & Controls

Canvas App Architecture, Screens, Containers & Controls

Microsoft Power Apps canvas apps provide functional consultants and app makers with complete, pixel-level control over user experience, layout, and data interaction. Unlike model-driven apps—which generate UI automatically from Dataverse relational metadata—canvas apps start from a blank canvas where every screen, container, control, and behavioral formula is explicitly configured. For the PL-200: Microsoft Power Platform Functional Consultant exam, you must master the fundamental building blocks of canvas apps: the application lifecycle, screen transitions, responsive container frameworks, high-performance gallery controls, and form management mechanics.

---

1. Canvas App Lifecycle & the App Object

Every canvas application is anchored by a top-level App object. The App object manages global application lifecycle events, initial routing, screen transitions, and unhandled exception management.

+-----------------------------------------------------------------------------+
|                        CANVAS APP INITIALIZATION FLOW                       |
|                                                                             |
|   [USER LAUNCHES APP / CLICKS DEEP LINK]                                    |
|                     |                                                       |
|                     v                                                       |
|   +---------------------------------------+                                 |
|   |           App.StartScreen             |  <-- Evaluated DECLARATIVELY    |
|   | Determines target landing screen      |      BEFORE OnStart executes    |
|   | (Inspects Param(), User(), Roles)     |      (No screen flicker!)       |
|   +---------------------------------------+                                 |
|                     |                                                       |
|                     v                                                       |
|   +---------------------------------------+                                 |
|   |             App.OnStart               |  <-- Imperative initialization  |
|   | Caches global variables & collections |      (Set, ClearCollect)        |
|   | (Navigate() is DEPRECATED here!)      |                                 |
|   +---------------------------------------+                                 |
|                     |                                                       |
|                     v                                                       |
|   +---------------------------------------+                                 |
|   |         Target Screen.OnVisible       |  <-- Screen-level state setup   |
|   | Evaluates local context variables     |      (UpdateContext)            |
|   +---------------------------------------+                                 |
|                     |                                                       |
|                     v                                                       |
|   [TARGET SCREEN RENDERS USER INTERFACE]                                    |
+-----------------------------------------------------------------------------+

The StartScreen Property vs. App.OnStart

Historically, makers used the Navigate() function inside App.OnStart to route users conditionally (e.g., directing managers to an approval dashboard and frontline workers to an inspection form). However, executing Navigate() in OnStart causes visual stuttering, delays time-to-first-render, and degrades mobile startup performance.

Microsoft introduced the declarative App.StartScreen property to resolve this:

• Declarative Evaluation: App.StartScreen is evaluated before the application loads and before App.OnStart runs. It must return an exact screen object (e.g., HomeScreen, AdminScreen, InspectionFormScreen).
• Allowed Logic: StartScreen can evaluate parameters passed via URL query strings using the Param() function, inspect the current user via User(), or evaluate offline states via Connection.Connected.
• Disallowed Logic: StartScreen cannot execute state-mutating behavior functions such as Set(), UpdateContext(), Collect(), or Navigate().

// Example: App.StartScreen formula
If(
    !IsBlank(Param("recordId")),
    RecordDetailScreen,
    User().Email in ["admin@contoso.com", "supervisor@contoso.com"],
    AdminDashboardScreen,
    StandardUserHomeScreen
)

// Example: App.OnStart formula (Data caching & global setup only)
Set(gblCurrentUser, User());
Set(gblAppTheme, { Primary: ColorValue("#0078D4"), Background: ColorValue("#F3F2F1") });
ClearCollect(colUserPermissions, UserPermissionsService.GetUserRoles(User().Email));

[!IMPORTANT] Exam Rule for PL-200: Never use Navigate() in App.OnStart. Using Navigate() in OnStart generates a studio rule warning and will be blocked in modern runtime environments. Always use App.StartScreen for initial screen routing.

Screen Lifecycle Events & Transitions

Canvas apps consist of one or more Screens. Each screen exposes distinct lifecycle event hooks:

• OnVisible: Triggers every time the user navigates into the screen. Used to reset screen-level variables, refresh specific data sources, or clear temporary selection buffers.
• OnHidden: Triggers when the user navigates away from the screen. Useful for cleanup routines and resetting form states.
• LoadingScreen & LoadingScreenColor: Configures the visual overlay shown while heavy data queries load on the screen.

Navigating between screens is accomplished imperatively via the Navigate() function:

Navigate(DetailScreen, ScreenTransition.Fade, { locRecordId: Gallery1.Selected.ID, locMode: "Edit" })

Available ScreenTransition enum values include: ScreenTransition.Fade, ScreenTransition.Cover, ScreenTransition.CoverRight, ScreenTransition.UnCover, ScreenTransition.UnCoverRight, and ScreenTransition.None.

---

2. Responsive Layout Architecture & Container Controls

Traditional canvas apps relied on absolute coordinate positioning (X, Y, Width, Height fixed integers). In modern enterprise multi-device deployments (smartphones, tablets, desktop browsers, Microsoft Teams tabs, and embedded model-driven forms), apps must be fully responsive without viewport scaling distortions.

+-----------------------------------------------------------------------------+
|                     RESPONSIVE CONTAINER HIERARCHY                          |
|                                                                             |
|   [SCREEN] (Width = App.Width, Height = App.Height)                         |
|      |                                                                      |
|      +---> [VERTICAL CONTAINER: LayoutVertical] (Header, Body, Footer)      |
|               |                                                             |
|               +--- [HEADER CONTAINER] (Flexible Height: OFF, Height: 60)    |
|               |                                                             |
|               +--- [BODY CONTAINER: LayoutHorizontal] (Flex Height: ON = 1) |
|               |       |                                                     |
|               |       +--- [LEFT NAV / FILTER] (Flex Width: OFF, Width: 280)|
|               |       |                                                     |
|               |       +--- [DATA GALLERY]      (Flex Width: ON, Portion: 1) |
|               |                                                             |
|               +--- [FOOTER CONTAINER] (Flexible Height: OFF, Height: 50)    |
+-----------------------------------------------------------------------------+

Prerequisites for Responsive Canvas Apps

To enable responsive reflow, you must disable the legacy fixed-canvas scaling settings in the Power Apps Studio (Settings > Display):

1. Scale to fit: Set to Off (prevents automatic stretching/shrinking of controls with black letterboxing).
2. Lock aspect ratio: Set to Off (allows the app to fill arbitrary viewport aspect ratios).
3. Lock orientation: Set to Off (allows fluid rotation between portrait and landscape modes).

Layout Containers: Horizontal vs. Vertical

Power Apps provides specialized layout containers that automatically position and resize child controls:

• Horizontal Container (LayoutHorizontal): Arranges child elements in a horizontal sequence (left-to-right). When wrapping is enabled, overflowing children wrap to the next row.
• Vertical Container (LayoutVertical): Stacks child elements in a vertical sequence (top-to-bottom). When wrapping is enabled, overflowing children wrap to the next column.
• Standard Container (Container): A logical grouping container that does not enforce automatic flex positioning, but allows grouped visibility, coordinate relative positioning, and component encapsulation.

Key Container Layout Properties

Child Control Sizing Inside Layout Containers

When a control is placed inside a layout container, new responsive properties appear:

• Flexible width (FillPortions) / Flexible height: When toggled on, the child control automatically expands to fill available remaining space in the container. If multiple controls have flexible sizing enabled, space is allocated according to their FillPortions ratio (e.g., 2 portions vs. 1 portion).
• Minimum width (MinWidth) / Minimum height (MinHeight): Prevents controls from shrinking below a functional touch or readability threshold.
• Align in container: Overrides the container's default LayoutAlignItems for that specific child control (Start, Center, End, Stretch, or Set by container).

Screen Size Breakpoints (Screen.Size)

Canvas apps evaluate viewport dimensions dynamically using the built-in Screen.Size property, returning an integer (1 to 4) corresponding to standard responsive breakpoints:

// Adaptive column count formula for a Gallery or responsive grid
Switch(
    Self.Size,
    ScreenSize.Small, 1,       // Phone / Narrow Viewport (< 600px)
    ScreenSize.Medium, 2,      // Tablet Portrait (600px - 900px)
    ScreenSize.Large, 3,       // Tablet Landscape / Small Desktop (900px - 1200px)
    ScreenSize.ExtraLarge, 4   // Widescreen Desktop (> 1200px)
)

---

3. Core User Interface Controls & Data Binding

Canvas applications interact with users through specialized input, display, and data-bound controls.

The Gallery Control (Gallery)

The Gallery control is the primary component used to display repeating, tabular lists of records.

• Templated Architecture: You design the first item cell (the Template), and the gallery automatically replicates that template structure across all items in its Items property.
• Key Properties:
  • Items: The tabular dataset or collection providing records (e.g., Filter(Accounts, StateCode = 'State (Accounts)'.Active)).
  • TemplateSize: Height (in vertical galleries) or Width (in horizontal galleries) of each individual item cell.
  • TemplatePadding: Internal margin separating each item cell.
  • Selected: References the active record selected by the user (e.g., Gallery1.Selected.Telephone1).
  • AllItems: Returns a table representing all loaded items currently rendered inside the gallery.
  • ThisItem Scope: Inside any control placed within the gallery template, ThisItem refers specifically to the record bound to that template instance (e.g., ThisItem.AccountName).

[!TIP] Performance Tip (PL-200 Exam): Avoid placing LookUp() formulas inside labels within a gallery template. If a gallery renders 100 rows, a LookUp() in each row triggers 100 separate synchronous network queries (the classic N+1 problem). Instead, use Dataverse relationship dot-notation (e.g., ThisItem.PrimaryContact.FullName) or pre-join data into a collection before binding to the gallery.

The Edit Form & Display Form Controls

Forms provide standardized, schema-driven data entry and record presentation for connected data sources.

+-----------------------------------------------------------------------------+
|                         EDIT FORM LIFECYCLE & METHODS                       |
|                                                                             |
|  1. INITIALIZE FORM:                                                        |
|     - NewForm(Form1)  ---> Sets FormMode.New (Blank fields, Default values) |
|     - EditForm(Form1) ---> Sets FormMode.Edit (Loads Form1.Item for edits)  |
|     - ViewForm(Form1) ---> Sets FormMode.View (Read-only presentation)      |
|                               |                                             |
|                               v                                             |
|  2. USER ENTERS DATA & CLICKS SUBMIT:                                       |
|     SubmitForm(Form1)                                                       |
|           |                                                                 |
|           +---> Data Validated & Sent to Backend                            |
|                     |                                                       |
|                     +---> [SUCCESS] ---> Triggers Form1.OnSuccess           |
|                     |                    (Access Form1.LastSubmit)          |
|                     |                                                       |
|                     +---> [FAILURE] ---> Triggers Form1.OnFailure           |
|                                          (Access Form1.Error / ErrorMessage)|
+-----------------------------------------------------------------------------+

Form Lifecycle Functions & Properties

Data Cards Architecture

When fields are added to an Edit Form, Power Apps wraps each field inside a Data Card control:

• DataCardKey: Text label showing the display name of the field.
• DataCardValue: The interactive input control (Text input, Dropdown, Toggle, DatePicker).
• Update Property: The most critical property on the card. Specifies the exact Power Fx formula that writes data back to the data source when SubmitForm() executes (e.g., DataCardValue12.Text or Dropdown1.Selected.Value).
• Default Property: Determines what value is initially populated in the input control when the form loads (e.g., ThisItem.Telephone1).
• Unlocking Data Cards: By default, cards are locked to preserve schema integrity. To replace standard controls (e.g., replacing a plain text box with a Star Rating control, a Barcode Reader, or a rich HTML text editor), you must select the card, go to the Advanced properties tab, and click Unlock to change properties.

Input Controls: Text Input, Dropdown, ComboBox & DatePicker

+-----------------------------------------------------------------------------+
|                        DROPDOWN VS COMBOBOX COMPARISON                      |
|                                                                             |
|   [DROPDOWN CONTROL]                       [COMBOBOX CONTROL]               |
|   - Single-item selection only             - Single OR Multi-select support |
|   - No type-ahead search filtering         - Searchable (IsSearchable=true) |
|   - Simple string array or single column   - Multi-column search fields     |
|   - Output: Dropdown.Selected.Value        - Output: ComboBox.SelectedItems |
+-----------------------------------------------------------------------------+

• TextInput: Supports single-line, multi-line, and password formats; triggers OnChange when focus leaves the control.
• Dropdown: Lightweight selector for small, static string lists. Supports only single selection and does not provide text search filtering.
• ComboBox: Enterprise-grade selector. Supports multi-select (SelectMultiple = true), type-ahead search (IsSearchable = true), searching across multiple column attributes (SearchFields = ["fullname", "emailaddress1"]), and setting complex initial selections via DefaultSelectedItems.
• DatePicker: Calendar date picker. Exposes SelectedDate and format options for localized calendar formats.