First it was HTML in SharePoint. **Now Copilot builds apps**
Microsoft WorkplacePower PlatformSharePointM365 CopilotPower AppsSPFxAnalysis

First it was HTML in SharePoint. Now Copilot builds apps

Copilot Cowork now builds React apps connected to SharePoint, Dataverse or SQL that read and write data. What the App skill does, where those apps run, what admins control and what it costs to run them.

Macareno7 min read

A few days ago, SharePoint started accepting HTML pages. We covered it here: a new format Copilot writes in one pass, locked inside an iframe that doesn't know who is looking and that shows a list's data without being able to touch it. A viewer. Useful, but a viewer.

Meanwhile, on the other side of Microsoft 365, Copilot Cowork got a skill that plays in a different league. It's called App, it's in preview through the Frontier program, and it doesn't generate pages. It generates applications. The kind that read your SharePoint list, show you what's at risk and, when you change a value, save it back to the list.

The snapshot started to move.

From list to app in three prompts

The best public demo so far comes from Reza Dorrani, one of the best-known content creators in the Power Platform world. He starts with a SharePoint list holding a project portfolio: owner, department, status, health, budget. He asks Cowork for a "project delivery command center" with indicators at the top, health, progress and budget versus spend, on a clean, executive-friendly screen.

Cowork invokes the skill and, a couple of minutes later, returns a link to the app running against the real data. Second prompt: highlight at-risk projects, add search, filters by owner, department, status and health, and a detail view. Third prompt: allow creating and editing projects. Reza changes a project's health to "on track", saves, and the project drops out of the alerts section. The change is already in the list.

Nobody wrote a line of code. But the code exists.

Under the hood: React, a config.json and one rule

This isn't static HTML. Cowork generates a full React project and lets you view the source code. There's a config.json with the app ID, the environment it was built in and the connection to the SharePoint list. That connection goes through Power Platform connectors, more than 1,500 of them, so the source could just as well be Dataverse, SQL or Excel instead of a list.

The rule: inside Cowork, that code is read-only. You can look, not touch. Every change goes through a prompt.

The HTML page lets you look at the list. The app lets you change it.

The engine has a name: Copilot Managed Runtime

Cowork is just one of the doors. These apps run on Copilot Managed Runtime, also in preview, which has three entry points: Cowork for people who want to ask for the app in a conversation, Copilot Studio for makers who want more control over each step, and an SDK with its own CLI (the ms command) for developers who prefer VS Code and Git.

All three produce the same artifact: a Microsoft-hosted app with built-in Entra ID authentication that inherits tenant policies and shows up in the admin inventory. End users find all of them in a single portal, managedapps.cloud.microsoft.

For anyone building portals, one important detail: these apps don't live inside a SharePoint page. They live in their own runtime. They read from and write to SharePoint, but they aren't SharePoint.

Three ways to show a list

HTML page App in Cowork SPFx web part
Who builds it Any author, or Copilot Any user, with Cowork A developer
Data List, Excel, CSV, read only 1,500+ connectors, read and write Any API, read and write
Knows who's using it No Yes, through Entra ID Yes, through SharePoint context
Where it lives Site Pages, inside an iframe Its own runtime, outside SharePoint Inside the SharePoint page
The code No code to maintain React, read-only in Cowork Yours, in your repository
License to use it None Power Apps Premium or credits None extra
Maturity Preview, GA between November and December Frontier preview Available for years

The part the demo doesn't sell: the admin

The most interesting part of the video isn't the app. It's the last four minutes.

The Microsoft 365 admin center gets a new section, Apps, with an inventory of every managed app in the tenant: who built it, when, whether it's active, how many daily users it has. For each app, admins see which connectors it uses, set alerts on open success rate, load time and number of launches, and can block or delete it.

There's also a baseline of allowed connectors that Microsoft sets by default and admins can trim, a policy that decides whether apps can be shared with the whole organization or only with chosen people and groups, and a content security policy that controls where the app can be embedded and which external resources it loads.

And here's the detail worth the whole article: each app is built in its creator's personal developer environment, using Power Platform environment routing. If the tenant has no routing rule configured, Microsoft applies a default one.

Translation: in a company where nobody has ever opened the Power Platform admin center, the day Frontier is turned on every person gets their own workshop for building apps, with the settings Microsoft picked for them.

The fine print

  • Using the app costs money. Whoever runs it needs Power Apps Premium or Copilot Credits. With credits, every launch is charged and every API call consumes 0.1 credit. Without enough credits, users get a warning and are blocked after 20 operations or five minutes of use. And building the app is a Cowork task, which comes with its own taxi meter.
  • The code doesn't easily leave Cowork. The SDK works with Git, in a platform-managed repository or your own, as long as it belongs to an organization on GitHub Enterprise Cloud. Azure DevOps isn't supported. What the documentation doesn't yet clarify is whether an app born in Cowork can be moved into that workflow to keep editing it in code. Test it before promising it to a client.
  • The link is a key. Microsoft warns that anyone who gets the link can open and use the app, including all its data. Sharing an app means opening a door to the list.
  • It's preview. Frontier means capabilities may change, or may not reach general availability the way they look today.
  • The app is only as good as the list. A list with free text in the status and health columns produces a nice-looking app that filters badly. Information architecture is still human work.

Where it fits

For an afternoon prototype, a team dashboard or the tracking app that today lives in an Excel file passed around by email, it's hard to think of anything faster. On that ground it competes head-on with Power Apps canvas, and it does it through conversation.

For anything that has to live inside the portal, sit alongside other web parts, last for years under version control or integrate with systems that have no connector, SPFx is still the answer. Because of architecture, not habit.

The point

In a matter of weeks, Microsoft showed two ways for Copilot to build things on top of your SharePoint data. HTML pages look. Cowork apps look, write and know who's on the other side. The gap between the two is the same as the gap between a report and a system.

And systems, even when they're born from a prompt, need an owner, a budget and rules. Microsoft shipped the governance tools on the same day as the feature. What doesn't come included is the decision to use them.

Is your organization about to turn on Frontier, or already testing Apps in Cowork? Let's talk at macareno.net before the inventory fills itself up.

Sources

Share article

Next business step

Connect this article with a relevant service and a real MacarenoNet case to move from insight to execution.

Recommended service

Automation with Power Platform

Flows, apps and analytics to accelerate delivery and decisions.

View service

Recommended case

Electronic Document Management

Document management with workflows, validity control and KPIs.

View case