Copilot Managed Runtime (III): everything at the click of a button

ℹ️ In collaboration with Ana Estigarribia

In the second part about managed apps and Copilot Managed Runtime (CMR), we looked at the options available to take control: temporarily blocking access, limiting who can create, configuring routing and policies, and controlling consumption.

But we left two questions unanswered. Deciding who can create and under what rules is only one part of governance. We also need to know how much an application consumes and what happens to it after it is published.

So, let us complete the journey that started with that click with the two pieces we still need to cover: consumption and monitoring.

Let us start with the first one.

How is all this paid for?

To answer that, we need to separate two moments that may appear to be part of the same experience but are managed and billed differently: building the application and running it. What the maker consumes while building is one thing; what people consume when they run the application is another.

Build: while we are building

Here we are referring to the actions the maker performs to create, generate, test and publish the application. Consumption depends on the entry point used:

• From Copilot Cowork, the maker needs a Microsoft Copilot licence and Copilot Credits associated with their Cowork spending policy.

• From Copilot Studio, building consumes Copilot Credits through the environment’s existing Copilot Studio billing. Billable activity begins during creation and includes natural-language authoring, testing and evaluation.

• From the Copilot Managed Runtime CLI, creating, building and deploying do not consume Copilot Credits for building. The CLI can be used directly or through tools such as GitHub Copilot. In the latter case, code-generation assistance depends on the GitHub Copilot licence. Running the application locally falls outside this development coverage and is considered runtime.

Although all applications ultimately run on the same runtime, their build phase is not necessarily funded from the same place.

Runtime: when the application runs

Runtime begins when someone opens and uses the application, including when it is run locally from the CLI. Microsoft provides two coverage options for using it:

• Power Apps Premium, which covers execution without consuming Copilot Credits. API calls count towards the daily Power Platform request limits associated with the licence.

• Copilot Credits, managed through spending policies and per-user allocations in the M365 Admin Center.

If the application uses services with their own billing, such as Work IQ APIs, those services retain their own metering. Likewise, API calls that exceed the daily Power Platform request limits associated with Power Apps Premium are billed through Copilot Credits.

But what does “consume” actually mean?

Copilot Managed Runtime measures application usage in API calls. Examples documented by Microsoft include launching the application, publishing a version, and performing read or write operations through connectors. According to the documentation, as of this article’s publication date, each API call consumes 0.1 Copilot Credits.

Therefore, to estimate consumption, it is not enough to look at how many people will use the application. What the application does and how many operations it needs to do it also matter.

Sharing does not mean being able to run the app

We have created the application, everything is properly governed, and we decide to share it with someone. Can they use it?

There is one thing we need to be clear about:

Sharing ≠ licensing ≠ access to data

Sharing an application, being able to run it, and accessing its data are separate decisions. Someone may receive the link and still lack runtime coverage or permissions for the data sources used.

• Application access. Sharing grants access to the resource. It does not automatically provide the coverage needed to run it.

• Runtime entitlement. The user needs to be covered by Power Apps Premium or Copilot Credits to run the application.

• Data access. Each recipient needs the appropriate permissions for the sources used by the application.

We can deliver the link correctly and still find that the person does not have the coverage required to run the application or cannot access one of its data sources.

And there is another important lifecycle consideration: removing access to the application and removing permissions to its data sources are not the same operation either.

So, governing sharing means looking beyond the Share button.

And... where can I find all those managed apps?

Let us return for a moment to the scene where this series began.

Someone clicks a button → A PDE appears → An application is created → It is shared → It is used → It generates consumption

For the team responsible for governance, this leaves a perfectly reasonable question:

Where can I see the managed apps that have been created and monitor their activity and consumption?

And this brings us to the second piece we still needed to cover: monitoring. To start with, we can find them in two admin centres:

In the Power Platform Admin Center (PPAC)

You can view them under Manage → Inventory and filter by“Item Type = Managed App”.

When you select one, you can review information such as owner, identifier, environment details, connectors, active users and sessions.

This allows us to locate the applications and understand where they are and what governance they inherit.

In the M365 Admin Center (MAC)

You will find them under Apps → All apps.

You can view information similar to that available in PPAC, but there is also a Monitor tab with additional metrics such as open success rate, time to inactivity, data request success rate and latency. We can also configure custom alert rules and block or delete applications.

Inventory tells us what exists. Monitoring helps us decide what to do with it.

And that brings us to the end of the story of our maker’s innocent click on the App button in Copilot Studio. Three chapters later, we know there was much more behind it than just an app: environments, routing, policies, permissions, credits and monitoring.

And remember: governance is not about preventing the click. It is about being prepared for everything that comes after it.