By Scott Singleton, Managing Consultant, i3solutions

Somebody on your team watched a demo. A person typed two sentences about tracking equipment checkouts, and ninety seconds later there was a working app with tables, screens and a form. It looked like the end of a category of work your organization has been paying for. The reasonable question that follows is not a rhetorical one, and it deserves a straight answer rather than a defensive one: if the AI can do that, what exactly are we still buying?

Can AI build me a Power App?

Yes. As of August 2026, Copilot in Power Apps generates a working app from a plain-English description, and Plans, which Microsoft lists as generally available, produces Dataverse tables, canvas and model-driven apps, Power Pages sites, flows and agents. What it hands you is a real first draft, not a governed production system. The distance between the two is environment strategy, DLP, ALM, security review, integration depth and licensing, and that is where the cost has always been.

The rest of this page is the honest version of both halves. First what the AI genuinely does well, quoted from Microsoft’s own documentation with the dates on it, because this surface changes faster than any page about it. Then the specific places a generated app meets an enterprise and stops, which is not a marketing list but a description of the work that is left over.

1. The capability facts on this page, and when each one was checked

Everything in this section was read directly from Microsoft’s published Power Apps documentation on 22 August 2026. The dates in brackets are the last-updated dates Microsoft states on each article, not our reading of them. This is a fast-moving product surface and two of the facts below were different a year ago, so if Microsoft’s page and this one disagree, Microsoft’s page is right and this one is stale.

  • Copilot in Power Apps overview [Microsoft date 21 January 2026]: “Copilot in Power Apps lets you quickly build apps using natural language.” Also, on admin control: “Generally available Copilot features are on by default and can’t be turned off except by Microsoft Support.”
  • Build apps through conversation with Copilot [10 April 2026]: “Enter the type of information you want to collect, track, or show in your app, and Copilot generates one or more Microsoft Dataverse tables that you use to build your canvas app.” Prerequisites include a Dataverse database and the system customizer security role.
  • Use plans to create AI-powered business solutions with Copilot [7 August 2026]: “Plans generates a complete Power Platform solution tailored to your needs. It includes Microsoft Dataverse tables, canvas apps, model-driven apps, Power Pages sites, Power Automate flows, and Copilot Studio agents.” Microsoft states that “Plans is generally available and enabled by default.”
  • Edit your app with Copilot in Power Apps Studio (preview) [10 November 2025]: “Starting January 6, 2026, this feature will be removed. To continue creating apps with Copilot, use Plans.”
  • FAQ for building apps and tables through conversation [28 May 2025]: “AI-generated content may have mistakes. Make sure it’s accurate and appropriate before using it.” And on the generated data: “The sample data is for illustration only and is fictitious.”
  • Move data across regions for Copilots, AI agents, and generative AI features [21 May 2026]: the feature table marks “Build apps through conversation” for Power Apps as not available in GCC, alongside “Describe a new table”. Power Automate designer Copilot and AI Builder prompts are marked available.
  • Overview of the new Power Apps vibe experience [16 April 2026]: “This feature is in preview.” And: “This capability is currently available only in the US, Australia, Asia, and India regions, and only in English.”

Read them yourself before you make a staffing decision on the strength of this page. The one that surprises people most is the fourth: a Copilot capability that shipped, was widely demonstrated, and was then retired into a different tool inside about two years.

2. What the AI is genuinely good at, stated without hedging

Answering this by listing everything the AI cannot do would be easy, and dishonest. The capability is real. It is better than the first release was, and it improved again this year. Dismissing it costs you credibility with the person who watched the demo, and they are usually right about what they saw.

Here is what it does well, on the evidence of Microsoft’s documentation and our own use of it:

  • Data modeling from a description. You describe what you want to track and Copilot proposes tables, columns, relationships and data types. This is the part people underrate. Getting a workable first-cut schema out of a business person’s sentence used to take a requirements session.
  • The first draft of a simple, data-backed app. A list, a form, a detail screen, a status field, an assignment. For an app whose entire job is structured capture over a single data source, the generated version is frequently close to what a developer would have built.
  • Scaffolding, so the expensive people start from something. A generated solution turns the first hour of a project from a blank canvas into a critique. Reviewing a wrong schema is faster than authoring a right one.
  • Making the shape of an idea visible to a business owner. Most requirements arguments are really arguments about a picture nobody has drawn yet. Generating the picture in ten minutes settles them cheaply.
  • Breadth, in the Plans experience. Microsoft’s list of what Plans emits is not trivial: tables, canvas apps, model-driven apps, Power Pages sites, flows and agents. It is a solution-shaped output, not a single screen.

If your need is a departmental tracker over one Dataverse table, used by twelve people, holding nothing an auditor cares about, then the honest advice is to let a trained maker build it with Copilot and spend your implementation budget somewhere else. We say that in scoping calls, and we have.

3. Where the generated app and the production app stop being the same object

The demo ends when the app runs. The enterprise question begins about ninety seconds later, and it is not a question about screens. Microsoft is direct about the boundary in its own responsible-AI FAQ: “AI-generated content may have mistakes. Make sure it’s accurate and appropriate before using it.” The sample rows the generator populates are, in Microsoft’s words, “for illustration only and is fictitious.”

The harder boundary is structural, and it shows up in six places: what the app may connect to, where it lives, how it changes, who may see what, what it integrates with, and what it costs to license. All six are routine in a regulated Microsoft estate. None of the six is expressible in a prompt.

Governance and DLP: what the app is allowed to touch

A generated app connects to what the maker can reach. It does not know that your organization forbids a connector that bridges an internal SharePoint list to a personal cloud storage account, or that a specific dataset may not leave a compliance boundary. Those rules live in tenant-level and environment-level data loss prevention policy, and they are enforced by the platform rather than by the app. i3solutions governs client Power Platform tenants with the Center of Excellence Starter Kit, tenant-level and environment-level DLP policies, and managed environment controls. Those are the controls that decide what the app your maker generated on a Tuesday is permitted to connect to, which is a different question from whether it works, and it is the question an audit asks.

The effect compounds in year two rather than week one. When generation is easy, generation happens more, and the population of apps grows faster than anyone’s ability to inventory it. That is the app sprawl problem, and AI generation is the strongest accelerant it has ever had. The countermeasure is not a rule telling people to stop; it is a DLP policy and a Center of Excellence that make the safe path the easy one.

Environment strategy: where the app actually lives

Watch closely during a Copilot demo and you will see the app land in whatever environment the maker happened to be in, or in a personal developer environment the platform created for them. Microsoft’s own prerequisites for Plans describe exactly this fallback: makers without permission to create tables are routed to their own developer environment.

That is fine for a prototype and wrong for anything a business depends on. i3solutions runs client Power Platform work on a multi-tenant Center of Excellence model with separate Dev, Test, UAT, and Production environments promoted through managed solutions. The generated app has to be moved into that structure, which is not a copy and paste: it is a solution boundary, a publisher prefix, connection references, environment variables and a promotion path. Deciding that structure is a design decision about your organization, and no prompt describes it.

ALM: what happens on the second change

Every generated app is built on the assumption that it is the first version. Production apps are defined by their fifth. i3solutions delivery includes ALM practices with Power Platform pipelines or Azure DevOps integration, environment separation strategies, and change control processes. Without that discipline the cost does not disappear, it defers: Power Platform environments without ALM discipline accumulate technical debt requiring 40-60% more maintenance effort within 18 months, making governance frameworks essential from implementation start rather than as an afterthought.

This is the single most predictable failure mode of AI-generated apps, and it is quiet. Nothing breaks on day one. The app works, the department is happy, and eighteen months later nobody can change it safely because there is no test environment, no solution layering and no record of why anything is the way it is.

Security review: the questions the prompt never asked

Who may see which rows? What happens when a user changes role or leaves? Where do the secrets live for the API this app calls? Which actions have to be recorded for an audit, and where is that record kept? Does this app touch controlled data, and if it does, does its environment meet the obligation attached to that data?

Generated apps answer none of these, because they were not asked. i3solutions selects Dataverse over SharePoint as the primary relational store when a client needs scalable high-volume transactional data, and holds application secrets in Azure Key Vault. The data-store choice in particular is one the generator makes for you by default rather than by analysis, and it is difficult to reverse once real data is in it. If that decision is live for you, our comparison of Dataverse and SQL Server is the longer version of that argument.

Integration depth: the second system

Generated apps are strongest when the app is the system. They get thin fast when the app is a face on something else: an ERP, a claims platform, a scheduling system, a line-of-business database with thirty years of rules in it. That work is connector architecture and error handling, not screen layout. i3solutions workflow automation builds use standard and premium Power Platform connectors, custom API connectors published through Azure API Management, and hub-and-spoke approval patterns built on Dataverse tables or SharePoint lists.

The tell is what happens when the other system is down or slow. A generated app usually does the naive thing, which in a business process means a silent failure somebody discovers a week later in a reconciliation.

Licensing: the bill the demo did not show

The connector your generated app chose may be a premium connector, and premium connectors carry a license. This is the most common unpleasant surprise in low-code programs, and it arrives after the app is popular. i3solutions implements Power Platform licensing across Power Apps per-app and per-user plans, Power Automate per-flow and per-user plans, and the Microsoft 365 default entitlements where app complexity is low. Sorting that out before rollout rather than after is a genuinely cheap piece of work, and the premium versus per-app comparison covers the decision in detail.

4. If your tenant is regulated, read this section before the others

Most of our clients operate under CMMC, ITAR, DFARS, HIPAA or SOC 2 obligations, and for them the availability question comes before the capability question. Here the published answer is specific rather than vague, and it is the fact most articles on this topic leave out.

Microsoft’s feature table marks “Build apps through conversation” for Power Apps as not available in GCC. That table is in Move data across regions for Copilots, AI agents, and generative AI features [Microsoft date 21 May 2026], and it marks “Describe a new table” the same way. In the same table, Power Automate designer Copilot and AI Builder prompts are marked available in GCC, so this is a per-feature answer rather than a blanket one. The newer vibe experience is narrower still: Microsoft states it “is currently available only in the US, Australia, Asia, and India regions, and only in English,” and that it “is in preview.”

Three practical consequences, in the order they usually matter:

  • The demo your team saw may not have been running in a cloud you are allowed to use. Before an internal debate about whether AI replaces a build, establish which environment the capability actually exists in for your tenant. That is a five-minute check that prevents a quarter of planning.
  • Commercial-cloud capability is not a roadmap commitment for a government cloud. Ask Microsoft or your licensing partner for a dated written statement about your specific environment. If you have not settled the environment question itself, whether CMMC actually requires GCC High is the decision underneath this one.
  • Where Copilot features are generally available, they are on. Microsoft’s wording is that generally available Copilot features “are on by default and can’t be turned off except by Microsoft Support.” Preview features can be toggled off per environment or per tenant; GA features cannot. For a governance team, that inverts the usual sequencing: the control you have is over environments, data policy and who holds the maker role, not over whether the capability exists.

None of that is an argument against using it. It is an argument for knowing which of the three answers applies to you before anyone builds a plan on top of the wrong one.

5. What this actually changes about how you staff the work

The useful way to think about generated apps is that AI has moved the expensive part, not removed it. The screens were never the expensive part. What costs money is deciding what the app is allowed to do, where it lives, how it changes, what it connects to and who is accountable when it is wrong.

Two things follow. The first is that the choice of app type still has to be made by someone who knows the consequences. Canvas apps and model-driven apps solve different problems and inherit different governance. i3Solutions builds both kinds through its power platform development services in regulated environments, and the choice always starts with the same question: what is the data and what governance does this app need to inherit. Our full treatment of that decision is in canvas versus model-driven apps for regulated enterprises.

The second is that governed generation at scale is a solved problem, but it is solved by structure rather than by tooling. i3solutions runs a governed Power Platform for a federal defense agency supporting roughly 10,000 personnel across about 180 locations, which works because it is governed, not despite it. Thousands of users and a genuine maker community coexist with a compliance obligation because the environment strategy, the DLP posture and the promotion path were designed before the app count grew, not after.

“Hire a firm” is not an answer by itself, so here is the number that matters. Microsoft specialists reduce environment management overhead by 40-60% because they understand ALM pipelines, solution layering, and security boundary management from day one. That overhead is the recurring cost AI generation does not touch, and it is the line where specialist delivery pays for itself rather than in the app build.

What the delivered work looks like when the app is real

For the class of project where a firm is worth engaging, the outcomes are ordinary and measurable rather than transformational. Replacing 32 outdated InfoPath forms with Power Apps reduced maintenance demands by 40%, saving an estimated $150K-$200K annually in IT labor and support. That was not a hard app to build. It was a hard app to build correctly, migrate onto, govern and support, which is a different sentence.

The band is wide because the drivers are. Power Apps development work ranges from $50,000 to $350,000 per project, depending on size, complexity and length. An app that a maker could have generated in an afternoon belongs at the very bottom of that band or outside it entirely. What pushes a project up the band is integration surface, data volume, compliance obligation and the number of systems that have to keep agreeing with each other.

6. A short decision rule you can use this week

You do not need a framework. You need three questions, and they sort most requests correctly.

  1. What is the worst thing that happens if this app is wrong? If the answer is that a team re-enters some data, let a maker generate it. If the answer involves a regulator, a customer commitment, a payment or controlled information, it goes through a design and review path regardless of who or what wrote the first version.
  2. How many systems does it have to agree with? Zero or one is maker territory. Two or more is integration work, and integration work is where generated apps are weakest.
  3. Who owns it in eighteen months? If nobody can name a person and a change process, the app is a liability the day its author changes roles. This question has ended more low-code programs than any technical limitation.

Used honestly, that rule sends more work to the AI than most delivery firms would like to admit, and it protects the work that genuinely should not go there. If you want it as a standing operating model rather than a judgment call each time, our Power Platform CoE operating model and citizen developer pages describe how that is usually set up.

What to bring to a scoping conversation

Four answers make thirty minutes productive: which cloud environment your tenant runs in, whether a Center of Excellence and DLP policy already exist, roughly how many Power Apps are live today and who can name their owners, and what the app in front of you has to integrate with. If you cannot answer the third one, that is not an embarrassment; it is the most common finding we have, and it is usually where the work starts.

What you should get out of that half hour is a straight sort: which of your candidate apps a trained maker should generate this month, which need design before anyone builds, and which are not app problems at all. That sort is useful whether or not you engage anyone, and it is the part your steering committee can actually act on. If you are building the internal case rather than buying this quarter, ask for how comparable engagements were scoped and where they landed in the band, so you have something to put in front of a committee before committing to anything. Nobody needs a proposal to make that half hour worth having.

Schedule a 30-minute scoping call

If the open question on your side is architectural rather than commercial, which environment structure you should be promoting through, how a maker community and a compliance obligation coexist, or whether a specific app belongs on Dataverse at all, that is a different conversation. It should be with someone who has built it inside a regulated tenant rather than with someone reading a feature table back to you. Ask for the architecture track when you book, and bring the app that is causing the argument.

Talk to a senior Power Platform architect

Related