What it does

A custom page is a canvas-authored page type inside a model-driven app. It gives you Power Apps Studio layout, Power Fx, connectors and PCF controls where a form, view or dashboard would be too rigid — as a full page, a centred or side dialog, or an app side pane.

Key facts

• Generally available: the runtime, solution/ALM support, connectors, modern controls, code components, canvas components, Monitor support, and authoring through the modern app designer and Studio. Custom pages in a Teams model-driven app and in mobile online are both public preview as of the March 2026 documentation.
• Custom pages must be created from a solution — either from the modern app designer or New > Page in the Solutions area.
• Each custom page is its own solution component, so one maker edits one custom page at a time. Even a multi-screen custom page is a single component.
• Custom pages are treated as part of the model-driven app infrastructure. They follow the model-driven app's licence and don't count towards app limits, because they're a page rather than an app.
• Sharing follows the model-driven app. App users don't need the page shared to them individually; makers may need it shared to edit.
• Microsoft's guidance is not to exceed 25 custom pages in a model-driven app. Beyond that, the first user to launch the app after a publish waits longer — the cost is on that first launch only.
• Navigation both ways: added to the site map for direct navigation, opened from model-driven pages using the navigateTo Client API, and navigating out to other custom pages or to forms, views and dashboards with the Power Fx Navigate function.
• Data can come from Dataverse and any Power Apps connector.
• Responsiveness is handled with the standard container controls, no formulas required.
• Existing standalone canvas apps aren't supported as custom pages. The expected structure differs — a custom page is typically a single screen with loose coupling, not a many-screen app with global state.
• App.ConfirmExit isn't supported in custom pages.

When to use / skip

Use a custom page when the requirement is a purpose-built interface that a form can't express — a wizard, a dashboard with bespoke visuals, a search-and-select experience over several tables, a guided data-entry flow. Stay on a form when you're editing one record's columns, because a form gives you business rules, role-based access, the timeline, the command bar and the audit trail free, and a custom page gives you none of that. The other clear rule: prefer a custom page over an embedded canvas app on a form. Embedded canvas apps are the older, looser integration with a cap on how many you can have; custom pages are the answer Microsoft built to remove that limit and they perform better.

Configuration decisions

• Custom page versus form versus embedded canvas app, decided per requirement rather than per project.
• Full page, centred dialog, side dialog, or app side pane — each has a different feel and a different amount of screen.
• How the page receives its context: site map navigation with no parameters, or opened with parameters from a command or a form script.
• Whether the page is one screen with navigation out to other pages, or multiple screens inside one component. One screen per page is the intended pattern and keeps co-development possible.
• Which connectors the page uses, since each one is a licensing and DLP question that a plain form never raises.
• How many custom pages the app will end up with, against the 25 guideline.

Gotchas

• One maker per custom page, full stop. Two people cannot work on the same page, and if you've put six screens in one page you've serialised six screens' worth of work behind one person.
• Business rules, role-based forms, field-level security behaviours and the form command bar don't come with you. Anything you rely on there has to be rebuilt or re-implemented.
• Going past 25 custom pages costs the first user after every publish. That's usually a maker in testing, so it's easy to dismiss until it's a real user on Monday morning.
• Migrating a standalone canvas app means copying screens one at a time into separate pages and rewriting every Navigate call to target page names instead of screen names. It's not an import.
• Connectors in a custom page bring premium licensing into an app that was otherwise covered by the model-driven licence. Check before you design around one.
• Custom page in Teams and in mobile online are preview as of March 2026. Don't build a mobile-first requirement on them without saying so in writing.

Consultant notes

• The strongest argument for custom pages with clients is that they don't count towards app limits and they inherit the model-driven app's licence and sharing. That removes two of the usual objections in one sentence.
• Set the "form first, custom page when justified" rule with the delivery team early. Custom pages are fun to build and that's exactly why they proliferate.
• The one-maker-per-page constraint is a sprint-planning fact, not a technical footnote. Split pages along the lines your team can work in parallel on.
• Warn the client that a custom page is code they now own. The maintenance profile is a canvas app's, not a form's.
• Use Monitor on custom pages when troubleshooting — it's supported and it's the only real visibility you get into what the page is doing.

---

Worth another look when Teams and mobile online custom pages reach general availability, or if the 25-page guidance shifts.