Generative Pages

What it does

Describe a page in natural language and an app agent writes React code for it, which then runs as a page inside a model-driven app. You point it at Dataverse tables, optionally attach a sketch of the layout you want, and refine the result by chatting with the agent or editing the generated code directly. Published pages are solution-aware, so they move between environments like any other component.

Key facts

Two authoring routes, and they are not equivalent. In-browser at make.powerapps.com is the maker experience, but it is limited to environments in the United States, Great Britain, Australia and Singapore, and GPT-4.1 is the only model available. AI code generation tools (GitHub Copilot CLI and similar, working against the local repo) are available worldwide on public clouds, give access to newer models, and can produce several pages plus the supporting tables in one run.
Up to six Dataverse tables can be linked to a single page. Prompts cap at 50,000 characters.
Power Platform connectors are supported as a data source in preview, and need a connection plus a connection reference in the default solution before the page can see them.
Supported column types are the common set — text, choice, lookup, customer, currency, dates, numbers, image, status, status reason, yes/no, unique identifier. Anything outside that list is not handled.
No AI or message credits are consumed by the maker experience for generative pages or plans. That is stated explicitly in the FAQ.
Prompting in the browser is US English only.
Pages accept recordId, entityName and data as input parameters, can be embedded in a form via the Generative page component under Display, and can be opened from client script with Xrm.Navigation.navigateTo.
Collaboration is not supported. One maker per page at a time, or you will lose work.
An accessibility assistant scans each iteration and offers Auto fix, which hands violations back to the agent.
Canvas apps are not supported. Model-driven only.

When to use / skip

Use it for pages the standard designer is bad at — card galleries, kanban boards, dashboards, anything where the requirement is visual and the out-of-the-box form and view experience produces something the business politely calls "functional". Having a stakeholder sketch a layout on paper, photograph it and get a working page back in the same workshop is a real capability, not a demo trick.

Skip it for the bread and butter. Forms, views, grids and business process flows are better served by the normal designer, which everyone can maintain, and which does not produce a few hundred lines of React that someone has to own. Skip it too if your environment is outside the four supported regions and nobody on the account can drive the CLI route, because the in-browser experience simply is not there.

Configuration decisions

Which authoring route. The CLI route is the better tool and the worse fit for most maker teams. Decide this per client, based on whether there is anyone who works in an IDE, and be honest about it before promising a region-locked browser experience.
Who owns the generated code after go-live. It is React, it is in a solution, and it is nobody's job by default. Name the owner during design, not at handover.
How generated pages are reviewed. Microsoft is explicit that the output is not guaranteed production-ready or compliant, and that validation is yours. Decide whether that is a code review, a security review, or both.
Whether to allow the stock image library. The Include images tool draws from a curated 25,000-image library — non-AI-generated, but still third-party imagery appearing in a client's app.
Where images come from otherwise — a Dataverse image column, an external URL, or a web resource. Pick one and standardise, because the agent will happily do all three across different pages.
Localisation approach, if the app is multilingual. The agent will build a translation dictionary if you ask for one in the prompt, but the sitemap entry is not localised and has to be handled separately.

Gotchas

Only the last published code and the first prompt survive a solution export. The agent conversation and the iteration history stay in the source environment. Anyone expecting to carry on the dialogue in the target environment is in for a surprise.
Pages created during the preview phase need a one-time migration to the solution-aware data model, triggered by opening them in the app designer. Until that happens they will not appear in dependency checks and will not export. Closing the window mid-migration is the obvious way to break this.
If generative pages still do not show up in dependency checks after migration, the usual fix is a trivial sitemap change and a republish. That is a genuinely obscure step to have to discover during a release.
The six-table limit sounds generous until you hit a page that wants a record, its parent, its child rows, a lookup table and two reference tables. Design the page around the limit rather than discovering it halfway through.
Region restriction is on the environment, not the tenant. A UK client with an environment provisioned elsewhere gets no browser experience and no useful error explaining why.
"Compare" only works from the second iteration in a session, so the diff you want after reopening yesterday's page is not there.
Manual code edits become a new iteration. Chatting with the agent afterwards means it is working on top of your edits — which is usually what you want, and occasionally very much not.

Consultant notes

The scoping mistake is treating this as a designer feature. It is code generation with a chat window on the front, and the estimate should look like a code-app estimate: build, review, test, own. Clients who scope it as "the AI makes the page" have not budgeted for the review.
It surprises people in UAT because it works. Testers start asking for more generative pages mid-cycle, and because generating one is quick, scope creeps without anyone logging a change. Fix the page count in the design, not in the sprint.
The post-go-live risk is ownership. When a generative page misbehaves in eighteen months, the person holding it is a maker who cannot read React and a developer who has never seen the app. Put the generated code through your normal source control and review path from the first page, even though nothing forces you to.
Sequencing matters with solutions. Get the app into the solution, confirm generative pages appear as UX Agent Project rows during dependency checks, and do a throwaway export to a sandbox early. Finding the migration and sitemap quirks during a go-live weekend is avoidable.
Ask about the four supported regions in the first conversation. It is the single fastest way to establish whether this is a real option or a slide.

Worth revisiting when connector data sources leave preview, when the in-browser model choice widens beyond GPT-4.1, or if the supported region list expands.