Podcast Takeaways: When to Build Custom Pages in Model-Driven Apps

Earlier this year I had the chance to join Daryl LaBar and Scott Durow on the XRM Toolcast to talk about custom pages in Power Apps. The conversation covered everything from theming tricks to delegation pitfalls—and even sparked a friendly debate about how to name a certain fast‑food item. The real takeaway, though, was a clear framework for deciding when custom pages are the right tool and when to stick with a classic model‑driven form. This article translates that discussion into a practical guide you can apply today.

The Contoso Project Dashboard

Let’s imagine you are building a solution for Contoso, a medium‑sized company that tracks internal projects. Their model‑driven app already has a table called Projects with these columns:

Column Name	Data Type	Notes
ProjectName	Text	Primary name of the project
Status	Choice	Not Started, In Progress, Completed, On Hold
Owner	Lookup (User)	Person responsible
TargetDate	Date Only	Planned completion date
BudgetRemaining	Currency	Amount left in budget

Management wants a single dashboard where they can see all projects, quickly update statuses in bulk, and highlight overdue items. A standard model‑driven view plus form can handle basic CRUD, but the interactive filtering and inline editing they envision would be clunky inside a form. This is the perfect scenario for a custom page.

Step‑by‑Step: Building the Custom Page

1. Add a Canvas Page to your Model‑Driven App

In the maker portal, open your solution, choose New > Page > Canvas page, and give it a name (e.g., “Project Dashboard”). Use the phone or tablet layout—for a dashboard, tablet works best.

2. Connect to the Projects Table

Use the Power Apps Studio that opens. Add a data source: Microsoft Dataverse > Projects. This gives you access to the table columns without writing the formula manually.

3. Design the Layout

Add a Vertical Gallery and set its Items property to:

powerfxGallery Items

Filter(Projects, Status <> "Completed" || Status = "Completed" && TargetDate > Now())

Delegation note: Filter with a direct column reference on a choice field is safe for lists under 50,000 rows. If your table grows larger, create a Status choice column that maps to a Dataverse choice (which can be filtered with ='Status (Projects)'."Value"). We’ll cover this in the performance section.

4. Enable Inline Status Updates

Inside the gallery, place a DropDown control bound to the Status field. Set its Update property to:

powerfxDropDown Update

Patch(
  Projects,
  ThisItem,
  {Status: Dropdown1.Selected}
)

This writes back instantly when the user picks a new status. For a polished feel, add a Modern Dropdown (available in the Creator Kit) instead of the classic drop‑down—they use points instead of pixels and better match the model‑driven look.

5. Add a Highlight for Overdue Items

Insert a Label that shows “OVERDUE” in red when TargetDate has passed and the project isn’t completed. Set the label’s Visible property:

powerfxOverdue Label Visible

ThisItem.TargetDate < Now() && ThisItem.Status <> "Completed"

Theming Consistency: Pixels vs. Points

During the podcast, we explored how to make a custom page look like part of the model‑driven app instead of a separate canvas app. The key is the Creator Kit (previously known as the Microsoft Power Platform Creator Kit). It provides components that use points (scalable units) rather than pixels, so your buttons and inputs align with the host app’s theme.

Creator Kit Setup

When you add a Modern Control (e.g., ModernButton), the kit automatically applies the same colour palette and font stack as your model‑driven app, provided you’ve loaded the kit’s theme. Add the <Theme> component inside your page’s container.

Performance and Delegation Gotchas

Custom pages inherit canvas app delegation limits. The most common trap is using Filter on an unsupported column type. For a Choice column, always use the syntax 'Status (Projects)' = 'Status (Projects)'.'In Progress' rather than a string compare. Similarly, avoid StartsWith on large Dataverse tables unless you’ve filtered enough rows first.

Workaround for very large tables: Pre‑filter the data in a Power Automate flow and pass the result to a collection. Or use a Filter on an indexed lookup column (like Owner).

Common Mistakes and Troubleshooting

Mixing unit systems: Default controls use pixels; Creator Kit controls use points. Placing both side‑by‑side makes the UI look mismatched. Pick one system and stay consistent.
Over‑engineering: You don’t need a custom page for every form. If the requirement is only to update a single field, a standard form with a quick‑view is faster to build and easier to maintain.
Missing error handling: Patch operations should be wrapped in an If or UpdateContext check. Otherwise a failed write silently fails.
Ignoring responsive layout: Most custom pages are used on desktop today, but users may open them on mobile. Test your gallery scrolling and button sizes on a smaller viewport.

Final Recommendation

Use a custom page when you need a spatial, interactive dashboard that goes beyond a standard form—like the Contoso project dashboard with inline editing, conditional formatting, and aggregated views. For everything else, keep the simplicity of model‑driven forms. The two together, designed with consistent points‑based theming, give you the best of both worlds.

Thanks again to Daryl and Scott for the great conversation. Watch the full episode on the XRM Toolcast YouTube channel.

References

Original podcast article by Matthew Devaney: Power Apps Custom Pages, Chicken Burger vs. Chicken Sandwich, Low Code AI Interview
Microsoft Learn – Create a custom page for a model‑driven app
Creator Kit documentation: Microsoft Power Platform Creator Kit