Apps have been reimagined!✨ Yes, once again. This time it’s a bigger change than those earlier preview / Frontier experiences like Power Apps Vibe Apps and the App Builder agent for M365 Copilot that I’ve been criticizing in my past newsletter issues. Like this one from July where I concluded that all the GUI-based attempts at leveraging AI for app development have been less impressive while the areas with code-first tooling have shown real potential:

Now, with the arrival of Managed Apps, we practically know that both Vibe Apps and the App Builder agent experiences are dead. Microsoft’s V2 take on this is more sensible in many ways and seems to go far beyond the isolated experiments of the earlier AI app generators. To understand the full meaning, we’ll need to once again look a bit deeper into what’s cooking in the cloud kitchen.

It wouldn’t be a Microsoft product if it didn’t have many names for the same thing. While I’ve chosen the technical name Managed Apps, you won’t find that in Ryan Cunningham’s announcement blog post “Build apps in Copilot Cowork and Copilot Studio”.

Similarly, in the Microsoft 365 admin documentation, it’s referenced merely as “apps”. Which of course is the worst possible name for finding any instructions online. Meanwhile, the GitHub repo at /microsoft/managed-apps/ says “Microsoft Managed Apps is in public preview”. As usual, the terminology can (and probably will) change by the time the preview phase ends. When exactly that might be is anyone’s guess since none of these things appeared on the AI at Work roadmap during the time of writing.

So, what is it really about? In short, the apps themselves are full-stack apps built on open standards with Git-backed source control. The kind of React apps you might have already built with Power Apps Code Apps. What’s new is how these apps are now expanding beyond Power Apps, aiming to capture a broader audience of Copilot users. At the same time, Managed Apps are leaving behind the Dataverse-based solutions model and ALM dependencies. Regardless of all this, they still share a lot of the same tooling and concepts such as connectors and environments that you know from Power Platform.

Since the emphasis is on the word managed, it’s only fair we start the tour from the management interfaces. Then, we’ll build an example app, look at the end-user experience (and licensing). Finally, a few words on the developer impact that Managed Apps introduce.

Microsoft 365 admin center is where all the new controls are published. The brand new Apps menu invites us to “look after every managed app in this tenant—see which apps are used the most, identify and resolve performance issues, and pull the data you need to make informed decisions.”

What does the “All apps” page cover then? Just like with the agents views earlier, you’d be mistaken if you assume all artifacts from Microsoft’s business cloud would be covered. Here’s a table from the docs:

So, it’s a net-new portal page that shows all the new stuff, some of the old stuff that’s visible also on another page (integrated apps), and none of the business apps Microsoft cloud customers have traditionally built and used. There are no signs of MAC replacing PPAC in the near future, so we get to enjoy these two alternative portals.

The core sales pitch for Managed Apps seems to be aimed at M365 admins who found the Power Platform side too complex and scary. This time, the promise from Microsoft is that things are already under control by default without having to establish and configure any governance model.

Is it true? Well, things certainly are more preconfigured than when starting with Power Apps back when canvas apps were gaining popularity. Because Microsoft has spent plenty of time and money in building the enterprise-ready governance tooling for Power Platform, they now have the existing technology and lessons learned to leverage in this Managed Apps rollout.

A Default Environment Group exists for every tenant when you open the Apps settings in MAC. In these early Frontier days, you can’t actually add more custom groups yet. In the group rules we find a place for configuring connectors and MCP servers. The default rule includes 29 allowed connectors/MCPs and if you go and edit it, there won’t be any automatic updates from Microsoft anymore. Since we don’t yet have a way to create multiple rules, I won’t dare to touch this setting myself.

The moment Power Platform admins see the words “Default Environment Group”, I’m sure many will be screaming in their minds: “NOOO!!! DON’T TELL ME YOU’RE PUTTING THINGS IN THE DEFAULT ENVIRONMENT AGAIN!!!” Relax, things ain’t as bad as they used to be. These new apps aren’t landing in the Default Environment we know and loathe.

Where do they go then? Well, it’s sort of simple and very complicated at the same time. Managed apps will follow an existing default environment routing rule if the customer tenant has enabled it and is using managed environments (with premium license requirement for everything) to give each maker a safe developer environment to build in. If such a rule is not in place and managed environments aren’t being applied, a routing process defined by Microsoft will be used anyway.

What this creates is an interesting Schrödinger's environment that is and isn’t Managed at the same time. The new environments won’t have Dataverse provisioned by default. However, “Dataverse is automatically added to the personal developer environments created for apps when a maker visits a Power Apps or Power Automate maker surface and explicitly selects the environment or is routed to it by an admin's routing configuration.” Which will immediately change the premium licensing requirement for said environment!

The environment routing documentation page is one of those articles that makes you head hurt:

There will be other entry points for building Managed Apps in the future, but Cowork was the first place where this skill landed on. If you’re in the Frontier program, typing /app should be enough to get started:

If your prompt is clear enough, Cowork will just get to it and one-shot a new app without asking any further questions:

The end result from my first test for generating a Newsletter Pipeline Tracker app was certainly better than the M365 Copilot App Builder agent experience last November. Which is an entire lifetime away when it comes to coding agent capability development. The timeline and the article list UI resembled what one would expect from an AI app generator these days:

It’s worth stressing that Cowork just went ahead with the visible UI part without paying much attention to the data side. “Your data is stored in your browser on this device, which is fine for solo use.” I see... I wouldn’t call a browser local data store fine for anything you really care about, so I asked Cowork to move the data to a shared list — without being any more specific about the technology. The options presented were interesting:

Cowork was able to use MS Graph to read things from the tenant but not create new resources like SharePoint lists. Presumably a Frontier limitation, given how the underlying framework clearly intends to make this happen. Nevertheless, it is again a much better outcome than the repeatedly failing attempts of the App Builder agent (R.I.P.) to provision new SharePoint sites for every app it generated and failing miserably. I’ll pretend I didn’t see Cowork suggest storing the data in an Excel workbook stored on SharePoint for this demo app.

There never was a user-facing portal dedicated to showing all the Power Apps available to the logged-in user. Once Microsoft decided to kill the home.dynamics.com page for Dynamics 365 customers in 2020 and redirect everyone to office.com (which later turned into Copilot chat in 2025), finding your apps became a ridiculously tough problem. I wrote about this challenge five years ago and I don’t think things ever improved. At one point I even had a meeting with Microsoft interns who had been given a task to build a Power Apps home page. I don’t think their Figma mockups ever got very far. All in all, it’s a bizarre self-inflicted wound in the app story for Microsoft cloud.

This time it’s different. There’s a proper home page for Managed Apps users, not just makers. Which is of course easier since all the building is now done via AI chats, not requiring big maker portals like with Power Apps. Every user can log in to managedapps.cloud.microsoft to view apps they’ve built or the ones others have shared with them:

Does merely sharing the app with another user allow them to work with it? Of course not, since the app layer has been disconnected from whatever databases there are behind the connectors. So, whether your app leverages SharePoint, Dataverse, or any of the other 1k+ connectors, you’ll have to remember to design the app’s security model and also grant the necessary permissions to users separately.

Let’s then talk about my favorite topic: licensing! While it’s clear that building these apps will cost Copilot Credits, given their Cowork / Copilot Studio entry point, what’s more novel for Microsoft is that using these apps will also cost credits. If the user to whom you’ve shared access to the app doesn’t happen to have any quota left in their Copilot Credits allocation for the month, a warning banner will be shown, and eventually the app becomes unusable.

How much will using these apps then consume Copilot Credits? That’s the burning question for which we don’t have an exact answer. The latest Copilot Credits Guide contains the following illustrative example that puts the cost for “host, run and manage an app” between 10 and 5000 credits per app per month. We have no further details on what specifically it is that determines the cost here.

It’s important to note that if the users already have a Power Apps Premium license, there should be no cost from running the app. Except if it’s using some metered capability like Work IQ, which will then require additional credits to be available for spending.

Are Managed Apps only for citizen developers who prompt their Copilot to build and modify simple apps for them? No, there’s no reason for Microsoft to restrict them in such a way. It’s all built on commonly used app development tooling anyway. Making it only accessible to the proprietary agent experiences would be repeating the same mistake as with the earlier AI app builder experiments and Copilot sidecars.

There is a preview of the Microsoft Managed Apps Plugin that you can already install from the GitHub repo for your Claude Code or GitHub Copilot:

After you use PAC CLI to flip the tenant setting powerPlatform.powerApps.enableManagedAppsCliPreview from off to on, you’ll be able to ask your coding agent of choice to build and deploy a Managed App for you. Claude Sonnet 5 had no problems figuring out what the necessary steps are for getting a static demo app running in Microsoft’s managed platform in a few minutes.

I then proceeded to test the available connectors. When testing how easily Lovable could connect to SharePoint document libraries (see the “Making SharePoint More Lovable” video for details), I had one-shotted a cool app for browsing and searching conference decks. Since that app’s code lives in a GitHub repo, I pointed my Claude at it and said “build something like this but as a Managed App”. After some back-and-forth, a basic app pulling data from a SharePoint site was in place:

I did have to drop a lot of features from it that Lovable supported just out of the box to get it working (AI summaries etc.). Even showing thumbnails for the documents was out of the question, thanks to a stricter content security policy in Microsoft’s environment. Yet for a preview product without official docs, this was an encouraging outcome.

As mentioned, nothing here relies on Dataverse and solutions. The app was built directly into the Microsoft-hosted Git repo via Claude and I just pulled the code into a local folder so I could observe it. Despite some hurdles with the Git Credential Manager, this was very simple when compared to the fights I’ve had with the native Dataverse Git integration and getting coding agents to understand how and where to access things.

As long as everything you need to build your app can live inside Managed Apps, things could be quite straightforward. If, on the other hand, you’d need to combine existing Power Platform solution components (beyond connections) into your app, I’m not sure what the intended model would be. Even if Managed Apps were to become visible as components inside the Power Platform environment, you would have a different ALM story at least. There are traces of “Managed Projects” inside the /microsoft/managed-apps/ repo code that may indicate the future direction of app lifecycle management.

First of all, I am delighted to see Microsoft investing in something new where the outcome is not an agent! Even if in the future we’d delegate many tasks to our AI assistants that operate across multiple systems and never touch a GUI, this does not remove the basic need that we humans have to see things with our own eyes to make sense of them. This means business apps aren’t going to suddenly vanish. Monolithic “one place for all data” type of enterprise apps as the common UX for every employee are going to become less relevant, though.

Managed Apps are not an entirely new construct from a technical perspective in the Microsoft cloud. It is rather an evolution of Power Apps Code Apps. We can see from the commit history of the plugin repo how the Power Platform / Power Apps branding was removed from it in June:

It’s way too early to give advice on when and where to use Managed Apps vs. Code Apps. All of the terminology as well as the commercial model can still change overnight in the coming months. While the usage of Copilot Credits will naturally give a Microsoft licensing geek like me a lot to write about, the bigger impact will be in if and how the new positioning of Copilot will commoditize app creation across the Microsoft 365 user base.

Many Power Platform / Dynamics 365 professionals may not like the idea of just anyone casually prompting Managed Apps into existence via Copilot Cowork. We have lived in a world where carefully planning the solution architecture and honing the platform-specific details has been a key part of our craft. And now someone might come and say “I could just build all that with my Copilot during this meeting” when we suggest such activities would be necessary in a business apps project. That someone could even be a M365 pro who doesn’t have experience on the BizApps side but knows their way around all things related to Copilot.

The lines between what is and isn’t part of Power Platform are blurring even further. It’s happening in the MSFT org structure, the comms, and the product packaging. This can lead to positive outcomes in the long run, yet often the journey to get there will go through clouds of uncertainty and confusion.