Arrow keys, scroll or swipe to navigate · press S to search
PP
Reference deck · Microsoft AI Business Solutions

Governance ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣for
Power Platform and Copilot Studio

The collection of what works, built from governance engagements with Danish customers across pension, utilities, telco, pharmaceuticals and manufacturing. Backed by more than six years with Microsoft Power Platform, including leading global development for Apps & Agents.

This is not a sequence to run from beginning to end. It is a reference work you pick from.

Maturity Operating model Environment zones Managed Environments DLP ALM Agent governance Credits and consumption Anti-patterns
Press S to search across all slides · click a chapter name at the top to jump directly there
The whole deck on one slide

Twenty ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣seven chapters. Click one to jump straight to it

Every chapter stands on its own, so any order works. The number on the right is how many slides that chapter holds. Nothing here needs to be read in sequence.

Three ways to navigate: click a chapter above, click a chapter name in the top bar, or press S to search every slide by word.
02
Symptom wall

Point ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣at what you recognise

Twelve situations. None of them are criticism. They are the most common places where missing structure first becomes visible. Click the ones you have seen in your organisation.

Selected: 0 of 12The marked fields point to the chapters that will pay off first. Click a chapter to jump there
03
How to use this deck

Built ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣to be picked from

No customer should see every slide. Each slide is written so it can stand alone and be used out of context, without missing the necessary context.

Search with S

Press S or / anywhere. Type for example routing, DLP, credits or pipeline. Arrow keys select, Enter jumps there

Chapters at the top

Twenty seven chapters. Click the name to jump to the first slide in that chapter, or use the clickable index on the previous slides

Self contained slides

The most important concepts follow the same structure: what it is, why it matters, what Microsoft's default is, and what we recommend

The most important thing on every concept slide: the difference between Microsoft's default and the recommended setup. Customers almost always believe that the platform's standard setting is the safe setting. It almost never is, because the standard is chosen to get people started, not to protect a group of companies.
04
The core of the whole deck

Governance ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣is not control.
It is speed with boundaries

The hardest conversation in any governance engagement is not technical. It is about what governance is for. Two organisations can have identical policies and disagree completely about what they are meant to achieve.

The control readingGovernance is a set of restrictions that must stop people from making mistakes. Success is measured by nothing happening
The sustainable readingGovernance is the frame that makes it possible to say yes quickly. Success is measured by how quickly a new solution can reach production safely
The resultEverything needs approval. The queue grows. The business finds a way around it, and shadow IT moves into tools you cannot see
The resultMost things are allowed within known boundaries. Only what leaves the frame needs approval. The queue is short because it is designed to be short
Zero incidents is not proof that the setup is safe. It may just as well prove that the rules have been so tight that the platform was never used.
05
The questions a model must be able to answer

Ten ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣questions. The answers must be names and numbers, not opinions

No matter how large or small the organisation is, the same ten questions apply. A governance model is complete when there is a name or a number next to each of them. If you cannot do that, you have an opinion about governance, not a model.

Ownership
Who owns the platform, and who may say no
Environments
Where do you build, where do you test, where do you run production
Access
Who may create an environment, and who may build in it
Data
Which connectors may talk to each other, and where is the boundary
Deployment
How does something reach production, and who presses the button
Agents
Who approves an agent, and who is its human owner
Cost
Who pays for licences and consumption, and who sees the bill
Overview
Where is the list of everything that is running
Lifecycle
What happens to a solution if the owner resigns
Cadence
How often does someone look at it, and who sends the invitation
Use them as the opening. Ask the ten questions out loud in the room and note how many are answered with a name rather than an opinion. That number is the real maturity, and it is a faster measurement than any model.
06
Sequence

Four ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣layers. From the bottom up, every time

The most common mistake is to start at the top, because the top is the visible part. A dashboard over solutions is useless if there is no environment structure to read it into.

Layer 1

Foundation

  • Environment strategy and zones
  • DLP and connector policy
  • Who may create environments
  • Default environment cleaned up
Layer 2

Control

  • Managed Environments
  • Sharing limits and routing
  • Solution checker
  • Licence and capacity
Layer 3

Delivery

  • Solutions from day 1
  • Pipelines for deployment
  • Naming and ownership
  • Agent approval
Layer 4

Overview

  • Inventory of everything
  • Consumption and credits
  • Cleanup and archiving
  • Quarterly review
Layer 1 can be set up in a week. Layer 4 takes a year to make run by itself. That is why the sequence matters: each layer rests on the previous one, and there is no shortcut from 1 to 4.
07
Chapter 02

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣landscape

What the platform consists of, where the data sits, and why Copilot Studio has made governance a conversation that cannot be postponed.

Power AppsPower AutomateCopilot StudioDataverseConnectorsAgents
What the platform is

Five ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣products, one foundation

Governance often falls apart because the organisation governs each product separately. They share environments, connectors, identity and data layers, so they must be governed as one platform.

Power Apps

User interfaces. Canvas apps for fast solutions, model-driven apps for processes on Dataverse

Power Automate

Automation. Cloud flows for integration, desktop flows for RPA against systems without an API

Copilot Studio

Agents. Instructions, knowledge and tools, orchestrated generatively. This is where the governance conversation typically starts today

Power Pages

External websites on Dataverse. Together with customer facing agents, the part that most often faces the outside world

Power BI

Analytics and reporting. It has its own licence and capacity model, but shares tenant and data sources

Dataverse

The shared data layer. Tables, relationships, security roles and audit trail. The foundation, not a sixth product

They share three things governance is about: the environment they run in, the connectors they call, and the identity they run as. Govern those three, and you have governed most of it.
09
Three layers

Where ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣the platform sits in the landscape

Power Platform is rarely a system in itself. It is the layer between the people who need something done and the systems that own the data.

Layer 3

Experience and channels

Microsoft Teams and OutlookMicrosoft 365 CopilotWeb and self serviceMobile and fieldTelephony and voice
Layer 2

Power Platform

Copilot Studio, agents and orchestrationPower Apps, interfacesPower Automate, automationDataverse, data and securityEnvironments, DLP and ALM
This is where the governance conversation sits
Layer 1

Connected ecosystem

SAP, D365 and other core systemsSharePoint and file archivesAzure, APIs and data layersThird party SaaSOn premises systems through gateway
Governance is almost always about layer 2's access to layer 1. That is where DLP, connector policy and network pattern belong, and that is where most discussions actually happen.
10
Why now

Agents ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣have made governance current

Apps and flows have existed for years without forcing the conversation. Agents do, because they break four assumptions that all previous governance relied on.

They act by themselves

An app waits for a click. An agent can be triggered by an event and act without a human in the loop. Approval must be designed in, it does not appear by itself

They cost per use

An app costs a licence. An agent also costs consumption. That makes cost a governance discipline rather than a procurement decision

They have their own identity

An agent appears as something that can be granted access. That raises the question of who owns that identity, and who can turn it off

Knowledge is an attack surface

An agent is only as secure as the knowledge it is grounded in. If it points at a SharePoint library with overly broad access, it inherits that mistake and makes it searchable

The practical consequence: an organisation may have had Power Platform for five years without a governance model and got away with it. With agents, that does not hold, because the four points above cannot be handled after the fact.
11
Where data actually sits

Dataverse ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣or connector. Two very different answers

This is the most overlooked architecture decision in the platform, and it determines how much governance you can actually perform. The decision is typically made by a maker in ten seconds.

Data in Dataverse

The platform owns the data

  • Security roles per table and row, column security per field
  • Audit trail once turned on, who changed what and when
  • Travels with solutions and pipelines
  • Can be used as a knowledge foundation for agents while respecting access
  • Costs capacity, and requires a premium licence
Data in a connector

The source system owns the data

  • Access is controlled in the source system, not in the platform
  • Audit depends on what the source logs
  • The connection typically follows the maker who created it
  • If the employee changes job, the solution can stop
  • Cheaper to get started, more expensive to clean up
The rule that works in practice: if the solution has its own data that no other system owns, it belongs in Dataverse. If the solution reads or writes in a system that already owns the data, it should stay with the connector and not create its own copy.
12
The connection everyone forgets

A ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣connection is a person's access

This is the single failure that explains most operations outages in mature Power Platform installations. It is trivial to explain and almost never handled.

What happens
A flow or an app calls a system through a connection. That connection was created by a human and runs with that human's permissions. The flow does not have its own access, it borrows one
Why it matters
When the person changes department, loses a licence or leaves the organisation, the solution stops. Often without an alarm. Sometimes it is only discovered when an account or a report is missing
Microsoft's defaultThe connection belongs to the maker who created the solution. There is no automatic warning when that maker is deactivated
RecommendedCritical solutions run on a service account or an application user, not on a named employee. Define for yourself what critical means, and make it a condition for production
Test it
Ask the question out loud: if the strongest person in the platform team resigns on Monday, what stops working by Friday? If nobody can answer, the answer is probably more than anyone wants
13
Chapter 03

Five ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣years at Novo Nordisk

Five learnings from building decentralised development capacity in a global, regulated company. They are all about the same thing: the technology changed, but the capabilities beneath it did not.

The journeyCore claimFive learningsThe bridge to agents
Background

Five ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣years making decentralised development able to deliver

This is not a product demonstration. It is what it took to move a global, regulated company from an approval decision to a capability that could deliver in operations.

1
2021 · Platform approval

Supplier and platform through the formal process. No solutions yet, but a foundation that could be built on

2
2021 Q4 · First pilot

Licences for research and development. A bounded area with real problems instead of a broad rollout

3
2022 · Real buy in

Investment and agreement in place. This is where the work shifts from convincing to delivering

4
Today · Global capacity

People, platform and operations. Not a project, but a function that runs

The point worth taking with you: it took about a year from approval to the first pilot, and another year before there was real buy in. Capacity is built through many concrete deliveries, not through a decision. That is also why it cannot be bought all at once when agents suddenly become urgent.
15
Core claim

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣agent race does not reset the maturity clock. It reads it

This is the single most important sentence from five years of work, and it is uncomfortable because it removes the hope of jumping the queue.

The hope

AI is a new start

  • Everyone is equal because the technology is new
  • We can skip the boring years
  • A tool choice can replace a capability
  • Those who were behind can overtake now
Reality

AI is a stress test

  • Agents use the ALM you already have or do not have
  • They inherit the sharing you have already cleaned up or have not cleaned up
  • They require the ownership you have already defined or have not defined
  • Those who were behind discover it faster than before
That is also the good news. If you have built the capability, agents are a new layer on top of something that works, not a new discipline from scratch. Most of what makes agents hard are things a mature platform organisation has already solved once.
16
Learning 1

Organic ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣adoption cannot carry the direction alone

Enthusiasm creates demos. It does not create operations ready solutions, and it certainly does not create a direction. Adoption requires architecture that is just as deliberate as the platform itself, and that was the learning that took the longest to accept.

Community

Makers, champions, patterns, peer review and a place to get help. Without a platform, it creates spread without control

Context

Processes, compliance, data, domain knowledge and prioritised problems. Without context, impressive solutions are built for the wrong problems

Platform

Environments, ALM, identity, integration, policy and telemetry. Without community, it becomes an empty control surface that nobody uses

Training

Product understanding, test, responsibility, operations and safe use. Not only how to build, but also what you owe afterwards

Programmes came and went. The four capabilities remained. That is why they are useful as a checklist: when something does not work in an adoption effort, you can almost always point to one of the four that is missing. And the one most often missing is context.
17
Learning 2

There ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣are not several golden paths. There is one happy path

The distinction between citizen development and professional development is an organisational construct, not a technical one. It creates two processes, two quality levels and two kinds of ownership, and it is worth giving up.

1
Idea

Everyone may raise a problem

2
Triage

Value, risk and reuse

3
Build

Maker, fusion team or developer

4
Validate

Test, security and ownership

5
Deploy

Controlled deployment

6
Operate

Measure, support and learn

Same path, different weight. It is not who builds that determines the weight of the process, it is risk. A read agent for five people and an agent that creates financial postings should not pass through the same gate, even though they follow the same path. Business understanding is just as necessary for good software as technical skill, so maker and developer are not competing camps.
18
Learning 3

Organise ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣around the delivery, not the technology

There should not be an AI department and a Power Apps department. The mandate is neither AI, platform operations, software development nor automation. The mandate is the finished solution, both strategically and operationally.

Product

The agent, the data, the integration, the user experience and a clear boundary for what the solution is and is not

Change

The process, the communication, the training and the new work habits. The part that is most often omitted, and that decides whether something gets used

Operations

Ownership, support, measurement, improvement and eventually retirement. A solution without a retirement plan is never closed

One solution. Same lifecycle. Same ALM. Whether it is called app, flow or agent. That understanding is what keeps lifecycle and ALM connected across technologies, and it is also what stops agents becoming a new silo project next to the existing one.
19
Learning 4

A ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣safe zone does not free anyone from responsibility

The biggest risk in decentralising development is not a missing fence. It is a fence that makes people believe the responsibility belongs to someone else. Decentralised development requires decentralised responsibility.

The zone as responsibility avoidance

What happens by itself

  • "I am safe because I am in the right environment"
  • Responsibility stops at the zone boundary
  • Platform operations inherit every exception
  • Nobody feels responsible for the individual solution
Policy as shared contract

What must be built deliberately

  • DLP and approval lists define the boundary
  • Environment groups scale the rules
  • The maker owns their solution all the way
  • Responsibility follows the solution, not the environment
Environments are lifecycle and isolation. They are not the compliance contract. In the agent world this becomes even sharper, because data sources, connectors, tools and identities must be explicitly governable, and ownership must stay with the solution. An environment cannot carry responsibility.
20
Learning 5

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣cheapest capability lift you will ever buy

This was the least expected learning. We built an adoption engine to bring apps and agents to life. What we actually got was something else.

What we thought we were building

A capability to deliver apps, flows and later agents. Measured in number of solutions, number of makers and time saved

What we actually built

A training programme in business understanding. People learned to define a problem, assess risk, take ownership and drive change, because they did it on their own work

The point for Monday: if you choose agents and digital development as your adoption track, you get the strongest school in everything that is not IT. Process understanding, prioritisation, risk assessment, ownership and change management are trained on real problems instead of on course slides. It is a gain that never appears in the business case, and it is larger than the one that does.
21
The bridge to today

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣AI layer is new. The delivery system beneath it has matured

That is the real reason Copilot Studio is a different starting point from an empty chat window. Agents land in an ecosystem that has already solved a set of boring and decisive problems.

Solution ALM

Solutions, environment variables, connection references and pipelines. Versioning and movement are solved, not invented from scratch

Governance at scale

DLP, connector policy, environment groups and Managed Environments. Rules can be set in one place and apply to many

Data and action

Dataverse, Power Automate, connectors, identity and business data. The agent can do something, not only say something

Operating model

Makers, developers, administrators and support around the same platform. One happy path, also for agents

Be precise about what mature means. It does not mean finished. Agent testing, evaluation and AI specific risk management still require capabilities most organisations do not have yet. But they are not starting from zero, and the difference between starting from zero and starting from a mature platform is probably a year.
22
Chapter 04

Maturity⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣

A quick, honest measurement of where the organisation stands. Not to give a grade, but to decide which chapters are relevant.

Eight disciplinesFive levelsSymptomsStarting point
Core model

Eight ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣disciplines, five levels

Set one mark per row by clicking directly in the table. If the room disagrees about where a row sits, that disagreement is the most important finding of the day. Ownership appears in two places on purpose: the top row is ownership of the platform, the overview row is ownership of the individual solution.

Discipline 1 · Ad hoc 2 · Reactive 3 · Defined 4 · Governed 5 · Optimised
Platform ownershipNobody owns the platform as a wholeIT keeps it running informallyA platform owner is namedThe owner has mandate and budgetOwnership is measured on delivery
EnvironmentsEverything is built in the default environmentA few project environments have been createdA zone model is describedZones are enforced technicallyEnvironments are created and retired automatically
Data and DLPDLP has not been set up yetOne shared policy for the whole tenantPolicy per zoneConnectors classified and reviewedExceptions are time limited and logged
ALMSolutions are built where they are usedMoves happen manually between environmentsSolutions and environments are definedPipelines with approvalsSource control, tests and gates
AgentsAgents are built where the need appearsWe know most of the people who buildGuidelines existIdentity, approval and inventoryAgents are products with an owner
Overview and solution ownershipThere is not a shared overview yetFollow up happens when something failsInventory exists, and every solution has an ownerAdmin analytics in regular use, ownership is reviewedTelemetry, alerts and measured response time
CostThe cost has not been calculated yetConsumption is seen at the annual statementLicence and capacity mappedBudget alerts and consumption per areaCosts allocated to consumers
AdoptionMakers learn it from each otherA few courses have been heldOnboarding and guidelines existMaker levels, community and championsAdoption is measured and governed towards value
Random We react We have described it It runs in operations It is improved continuously
24
What the levels mean

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣difference between defined and governed

The jump from level 3 to 4 is the one that costs. Every other jump can be made with a decision. This jump requires someone to make it their job.

1 · Ad hoc
It happens, but nobody has decided that it should happen. There is nobody to ask, and nobody follows up
2 · Reactive
Action is taken when something goes wrong. Knowledge sits with individuals. It works until that person is busy or on holiday
3 · Defined
It is written down and agreed. But it is not technically enforced, so it is only followed by those who know the document
4 · Governed
The platform enforces it itself. A maker cannot break the rule by accident, because the setup does not allow it. This is where governance stops depending on discipline
5 · Optimised
Measurement exists, and the measurement leads to change. Few organisations are here on all eight disciplines, and it is neither necessary nor financially sensible to be there
The goal is not five. The goal is four on what can hurt, and three on the rest. An organisation that chases fives across all eight disciplines spends money on control it does not need.
25
From symptom to chapter

Every ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣symptom points to a specific place

This is how what was just pointed at is translated into what is worth spending time on.

Nobody owns the platform as a whole
Operating model. Mandate, budget, RACI and who may say no
Solutions without owners and abandoned assets
Operations. Inventory, one owner per solution, cleanup and what happens when an employee leaves
Environment chaos and default environment
Environments. Zone model, Environment Routing and cleanup of what already exists
Overly broad sharing and unknown connectors
Security and DLP. Policy per zone, connector classification and sharing limits
No rollback and production changes
ALM. Solutions, pipelines and the difference between publish and deployment
Unknown agents and missing inventory
Agent governance. Identity, approval, registry and who may turn it off
The bill surprised us
Cost. Licence model, credits, consumption ceilings and who pays
Long response time to an idea
Adoption. Intake, triage and why a fast no is better than a slow maybe
26
Where to start

Start ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣where it already hurts

The most common mistake after a maturity measurement is to make a plan that lifts all eight disciplines at the same time. That plan will not be completed, and afterwards the conclusion is that governance does not work.

Choose three

Take the three disciplines with the lowest level and the highest pain. The other five should not be touched before those three are at level 3

Define done

Write down how you can see that a discipline has reached the next level. Without that, an improvement becomes an opinion

Set a date

Repeat the measurement in six months with the same people in the room. The curve is worth more than the number

A warning about self assessment: organisations almost always overestimate ALM and almost always underestimate cost. If you land at level 4 in ALM, ask when a production change was last rolled back, and how long it took.
27
Your starting point

What ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣you just selected points here

This page calculates from the maturity table and the symptom wall. It is empty until marks have been set. Click a chapter to jump directly there.

Maturity profile
N/Aaverage of 0 of 8 selected disciplines
Start here, three lowest
Chapters to open
Use the spread, not the average. An average of 3 can cover eight threes, which is a healthy platform, or four fives and four ones, which is a platform with four holes that someone will soon fall into.
28
Chapter 05

Operating ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣model

Who owns the platform, who owns the solutions, and who pays. Without that answer every other rule becomes an exception.

CentralDecentralisedHybridCoERACIFusion teams
Before choosing the model

Why ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣governance often never happens

Most organisations have had a governance proposal on the table at least once. Most of those proposals are still there. There are three recurring reasons, and none of them mean the proposal was technically wrong.

Too broad

A framework that is larger than the organisation that must carry it will never be adopted. Scope is not the same as quality

Only anchored in technology

Policies, zones and DLP can be configured in a week. They only last if someone owns them afterwards

No one with mandate

Without a named owner who may say no and may spend money, governance becomes a recommendation

Question for the room: if you have previously had governance on the agenda, what stopped it from becoming real? That answer is more useful than any recommendation from outside.
30
Three models

There ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣is no single right model

The choice follows the organisation's own structure. What matters is that the model has been chosen deliberately and has not simply happened. Most organisations run centrally without deciding to.

Central

IT builds and owns everything
  • High consistency and control
  • One queue for everything, IT becomes the bottleneck
  • The business experiences the platform as slow
  • Works for a small number of critical solutions
  • Breaks down when demand increases
Most often the best fit

Decentralised

Central guardrails, distributed product ownership
  • Platform team owns framework and operations
  • Business units own their own solutions
  • Makers work within known boundaries
  • Scales without administration scaling at the same rate
  • Requires the framework to actually be in place

Hybrid

Different model by risk level
  • Critical solutions central, the rest decentralised
  • Requires a clear definition of critical
  • More rule sets to maintain
  • Good transition model on the way to a decentralised model
  • Risk that everything gradually becomes critical
The hidden cost of central: it looks cheapest because it requires no setup. It is most expensive in practice, because every single request uses a person's time, and because it pushes the business into tools you do not administer.
31
Responsibility split

Three ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣layers, three kinds of responsibility

Governance typically falls apart because the three layers are mixed together. The platform's responsibility is not the same as the responsibility for each solution, and neither of them is the same as oversight.

Layer 1

Platform governance

  • Environment strategy and zone model
  • DLP and connector control
  • Managed Environments and routing
  • Licence and capacity
  • Owned by IT and the platform team
Layer 2

Maker governance

  • Naming and documentation
  • Solution based development from day 1
  • Owner policy, no orphaned solutions
  • Onboarding and guidelines
  • Shared responsibility between IT and the business
Layer 3

Oversight and compliance

  • Inventory and audit
  • Admin analytics and reporting
  • Quarterly review
  • Reporting to risk and compliance
  • Continuous, not a project
Start with layer 1. Without it, layer 2 is a request, and layer 3 is a task with no data to solve it.
32
Decision rights

RACI ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣as a starting point for discussion

This is a proposal, not a model to approve. The value lies in editing it. R means performs the work, A means accountable and decides, C means consulted, I means informed.

Decision or taskPlatform ownerPlatform operationsSecurityBusiness unitMaker
Environment strategy and zone modelARCIC
DLP and connector classificationRCAIC
Approval of new connectorRCAII
Creation of new environmentARICI
Ownership of each solutionCIIAR
Deployment to productionRAICC
Approval of agent for productionCRCAI
Licence and capacity managementARICI
Consumption and credits per areaARIRI
Monitoring and inventoryARCII
Cleanup and archivingARIRC
Maker enablement and communityARICC
Only one A per row. Two accountable people means no accountable person. It is the most common mistake in governance models, and it is almost always the result of a compromise in a meeting where no one wanted to lose.
33
Center of Excellence

What ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣a CoE is and is not

CoE is one of those concepts that means something different to everyone in the room. The definition must be settled before you can discuss whether there should be one.

It is

A function, not a department

  • Owns the framework: environments, policies, ALM and licence
  • Delivers platform services so others can build quickly
  • Drives enablement, community and reusable patterns
  • Creates oversight and reports on risk and value
  • Can be two people with clear mandates
It is not

A build team

  • Not the place where all solutions are built
  • Not an approval body for every idea
  • Not a tool you install
  • Not a project with an end date
  • Not necessarily a full time role from day 1
About CoE Starter Kit: it is a toolkit, not a governance model. Microsoft states that it is no longer actively maintained, is not being expanded with new functionality, and that reported issues are no longer processed. It is still available, but the core functions have moved into Power Platform Admin Center as Microsoft first party functionality, and that is where they should be used from. We return to the transition in the Admin center chapter.
34
The four roles

Fusion ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣teams, and why they work

The highest performing way to build on Power Platform is not citizen development alone and not professional code alone. It is four roles around the same table with different mandates.

Business expert

Owns the problem and defines when it is solved. Has no tools, but has the only mandate that counts: to say that the solution is good enough

Maker

Builds most of the solution. Knows the business better than IT and the tool better than the business

Pro developer

Takes the 20 percent that cannot be built low-code: integrations, custom connectors, components and performance

Platform and security

Sets the framework once instead of approving every solution. Joins early rather than being a gate at the end

The most important change is the last one. As long as security is a gate at the end, it is experienced as an opponent, and makers optimise for getting around it. When the framework is set in advance, there is nothing to get around.
35
The mandate

An ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣owner without budget is a contact person

It is easy to appoint a platform owner. It is hard to give that person something to own with. Four things separate a real owner from a named contact person.

May say no
Can reject a request for a connector, an environment or a production release, without the decision being overturned somewhere else. If it can be overturned, there is no framework
May spend money
Has a budget for licences, capacity and credits. Otherwise every growth step becomes a negotiation, and every negotiation becomes a delay
Has a cadence
A fixed forum with a fixed agenda. Without it, governance becomes something that only happens when someone is unhappy
Is close to the business
If ownership is placed too far inside infrastructure, the platform is governed as infrastructure, and then operational concerns always win over delivery concerns
Test whether the mandate is real: what happened the last time the platform owner said no to something an executive wanted? If it has never happened, that is not proof of agreement.
36
Chapter 06

Ownership ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣over time

An employee leaving is an HR event with technical consequences. Deletion is not a handover plan.

OffboardingAbandoned flowsService identitiesAdditional ownersConnection references
The quiet failure

Nothing ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣breaks on the day the employee leaves

It breaks weeks later, when a connection expires and no one remembers what the flow did. It is the most expensive governance failure because it is invisible until it is not.

Data loss

OneDrive, mailbox, notebooks, Forms and Teams conversations. Deletion starts a retention clock that rarely aligns with the handover plan

Functional loss

Flows, apps, solutions and agents may be owned by the person or run under the person's connection. The failure is silent and appears weeks later

The replacement user

Group memberships, direct permissions, licences, admin roles and delegated access must be recreated. Give her the same as Priya is not a procedure

Relationships

Mailbox, calendar, customer threads, supplier contacts and meeting series. Some of it cannot be recreated afterwards

The handover

The cheapest control and the one most often skipped. It must happen while the account is still active, not afterwards

The hidden accounts

Admin accounts, test accounts and service accounts that are effectively tied to a named human. HR driven offboarding does not find them

This is not a Power Platform problem. It is an ownership problem that Power Platform makes visible, because the platform lets individuals own production logic.
38
Power Platform

Four ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣places ownership can stick to a person

Each of the four has its own mechanism and its own failure mode. They are not solved by the same action.

Flows
Use service identities from the beginning. Hand over or reassign abandoned flows. Reauthenticate every connection after handover. Repeated failures can cause a flow to be turned off automatically
Apps
Add additional owners. Canvas apps can be handed over through PowerShell. Check connections, connection references and embedded flows separately
Solutions
Always build in a solution. Owners can then be changed by an admin rather than being stuck with one person. Connection references make it possible to switch the connection centrally
Environments
Content in the default environment is not deleted when the user disappears. A managed developer environment is disabled after 60 days of inactivity and deleted 15 days later
The most important consequence: business critical automation must be placed neither in the default environment nor in a personal developer environment. One is invisible, the other disappears.
39
Agents

An ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣agent without an owner is worse than a flow without an owner

An abandoned flow fails. An abandoned agent keeps answering, and it answers with the permissions it received from a person who no longer works here.

The agent outlives the user

Published agents continue to run. If the agent uses the user's connection to a data source, it fails when the connection expires. If it uses a service identity, it continues, even without supervision

Agent 365 as registry

Ownership, approval and blocking of agents are managed centrally in the Microsoft 365 admin center, partly with an Agent 365 licence. Offboarding becomes an admin action, not archaeology

The identity must be reassigned

An agent's Entra Agent ID must have a sponsor who can explain why the agent exists. When the sponsor leaves, that is an offboarding task on the same level as an access badge

The right to turn it off

Someone must be able to stop an agent without knowing how it is built. That is an operations function, not a maker function

Question for the room: if the employee who has built the most automations in your organisation resigns on Monday, how long before you know what you have inherited?
40
Prevention

Five ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣habits that remove the problem before it appears

None of them requires a tool. They require agreement before the first solution is built.

1
Always two owners

Apps, solutions, agents, Teams, SharePoint sites and Microsoft 365 groups have at least two owners. Not because the second one does anything, but because the second one can

2
Service identity for production

Everything that runs without a user in front of the screen runs on an identity that cannot resign

3
Connection references everywhere

The connection is separated from the solution. Then it can be changed centrally without opening every single flow

4
Offboarding with a platform step

The existing offboarding process gets one new step: which apps, flows and agents does the person own, and who takes them over. That step must happen while the account is alive

5
Abandoned resources in the cadence

Ownerless resources are reviewed on a fixed cadence, not when someone discovers a problem

41
Chapter 07

Environment ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣strategy

The environment is the boundary where technical governance takes effect. Environment groups set it consistently across many environments at once.

ZonesDev, test, prodDefault environmentRoutingEnvironment GroupsNaming
The basic concept

What ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣an environment actually is

Most governance discussions stall because the room does not share the same picture of what an environment is. It is not a folder and not a tenant. It is a boundary.

What it is
An isolated container with its own apps, flows, agents, connections and optionally its own Dataverse database. The environment has its own access control and its own geographic location
Why it matters
The environment is where DLP policy, Managed Environments, sharing and deployment take effect. Environment groups do not remove that boundary, they set it consistently across many environments at once and lock it locally
The consequence
Every time someone says "we would like different rules for these two things", the answer is almost always two environments. And every time someone suggests a new environment, the question is which rule needs to be different
The costly mistakeToo few environments, everything in default. No separation between what is being experimented with and what the business depends on
The other costly mistakeToo many environments, one per project. Capacity and licences are spread out, no one has oversight, and cleanup becomes impossible
43
Two axes that get confused

Zone ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣and stage are not the same

The most frequent source of confusion in environment design is that two completely different divisions are blended into one. You need both, but they answer different questions.

Axis 1

Zone: how much may happen here

  • Answers risk and reach
  • Green: experiments, no production data, no shared solutions
  • Yellow: departmental solutions, known connectors, limited sharing
  • Red: business critical, strict DLP, only deployment through pipeline
  • Determines DLP policy, sharing limits and approval requirements
Axis 2

Stage: where are we in the lifecycle

  • Answers maturity of the individual solution
  • Dev: building happens, it is allowed to break
  • Test: verification happens with realistic data and real users
  • Prod: running happens, no one builds directly here
  • Determines pipelines, approvals and who has write access
The two axes are combined. A red zone typically has all three stages. A green zone has only one, because nothing real ever runs in it. Blend them together, and you end up with an environment called Test that the business uses in production.
44
The zone model

Segment ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣by risk and reach

Not by department and not by technology. A zone is a combination of who the solution reaches and what happens if it fails.

PropertyGreen zone · Safe innovationYellow zone · CollaborationRed zone · Enterprise
PurposeLearning and experimentsDepartmental solutions and team solutionsBusiness critical operations
DataTest data, no personal dataReal data in known scopeFull production data
Who may buildEveryone with a licenceApproved makersOnly appointed development team
DLP policyStrict, only non sensitive connectorsBusiness connectorsNarrow, approved list
SharingOnly the ownerSharing limit, not the whole organisationThrough security group
Premium connectorsNoAs needed and licensedYes, approved per solution
DataverseRarelyOftenYes
DeploymentNot relevantSolution export or pipelineOnly through pipeline with approval
Managed EnvironmentYesYesYes, with solution checker
CreationAutomatic through routingOn requestRequires change
LifetimeDeleted after inactivityFollows the solutionPermanent, with owner
Without active safeguards, all environments behave like the yellow zone. Green zone is not a default state, it is the result of configuration. The same is true of the red one.
45
The highest priority task in almost any tenant

Default ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣environment is everyone's environment, and therefore no one's

Default environment exists in every tenant from day one. Everyone with a licence can build in it, it cannot be deleted, and it is hard to clean up afterwards. It is almost always where the largest undiscovered risk sits.

Why it happens
This is not anyone's mistake. The environment was created to get people started without friction, and it succeeds. The problem is that nothing moves the solutions out again when they become important
Microsoft defaultAll licensed users can create apps, flows and agents. The environment is usually named only after the organisation, so it looks like the official place to build
RecommendedRename it to something that signals what it is, for example Personal productivity, do not share. The name is the cheapest governance there is
Five concrete steps
  • Rename the environment so the name warns people
  • Restrict creation of new environments to appointed administrators
  • Remove sharing with the whole organisation from existing apps
  • Turn on environment routing so new makers do not land here
  • Set the strictest data policy on this specific environment
Whereadmin.powerplatform.microsoft.com under Manage, Environments and Security, Data policy
46
The model that scales

Personal ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣developer environments rather than shared build environment

When the number of makers increases, the shared development environment stops working. Not for technical reasons, but because people begin to step on each other.

Shared development environment

Everyone builds in the same place

  • Two makers change the same solution at the same time
  • An unfinished change blocks someone else's deployment
  • No one can determine who owns what
  • Coordination grows faster than the number of makers
  • IT is asked to judge conflicts
Personal developer environment

Each maker builds in their own place

  • No conflicts, no coordination cost
  • The maker can experiment without fear
  • Solutions are assembled first in test, where they belong
  • The environment can be deleted automatically after inactivity
  • Requires routing and a cleanup policy to be sustainable
The important key: personal developer environments are only a good idea if they come with automatic creation and automatic cleanup. Without that, you exchange one problem, coordination, for another, environment sprawl.
47
Three ways to structure the estate

How ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣environments are grouped across the organisation

Once zones and stages are in place, there is still a question of how environments are distributed across the business. There are three patterns, and the third almost always wins in large organisations.

Centralised

Few environments, everything gathered
  • Highest consistency, easiest operations
  • No natural cost allocation
  • Scales poorly above about 100 solutions
  • Fits smaller organisations

Per business unit

Each unit has its own set
  • Clear cost allocation and clear ownership
  • The number of environments grows quickly
  • Rule sets drift apart over time
  • Reuse across units becomes difficult
Recommended at scale

Hybrid enterprise

Shared core, units on top
  • Shared production environments for cross organisation solutions
  • Own environments where there is a real special need
  • One shared rule set, a few deliberate exceptions
  • Costs can still be allocated per unit
  • Requires someone to enforce the core
Always ask: what is the business reason for this specific unit to have its own environment? If the answer is organisational pride rather than a different rule set, a different geography or a different data category, the answer is no.
48
Environment Routing

New ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣makers must not land in default

Routing is the single feature with the highest impact relative to the effort required to turn it on. It solves the problem at the source instead of cleaning up afterwards.

What it is
When a maker opens Copilot Studio, Power Apps or Power Automate, they are automatically sent to their own personal developer environment instead of to default. If the environment does not exist, it is created at that moment
Why it matters
Without routing, every new maker lands in default environment. This is not a one time problem, it is a continuous inflow, and cleanup therefore never finishes
Microsoft defaultTurned off. All new makers start in default environment
RecommendedTurn on for everyone, or for a security group if you want to start in a controlled way. Combine it with a cleanup policy, otherwise the number of environments grows without limit
Prerequisite
The personal developer environments created by routing are Managed Environments. That must be included in the licence calculation, and that is also the point: they are governed from the first second
WherePower Platform Admin Center under Manage, Tenant settings, Environment routing
49
Environment Groups

Rules ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣on a group rather than on each environment

As soon as there are more than a handful of environments, keeping them consistent by hand becomes impossible. Environment Groups move the rule up one level.

What it is
A logical group of environments where one shared rule set is applied. New environments that join the group inherit the rules, without anyone needing to remember to set them
What can be controlled
  • Sharing and sharing limits
  • Rules for solutions and deployment
  • Backup retention and release channel
  • Solution checker and unmanaged customizations
  • Configuration of AI and agent features
Without groupsEvery new environment setup is a manual task, and deviations are not found until a review. Configuration drift is unavoidable
With groupsOne group per zone. Personal developer environments in one group, departmental environments in another, production in a third. The rule is set once
Note
Environment Groups work on Managed Environments. That is one more reason why Managed is not an add on, but what makes governance possible in practice
50
The whole picture

Tenant, ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣groups and environments

All the parts gathered on one page. The tenant sets what applies to everyone. The groups set the rule set per zone. The environments are where the work happens, and their type determines what they may be used for.

Tenant
Data policies, tenant isolation and tenant settings. Can apply across everything below, or to chosen environments
Set once
Environment Routing sends new makers down here
Group 1 · Personal developer environments
Green zone. Created automatically, one per maker
Sharing: only the owner
Deleted after inactivity
Makers
Maker A
Developer
M
Maker B
Developer
M
Maker C
Developer
M
Maker D
Developer
M
and one per new maker after that
Group 2 · Decentralised per business unit
Yellow zone. The unit owns and builds itself
Sharing limit
Deployment through pipeline
Unit A
Dev
Sandbox
M
›
Test
Production
M
›
Prod
Production
M
Unit B
Dev
Sandbox
M
›
Test
Production
M
›
Prod
Production
M
Group 3 · Central IT and business critical
Red zone. Appointed team, formal change
Solution checker blocks
Only pipeline with approval
Core
Dev
Sandbox
M
›
Test
Production
M
›
QA
Production
M
›
Prod
Production
M
Type Sandbox or Developer, may be reset Type Production, cannot be reset Runs for real users MManaged Environment, without exception
51
Who may create

Environment ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣creation is a permission, not a formality

In a standard tenant, far more people can create environments than anyone expects. It is the single setting that most often surprises a security department.

Microsoft defaultLicensed users can create production, sandbox, trial and developer environments when capacity is available. Trial environments alone are enough to move data somewhere no one is looking
RecommendedRestrict creation of all environment types to appointed administrators, and make personal developer environments the approved release valve through routing. Then there is still a route, but it is governed
Trial environments
Have a short lifetime and disappear by themselves. That sounds reassuring, but it also means a solution can be built, used and disappear, without anyone noticing it in time
The practical answer
Say yes to people getting an environment, and make it fast. A no that takes three weeks produces trial environments. A yes that takes an hour produces a governed estate
WherePower Platform Admin Center under Manage, Tenant settings, environment assignments
52
Naming and metadata

A ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣name is cheap governance

Naming feels like a detail until there are 40 environments and no one can explain what half of them are used for. The convention must be trivial to follow, otherwise it will not be followed.

Format
Organisation, business unit, purpose, stage. For example KON HR Recruitment PROD
Stage always last
DEV, TEST, PROD. Makes it possible to sort and to see immediately what is real
Personal environments
Named automatically by routing. Do not touch them, consistency is worth more than aesthetics
No person names
An environment named after an employee outlives the employee and becomes incomprehensible
Description field
Must be filled in. Purpose, owner and expected lifetime. It is the only place where context can survive a job change
Security group
Each environment is bound to a group in Entra. Access is governed in the group, not in the environment, so it follows employment
Owner
A human, not a shared mailbox. Mailboxes do not answer when a decision has to be made
Expiry date
Project environments get a date at creation. Without a date, everything becomes permanent
Test the convention: can a new colleague on their first working day read the list of environments and explain what each one is used for? If not, the convention is not good enough, no matter how precise it looks in the document.
53
Chapter 08

Managed ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣Environments

The conversation that most often ends badly. Not because the feature is difficult, but because it is presented as a cost rather than as the thing that makes governance possible.

What it isThe licence perimeterSharing limitsSolution checkerGroupsWhen not to
The basic concept

What ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣Managed Environments are

It is not another kind of environment. It is a set of administrative controls that you switch on for an environment you already have. Setup takes minutes.

What it is
A switch on the individual environment that gives administrators visibility and enforcement that is otherwise not available: who shares what, who builds, which solutions meet standards, and what is starting to go wrong
What it gives you
  • Sharing limits, limits for how widely an app may be shared
  • Solution checker enforced on import, not just as a recommendation
  • Weekly digest for administrators covering top apps, active makers and unused resources
  • Maker welcome content, your own guidelines shown inside the tool
  • Usage insights per environment, so cleanup can be based on data
  • Access to Environment Groups and rule sets across environments
The important point
Without Managed Environments, governance is something you describe. With Managed Environments, it is something the platform enforces. That is the whole leap from level 3 to level 4 in the maturity model
WherePower Platform Admin Center, select environment, Edit Managed Environments
55
The objection that always appears

No, ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣it does not cost premium for the whole organisation

The objection sounds like this: Managed Environments require a premium licence for all active users, and we cannot afford that for thousands of employees. The premise is right. The conclusion is wrong, because it overlooks who is active where.

The assumptionManaged Environments are switched on for the whole tenant, so every employee needs a premium licence
The realityManaged Environments are switched on per environment. You choose which ones. The requirement only applies to users who are active in those specific environments
The assumptionThe perimeter is the number of employees in the organisation
The realityThe perimeter is every user active in the managed environments. Start where mainly makers and developers work: typically a few hundred, not several thousand
The assumptionEverything or nothing
The realityStart by making the maker and development environments managed. That is where the risk is created. Production environments can follow later
How to do the calculation: do not count employees. Count the active users of the environments you manage. Subtract the people who already have premium through another solution. The number that remains is the real additional cost, and it is almost always much lower than the room expects.
56
Three levels

What ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣you get, step by step

This is not a choice between nothing and everything. There are three real levels, and most organisations gain the most by moving from the first to the second.

CapabilityUnmanaged environmentManaged EnvironmentManaged with groups
Environment isolationYesYesYes
DLP policyYesYesYes
Sharing limitsNoYesYes
Solution checker enforcedNoYesYes
Weekly admin digestNoYesYes
Maker welcome contentNoYesYes
Usage insights per environmentLimitedYesYes
Environment GroupsNoYesYes
Rule sets inherited by new environmentsNoNoYes
Pipelines with approvalNoYesYes
Configuration drift over timeHighMediumLow
Note the last row. Configuration drift is the quiet cost: every environment configured by hand drifts away from the standard, and nobody notices until there is an incident or an audit.
57
Sharing limits

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣control that prevents the sharing accident

The most common serious incident on Power Platform is not an attack. It is an app with sensitive data that was accidentally shared with the whole organisation.

What it is
A limit per environment for how widely a canvas app may be shared: whether it may be shared with security groups, including everyone, and the maximum number of individual people it may be shared with
Microsoft defaultUnlimited. A maker can share with the whole organisation in two clicks, and there is no approval and no notification to anyone
RecommendedSwitch sharing with the whole organisation off in every environment except those where it is a deliberate choice. Set a numeric limit for individuals in development environments
Sharing can be switched off completely
For solution cloud flows and for agents, sharing can be switched off, not just limited. In personal development environments, that is often the right choice. The environment is for building, not for delivery. If something needs to be shared, it belongs somewhere else
Important boundaries
The controls work differently per asset type: canvas apps and agent viewing are controlled with a maximum number, while flows and agent sharing can be switched off. The limit also works going forward. It does not remove existing sharing, so it must be followed by cleanup. And it does not replace DLP or access control in the source systems
The date that matters
From February 2027, users without an appropriate licence can no longer open apps in a Managed Environment. Until then they are only notified. That belongs on the roadmap, not only in the licence notes
58
Solution checker

From ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣recommendation to gate

Solution checker also exists without Managed Environments. The difference is not whether it can run, but whether anyone can choose not to listen to it.

What it is
A static analysis of a solution that finds problems in performance, maintainability and security before the solution moves on
Without enforcementThe checker can be run manually. The report is read by the maker who is already careful. The others never see it
With enforcementThe import is blocked if serious findings have not been handled. The rule applies equally to everyone, and there is no need for a discussion per solution
How to introduce it without resistance
Start in warning mode for a period, so makers see their own findings without being stopped. Enable blocking afterwards. If blocking is introduced first, it is experienced as a punishment for something people did not know
Where it belongs
Enforce in test and production. Keep development environments free, otherwise you punish experimentation, and experimentation is the whole point of a development environment
59
The overlooked controls

Three ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣things nobody switches on

Managed Environments include features that are almost never used, even though they solve problems that organisations spend meetings on.

The weekly digest

A regular email to administrators with top apps and flows, the most active makers and resources that have not been used for a while. It is the cheapest way to create a cadence, and it takes no effort to keep alive

Maker welcome content

Your own guidelines shown inside the tool when a maker signs in to Power Apps or Copilot Studio. Guidelines on an intranet are not read. Guidelines in the tool are seen

Usage insights

Which solutions are actually used, and by how many people. That is the prerequisite for cleanup, because cleanup without data becomes a negotiation with the owner

Maker welcome content is underrated. It is the only place in the whole governance apparatus where the message reaches the person at the moment when it is relevant. Everything else is communication that competes with the rest of the inbox.
60
Honesty

When ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣Managed Environments are not the answer

Recommending it for everything weakens credibility. There are situations where it does not make sense, and it is better to say that yourselves than to be caught out.

Environments without makers

A pure production environment where nobody builds and everything arrives through a pipeline gets less value from the maker controls. It can still make sense for insights, but the gain is smaller

As the very first step

If the default environment has not been cleaned up, and nobody knows who owns what, Managed Environments will not solve that. If you do not clean up first, you are buying enforcement of a mess

When the perimeter is genuinely large

If tens of thousands of users are active in those environments, the calculation is different. Then it must be handled honestly rather than talked down. It is rare, but it exists

The honest positioning: Managed Environments are not a security feature you buy in order to be secure. They are what makes an already made decision enforced. If you have not made the decision yet, make it first. That is cheaper and works better.
61
Chapter 09

Admin ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣center

Everything the other chapters describe as decisions becomes configuration in one place. The admin center is not a reporting portal. It is where the rules are actually switched on.

The eight areasThe role modelLeast privilegeTenant settingsRoutingGroup rulesEnvironment settingsAgent policyAnalyticsCoEData residencyNavigating by question
The console

Where ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣governance becomes real

Most governance efforts shine in a document and stand still in the portal. The difference between a policy and a control is whether someone has set it here.

What it is
The Microsoft portal for administering environments, environment groups, data policies, security, capacity, licences and agents across the whole tenant
Who can open it
Tenant settings can be opened by Global Administrator, Power Platform Administrator and Dynamics 365 Administrator. The latter two are the roles a platform owner typically needs, and they deliberately do not grant access to user accounts, licence assignment, Exchange or SharePoint
What it is not
It is not an audit archive, and it is not a security product. Analytics data has short retention windows, and threat detection for agents belongs in Microsoft Agent 365 and Defender. We return to both
The important point
When a chapter in this material ends with a Where, it almost always points in here. This chapter is the map for those references
Whereadmin.powerplatform.microsoft.com
63
Orientation

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣eight areas in the left menu

The portal has been cleaned up. Today there are eight functional areas, and almost all confusion about where something lives comes from looking for a ninth one that does not exist.

Actions

Recommendations for your own implementation. Security, operational reliability and general health, prioritised by the platform itself

Manage

Environments, environment groups and tenant settings. Also inventory, consumption and analytics under Products

Security

The security features collected in one place, including identity and access, tenant isolation and data policies

Copilot

Material, consumption and governance controls for Copilot and agents

Monitor

Operational health for what has been built and deployed. This is where an app that fails for users becomes visible

Deployment

ALM at scale, including pipelines and deployments across environments

Licensing

Environments that need licence attention, licence consumption and capacity add ons

Support

Self help and support case creation

The three things people always look for in the wrong place: Environment groups and tenant settings are under Manage, not separate menu items. Data policies belong under Security. Analytics is under Manage and then Products, split by product. There is no longer a standalone Analytics menu item.
64
The role model

Four ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣kinds of roles that are often confused

Most discussions about who may do what arise because two people are talking about different rows in this table. Get this in place first.

Role typeExamplesScopeAssigned where
Tenant rolesPower Platform administrator, Dynamics 365 administrator, Global AdministratorThe whole tenant, all environmentsMicrosoft 365 Admin Center
Environment rolesEnvironment Admin, Environment MakerOne environment without DataversePower Platform Admin Center
Dataverse security rolesSystem Administrator, System Customizer, Basic UserOne environment with DataverseIn the environment
Application rolesRoles from Dynamics 365 Sales and Customer ServiceOne environment with DataverseIn the environment
The two traps: tenant roles give administrative access across environments, but they do not automatically grant access to data in Dataverse. And Environment Admin applies only to environments without Dataverse. If the environment has a database, System Administrator is the full administrative role. Also note that Power Platform administrator exists both as a directory role and as a Dataverse security role with the same name.
65
The change nobody has noticed

Administrators ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣no longer get access automatically

This is the single change in the platform administration model that most often surprises an operations team. It is good news for governance, and it breaks habits.

The assumptionIf someone has Power Platform administrator, they automatically have System Administrator in every environment
The realityMicrosoft no longer assigns System Administrator automatically to global and service specific administrator roles. Access must be claimed deliberately per environment
The assumptionSelf elevation is a backdoor that undermines control
The realityAll elevation actions are logged to Microsoft Purview. That is the difference between permanent access and traceable access
The assumptionWe assign administrator roles through a security group, as we do with everything else
The realityIt does not work. Global admin, Power Platform admin and Dynamics 365 admin must be assigned directly to the user. Inheritance through groups is not supported
What they can do without elevation: switch tenant settings on and off, see analytics for environments and see capacity consumption. What they cannot do: change a user's security role in an environment, install apps in an environment or touch data in Dataverse. If you use PIM for time limited access, System Administrator is removed again when the assignment expires.
66
Least privilege

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣smallest possible role for each task

Microsoft itself documents which role is the least privileged for each of the five tasks a platform administration must be able to perform in practice. It is the best antidote to giving everyone Global Administrator.

TaskLeast privileged role
Create or manage a security group and its membersGroups Administrator
Create usersUser Administrator
Assign or remove licencesLicense Administrator
Attach a security group to an environmentPower Platform Administrator or Dynamics 365 Administrator
Assign Dataverse security rolesSystem Administrator in the environment
Three caveats that make the model work: a Dynamics 365 Administrator must be a member of the environment's security group, which does not apply to Global and Power Platform administrators. None of the service roles can, by itself, create users, manage groups or assign licences. And all of them must self elevate before they can assign Dataverse roles.
67
Tenant settings

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣few switches that move the most

There are about thirty tenant settings. You can leave most of them alone. These four determine whether the rest of the governance model can be enforced at all.

Who may create environments
Three separate settings for production and sandbox, developer environments and trial environments. They must be set separately. There is no separate sandbox setting
Microsoft defaultAny user with the right licence can create an environment as long as 1 GB of capacity remains in the tenant
RecommendedSet production and trial environments to specific administrators only. From 15 November 2026 each user gets one managed developer environment. Decide here who may create it
Capacity and licences
Two settings control whether environment administrators may also see the tenant capacity and licence overview. Giving them insight is the cheapest way to make consumption a shared responsibility rather than a central surprise
Copilot and AI
Copilot Studio authors limits which security group may build agents. Publish Copilots with AI features controls publishing. Data sharing for human review at Microsoft is switched off by default, and it should stay that way
WhereManage, Tenant settings
The trap everyone falls into: a restriction only works going forward. Environments that were created before you removed creation rights can still be administered by the people who created them. The restriction prevents new environments, it does not clean up the old ones. Cleanup is a separate task, and it will not do itself.
68
Environment routing

Give ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣every maker their own sandbox

This is the single most effective control against building in the default environment. Instead of banning, you redirect. New makers automatically get their own personal developer environment, which is managed from the second it is created.

What it does
Sends new or existing makers into their own personal developer environment when they open Copilot Studio, Power Apps or Power Automate. It does not work for Power Pages
Prerequisite
It is a premium feature that requires Managed Environments, precisely because all the environments it creates become managed. The default environment does not itself need to be managed
What the maker gets
Sharing limits set to no security groups and at most five individual people, Solution Checker set to Warn, usage insights switched on, and the maker themselves as administrator in their own environment. The environments do not count against the tenant Dataverse quota, and they inherit the tenant data policies
Multiple rules
You can define multiple routing rules, each with its own security group and environment group, prioritised in order. The first matching rule wins. If none match, the maker ends up in the default environment
Microsoft defaultRouting is switched off. All makers land in the default environment, which is why it looks the way it does
RecommendedSwitch it on early. It is the one control that changes behaviour without anyone experiencing a ban, and it makes the default environment significantly smaller
WhereManage, Tenant settings, Environment routing
The licence point that must be said out loud: a maker does not need a premium licence to create or preview an app or a flow in a managed developer environment. Premium is required to run them. Developer Plan does not cover Managed Environments when users run their solutions. Unmanaged developer environments are being retired: none can be created after 15 November 2026, and existing ones are suspended and then deleted from early 2027.
69
Group rules, the mechanics

What ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣happens when you press publish

Environment groups are where a policy stops being an agreement. The mechanics have four traits worth knowing before you set the first rule.

Prerequisite
A group can contain only managed environments. Environments without Dataverse cannot be selected at all. An environment that is not managed can be upgraded as part of enrolment. An environment can be in one group, with no nesting and no overlap
Only what you publish
Rules are enforced only when they have been published. Unsaved changes appear in bold with an asterisk. Rules you have not touched are still managed on the individual environment
Locking
When a rule has been published, the corresponding setting becomes read only in every individual environment in the group. There are no exceptions per environment. If you want an exception, the environment must be in another group
Into and out of the group
An environment that is added inherits the group's published rules. An environment that is removed keeps the last applied configuration, but is unlocked again. Removal therefore does not roll back
The naming convention
Microsoft is explicit: rules with (preview) in the name are in public preview, rules without it are generally available. Of the 28 rules, four carry the label. That is a precise and useful guide when you decide what may be used in production
WhereManage, Environment groups, Rules, Publish rules
The documented surprise: if the group publishes a rule for sharing limits, maker welcome content, solution checker, usage insights, backup retention or generative AI settings, then the environment's own settings are overwritten at enrolment. Microsoft's own example: if you publish sharing limits, the environment's existing welcome text is reset. Note what is in the environments before you enrol them.
70
Group rules, the selection

Twenty ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣eight rules, five that move the most

The list keeps growing. You do not need to decide on all of them at once. These five are the ones that actually change what is possible in a zone.

1 · Sharing
Sharing controls for canvas apps with the choices Don't set limits, Exclude sharing with security groups and a numeric ceiling. Agents have two separate rules for Editor and Viewer. Enforcement happens when sharing is attempted, not retroactively, and it can take up to an hour before it works
2 · Solution checker enforcement
The levels are None, Warn and Block, and only findings with critical severity block an import. Individual rules can be exempted. It does not work while the environment is in administration mode
3 · Generative AI settings
Sets the environment's AI map at scale: Move data across regions, Bing search, Microsoft 365 services and, for EU environments, flex routing. The two middle options cannot be selected until the first one has been selected
4 · Advanced connector policy
Replaces business and non-business with a pure allowlist: everything is blocked unless it is allowed, and new connectors are blocked automatically. Two modes, Mixed mode where the strictest policy wins, and ACP-only. The rule is available, but ACP-only is in preview and covers certified connectors only
5 · Cost controls
Draw from tenant credit pool decides whether the environment's agents may draw on the tenant's shared credit pool. It is the one rule with a direct bill at the other end
Worth knowing
Back-up retention with 7, 14, 21 or 28 days against a platform default of 7. Unmanaged customizations. Release channel. Maker welcome content with Markdown and a Learn more URL
Advanced connector policy is not removed by itself. If you remove the rule from the group, or remove an environment from the group, the policy remains in the environment. It must be removed per environment or through API.
71
What nobody has chosen

Environment ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣settings that are already switched on

Under Settings and Product you find Features. Here there is a set of switches that Microsoft has switched on. Nobody has made a choice, and most organisations discover them only when someone asks.

Dataverse MCP
Allow MCP clients to interact with Dataverse MCP server is switched on. It gives Copilot Studio, Visual Studio Code and other MCP clients an interface into Dataverse. Clients outside Copilot Studio, such as Claude, are nevertheless limited by default and must be allowed under Advanced Settings
Agent transcripts
Both Allow agent owners and editors to see session transcripts and Allow conversation transcripts to be saved in Dataverse are switched on. If you switch saving off, the old data is not deleted, and if you switch it on again, the period in between never comes back. That is a decision for a data protection adviser, not for a maker
Three AI switches
Preview and experimental AI models, External models and AI prompts are all switched on. All three also exist as group rules. Switching the first two off in the production group and leaving them on in a pilot group is the cleanest way to phase AI
Cost without a ceiling
Allow process capacity overage and Allow auto-claim of process capacity are both switched on. That is direct consumption exposure in a setting most people never open
The opposite direction
Dataverse blocks unmanaged customizations is switched off, and should be switched on in the production group. Dataverse intelligence and Allow data availability in Microsoft 365 Copilot are both switched off and require a deliberate chain of steps to work
WhereManage, Environments, Settings, Product, Features
Two caveats that must be said: Microsoft itself writes that generally available Copilot features are switched on and cannot be switched off in the portal. A tenant administrator must contact support. And several of the switches here have been announced as moving to Copilot, Settings. Take a screenshot of your own tenant before you build a procedure on this page.
72
Agent governance

Copilot ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣Studio is governed with data policies

There is not one page for Copilot Studio administration. The real control surface is data policies, where each agent capability appears as a connector you can block. Here are the names, so you can find them.

Force sign in
Block Chat without Microsoft Entra ID authentication in Copilot Studio. New agents are created with Authenticate with Microsoft switched on, but the maker can change to no authentication. That is exactly what the block prevents
Control knowledge
Three separate connectors: Knowledge source with SharePoint and OneDrive, Knowledge source with public websites and data and Knowledge source with documents, all with the addition in Copilot Studio
Control reach
HTTP for free calls out of the platform and Skills with Copilot Studio for connecting external skills
Control channels
A separate connector per channel, including Direct Line channels, Microsoft Teams + Microsoft 365 Channel, SharePoint channel, WhatsApp channel and Facebook channel. Direct Line is allowed by default, and it is the channel that makes an agent available on a website
Control export
Application Insights in Copilot Studio decides whether telemetry may be sent out of the platform
Two things to plan around: connectors added after 2019 typically land in the Non-business group, so a policy that allows everything in Business does not automatically catch them. And Microsoft is moving the virtual connectors for Copilot Studio into standalone rules outside data policies, starting with Skills in Copilot Studio and Knowledge sources for agents. A model built on connector blocking today will need adjustment. That is not an argument for doing nothing, it is an argument for writing down why each block exists.
73
Outside tenant settings

What ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣is not where people look

Four controls that are almost always mentioned in a governance model, and that do not live under Tenant settings. They are the most common dead ends in a workshop.

Tenant isolation
The switch is called Restrict cross-tenant connections and is switched off. When it is off, anyone with valid credentials in another tenant can establish connections in and out. Exceptions are added with direction and tenant ID, there is room for 500 rules, and a change takes effect in about an hour. It is under Security, Identity and access
Audit log
Switched on per environment. The retention policy is set to Forever by default, and a change made in environment settings applies only to new records, while the Security page option can also apply it to existing logs. User access and activity are sent to Purview only for production environments. It is under Security, Compliance, Auditing
Agent consumption
Credit consumption, limits per agent and status as Within limit, Nearing limit or Over limit. Overconsumption is handled either by drawing on the tenant's capacity or by billing to a pay-as-you-go plan. If prepaid capacity runs dry, new agent flow runs are blocked, while the agent itself continues. It is under Licensing, Copilot Studio
The weekly digest
Switched on per environment under usage insights and extended with recipients at tenant level. Requires tenant analytics to be switched on, otherwise nothing arrives. Not available in GCC, GCC High, DoD or China
74
The limit of what the portal can do

Analytics ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣is an operations window, not an archive

This is worth clarifying early, because many governance models are built on an assumption that the portal remembers. It only does so briefly, and the numbers do not mean quite the same thing from product to product.

Power Apps

Data is stored for at most 28 days. The reports are updated about every 24 hours

Power Automate

Data stays in the region for up to 28 days. Also about 24 hours of refresh latency. Solution cloud flows are not included in the reports

Dataverse

Each chart is updated every 24 hours. No retention window is stated for the views themselves. 30 days applies to the reports you download

The consequence for your model: tenant analytics must be switched on actively and are first ready after one to two days. If you need to document something months or years back, for audit or for a case, the portal cannot carry that alone. Exporting data to your own data layer exists, but is still in preview. Plan the archive somewhere else, and use the portal to run operations, not to remember.
75
Important change

CoE ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣Starter Kit has moved into the product

Many organisations have built their governance model on top of CoE Starter Kit. There is a good reason for that, and there is now an equally good reason to plan a transition.

What Microsoft writes
The toolkit is no longer actively maintained. It is not being expanded with new functionality, and reported bugs are no longer processed. Security vulnerabilities are the exception and are reported to Microsoft Security Response Center
What that does not mean
It has not been retired. It remains available for both existing and new installations. Nobody is forced to tear anything down on Monday
Why
The core capabilities have become Microsoft product functionality in the admin center. Microsoft now recommends the portal as the central place for governance, monitoring and insight
What you used CoE forWhere it lives now
Inventory of apps, flows and agentsInventory under Manage
Adoption, most used solutions and ownersUsage under Manage
Operational health for heavily used solutionsMonitor
Find risks and enforce good practiceActions
Programmatic access and your own reportsPower Platform CLI, Power Platform API, inventory API and the connector Power Platform for Admins V2
76
The first question in every European workshop

Where ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣the AI actually processes your data

An environment in Europe does not mean every AI feature stays in Europe. The answer is set per environment, in four switches, and one of them always leaves the region.

Move data across regions
Consent for generative AI features to use Azure OpenAI in another region when the model is not available in yours. For environments in Europe, Azure OpenAI is processed inside the EU Data Boundary. Experimental, preview and cross-geo models in the model picker also depend on it, and may process data outside your geography
Bing search
Web search grounding. Bing search data is stored and processed in the United States, also for environments in Europe. This is the switch that needs a decision, not a default
Microsoft 365 services
Allows generative AI features that depend on Microsoft 365 services. Review it together with the Microsoft 365 data residency position, not separately
Flex routing at peak load
Allow flex routing during periods of peak load. On by default for eligible tenants created after 25 March 2026. Older tenants should check what it is set to
WhereManage, Environments, the environment, Generative AI features, Edit
Two things to say out loud. Only Power Platform Administrators and Dynamics 365 Administrators can give consent for these switches. And switching off a setting stops data movement from that point on. It does not bring back what has already been processed elsewhere, so decide before the first agent goes live, not after.
77
Navigating by question, part 1

Security, ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣data and AI: where the answer lives

Administrators rarely open the portal to browse. They open it with a question. These are the questions a security review asks, and the path to the answer.

The questionThe path in the Power Platform admin center
How secure is the tenant overallSecurity, Overview
Which data policies applySecurity, Data protection and privacy, Data policy
Can data leave for another tenantSecurity, Identity and access management, Tenant isolation
Who approved Microsoft access to our dataSecurity, Compliance, Customer Lockbox
Where the AI processes dataManage, Environments, the environment, Generative AI features
Which AI features are on, and what they costCopilot, the Copilot hub
Is a public website exposedSecurity, Products, Power Pages
Labels move. The portal has been reorganised more than once, and older articles and screenshots still show former names. When a path does not match, search the portal for the setting name rather than following an old screenshot.
78
Navigating by question, part 2

Operations ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣and lifecycle: where the answer lives

The second half is the operations team's daily route. Most of it sits under Manage, and the rest is spread over three top level areas that people forget exist.

The questionThe path in the Power Platform admin center
What exists, and who owns itManage, Inventory
What should we fix firstActions, which is Power Platform Advisor
Is something failing for usersMonitor
Who may build agents, create environmentsManage, Tenant settings
Rules for many environments at onceManage, Environment groups
Can we restore yesterdayManage, Environments, the environment, backup and restore
Can we survive a regional outageManage, Environments, the production environment, Disaster Recovery
How do changes reach productionDeployment
The order to learn it in: Inventory to see what exists, Actions to see what is wrong, Monitor to see what is failing now. Three areas, one per question, and they cover most of what an operations team is asked in a week. The Microsoft 365 side of agents is in the next chapter.
79
How to use this chapter

Four ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣things to do first

Not an implementation plan, but the four actions in the portal that give the most back for the least effort. All four can be done in one morning.

1. Clean up roles

See who has Global Administrator today, and move them to Power Platform Administrator where that is enough. Remember that the role must be assigned directly, not through a group

2. Close environment creation

Set production and trial environments to specific administrators only. Then make a list of the environments that already existed, because they still belong to their creators

3. Switch on routing

Give makers their own managed developer environment. It is the control that changes the most behaviour without anyone experiencing a ban

4. Look at Actions

The platform already has a prioritised list of your own risks. It is free, it is specific, and most people have never opened it

Note that none of the four requires a project, a business case or a supplier. They require that someone has been allowed to make the decision. That is again the chapter on Operating model, not the chapter on the portal.
80
Chapter 10

Microsoft ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣365 admin center

An agent is built under Power Platform rules and used under Microsoft 365 rules. Two admin teams, two portals and one agent. This chapter draws the line between them.

Two portalsWho decides whatPublishingAgent BuilderInventoryConnectorsBillingIdentityThe handshake
The split

Built ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣in one portal, used through another

Microsoft's own agent FAQ names both admin centers for configuration and enforcement. Most organisations have one team per portal, and the agent falls in the gap between them.

Power Platform admin center

Where agents are built. Environments, who may author, data policies for connectors and knowledge, sharing limits, capacity and Copilot Studio billing

Microsoft 365 admin center

Where agents are used. The Agent Registry, requests for publishing, the store, who may install, pinning, blocking and removal

Microsoft Entra admin center

Where the agent's identity lives. New Copilot Studio agents get a Microsoft Entra Agent ID automatically

Microsoft Agent 365

The control plane across agents from every source. Generally available since 1 May 2026, and licensed separately

The practical consequence: a Power Platform team can do everything right in its own portal and still see an agent reach the whole organisation, because the last approval happens in a portal they do not administer. Governance of agents is a joint process, or it is a gap.
82
The anchor slide

Which ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣portal owns which decision

Eight decisions every agent passes through. Read across the row, and the gap between the two admin teams becomes visible before it becomes an incident.

DecisionPower Platform admin centerMicrosoft 365 admin centerNote
Who may build agentsCopilot Studio authors, a tenant settingNoPoints to one security group
Where makers buildEnvironment routingNoPersonal developer environments, managed from birth
Which connectors and knowledge an agent may useData policiesNoAlso controls knowledge source types and channels
How widely a maker may shareSharing limits in Managed EnvironmentsSharing, but only for agents built with Agent BuilderTwo settings for two kinds of agent
Publish to the whole organisationNoRequests: publish to store or rejectThe admin also chooses which users or groups may install
Who may install and use agentsNoAgents, Settings, User accessAll users, no users, or specific users or groups
Block or remove an agentNoAgent RegistryAlso pinning, deployment and export to CSV
Pay for consumptionBilling policies and capacity allocationCopilot, Billing and usageDifferent products, see the billing slide
Read the table vertically too. The first four rows are prevention, and they live in Power Platform. The next three are distribution and removal, and they live in Microsoft 365. A tenant that has only configured one column has only half a control.
83
Publishing

Sharing ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣with the organisation is a request, not a click

A Copilot Studio agent reaches Teams and Microsoft 365 Copilot through one channel. What happens next depends on whom the maker shares it with, and only one of the two routes passes an administrator.

1
The maker connects the Teams and Microsoft 365 Copilot channel

And chooses whether the agent should also be available in Microsoft 365 Copilot

2
Shared with specific users or groups

Only those users can find and install it, under Shared with you in the Agent Store. No admin approval. Sharing limits in PPAC are the control here

3
Shared with the organisation

The agent is submitted for admin approval and lands under Requests in the Microsoft 365 admin center

4
The administrator decides

Publish to the store or reject. Choose which users or groups may install it, and optionally install it for them

5
It appears in the store

In the Teams app store and the Microsoft 365 Agent Store, and in the Integrated apps list

Agree who reviews the request. The Microsoft 365 administrator sees the agent's data sources, tools and actions. The Power Platform team knows the environment, its policies and the business context. Approving without that context is approving blind. Global Administrator and AI Administrator can manage agents. Global Reader and AI Reader can only look.

Publishing article verified for the standard harness.

84
Agent Builder

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣no-code tier is administered in Microsoft 365

Agent Builder lives inside Microsoft 365 Copilot. Microsoft documents that admins manage it through the Microsoft 365 admin center, while Copilot Studio is managed through PPAC. Its sharing model is therefore a Microsoft 365 decision, not a Power Platform one.

Two roles, and one is owner

Can edit makes someone a full owner with equal rights to share, manage and delete. Can chat is use only. Groups can only be chat users, so ownership always sits with named people

Org-wide is one toggle

Turning on org-wide sharing for chat access puts the agent in the Agent Store for the whole tenant. The admin decides who may use the toggle: all users by default, specific users or groups, or no users

Permissions follow the user

The agent respects each user's SharePoint permissions and sensitivity labels. Sharing the agent can share the files you added, but removing someone from the agent does not remove their access to those files

Set the sharing control before the first agent spreads. A change to who may share applies only to new sharing actions. Agents already shared org-wide stay shared until someone updates them. The cleaner route to the whole organisation is a submission to the org catalog, which an admin reviews in the Microsoft 365 admin center.
85
The graduation path

Copy ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣to Copilot Studio crosses the border between the two portals

When an Agent Builder agent outgrows the no-code tier, the maker copies it to Copilot Studio. From that moment it is stored in Dataverse, lives in a Power Platform solution and is governed in PPAC.

Copied

  • Name, description, instructions and suggested prompts
  • The agent icon
  • SharePoint files, folders and sites added as knowledge
  • Websites added as knowledge

Not copied

  • Embedded files, which must be uploaded again
  • Teams chats, meetings and email as knowledge, which need Power Platform connectors
  • Copilot connectors and the code interpreter, which must be set up again
  • Scoped Copilot connectors and image generation, which Copilot Studio does not support
Three things the governance team should know. The copy is a snapshot: the original keeps running in Microsoft 365 Copilot and later edits do not follow, so plan to retire it. The maker needs a Copilot Studio or Microsoft 365 Copilot licence and the Dataverse entitlement. And the copy lands in whichever environment the maker picks, where data policies, connector policies and sharing limits apply. Environment routing decides which environment that is.
86
Inventory

Two ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣inventories that will never match

Every governance review eventually puts the two agent counts side by side and finds they differ. Microsoft documents that they differ by design. The work is to know why each difference exists.

Power Platform inventory

  • Only agents built on Power Platform: Copilot Studio and Agent Builder
  • Includes drafts that have never been published
  • Shows environment, owner and status
  • Does not show agents from Microsoft or external publishers

Microsoft 365 Agent Registry

  • Agents available to users in the tenant
  • Microsoft agents, external partner agents, agents published by your organisation and agents shared by their creator
  • Pinning, blocking, deployment and export
  • Shows few drafts, and only Copilot Studio drafts
A monthly reconciliation in three questions. Which agents exist in Power Platform but not in the registry? Usually drafts, so check how old they are. Which agents are in the registry but not in Power Platform? Microsoft and partner agents, so check who allowed them. And which agents appear in both with a different owner? That is the one to chase first.

The Copilot Studio agent inventory article is marked as preview documentation.

87
Two things called connector

Copilot ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣connectors and Power Platform connectors are not the same control

The names are close enough to cause a wrong answer in a security review. One indexes data ahead of time, the other calls an API at the moment of the question, and each is governed in its own portal.

Microsoft 365 admin center

Copilot connectors

  • Formerly Microsoft Graph connectors
  • Index data from outside Microsoft 365 into Microsoft Graph
  • Set up and permissioned by the Microsoft 365 administrator
  • Used as knowledge by Microsoft 365 Copilot and by agents
Power Platform admin center

Power Platform connectors

  • Call an API in real time, nothing is indexed
  • Governed by Power Platform data policies
  • Used as tools by agents, apps and flows
  • Use as real time knowledge is in preview
Two reviews, not one. Power Platform data policies decide which knowledge source types and connectors a maker may add to an agent. What a Copilot connector indexes, and who can see it, is decided where it was set up. Ask both teams the same question: which external data can an agent reach today?
88
Billing

Three ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣meters, two portals

Finance sees one Microsoft invoice. The configuration behind it is split, and the person who switches on a meter is rarely the person who reads the bill.

MeterCoversConfigured in
Copilot Chat pay as you goAgents in Microsoft 365 Copilot Chat and SharePoint agentsMicrosoft 365 admin center, Copilot, Billing and usage
Power Platform billing policyAn environment linked to an Azure subscription. The Copilot Studio meter counts Copilot Credits consumed by agentsPower Platform admin center
Copilot Credit capacity packsPrepaid, 25,000 Copilot Credits per pack per monthBought as a licence, allocated to environments in the Power Platform admin center
And the licence on top. For users with a Microsoft 365 Copilot licence, classic and generative answers, Graph grounding, agent actions and AI tools used by the agent are zero rated in employee scenarios. Computer use is not included. The cost chapter covers what is and is not free.
89
The handshake

Five ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣agreements between the two admin teams

None of these need new technology. They need two teams in one meeting, and a name written next to each line.

1
Who reviews an organisation wide publishing request

The Microsoft 365 admin approves, the Power Platform team supplies the context: environment, connectors, knowledge and owner

2
Who owns User access in the agent settings

All users, no users or specific groups. The default decides how far an approved agent travels

3
Who runs the monthly reconciliation

Power Platform inventory against the Agent Registry, with the three questions from the inventory slide

4
Who sees each bill

Copilot Chat pay as you go and Power Platform billing policies land on the same invoice from different portals

5
Who governs agent identities

New Copilot Studio agents get an Entra Agent ID. Governing those identities needs Microsoft 365 E7, or Agent 365 with at least Entra ID P1 or Microsoft 365 E3

Where Agent 365 fits: it is the control plane that sees agents from every source, and Copilot Studio agents register in it automatically. It does not replace the decisions above. It makes them visible in one place.
90
Chapter 11

Security ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣and DLP

Where data may move, who may see it, and how to approve an exception without opening everything.

DLPConnectorsBlock firstExceptionsSharingNetworkPower Pages
Core concept

What ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣DLP actually does

DLP in Power Platform is not like DLP elsewhere in Microsoft 365. It does not inspect the content of data. It decides which systems may talk to each other in the same solution.

What it is
A policy that places every connector in one of three groups. Connectors in different groups cannot be used in the same app, flow or agent. That is the entire mechanism
The three groups
  • Business data, systems with the organisation's own data
  • Non business data, everything else, typically personal and external services
  • Blocked, may not be used in the environment at all
The names do not mean sensitive and non sensitive. They simply mean two buckets that must not be mixed
Why it works
It prevents the classic leakage path: a flow that reads from a business system and writes to a private service. No user can bypass it, because the combination simply cannot be saved
What it does not do
It does not look at which data is flowing, only at which connectors are combined. A user can still send sensitive data to an approved system that is the wrong destination. DLP is a coarse sorting mechanism, not a content filter
WherePower Platform Admin Center under Security, Data and privacy, Data policy
92
The principle

Block ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣first. New connectors are blocked until someone has reviewed them

New connectors are added to the platform continuously, both from Microsoft and from third parties. The question is not whether you manage to assess them. It is what happens in the meantime.

Default: allow firstNew connectors automatically land in an allowed group. They can be used from the day they are released, and no one has made a decision
Recommended: block firstNew blockable connectors land in Blocked, while unblockable ones still land in Non business. They are moved out when someone has assessed them
The consequenceYou discover a new data exit when someone has already built on it. Removing it afterwards breaks a solution that the business now depends on
The consequenceA maker gets a no immediately and can ask for an assessment. That is an irritation for a week rather than a cleanup for a quarter
What makes block first acceptable is the cadence. Without a fixed monthly review, block first becomes a wall, and makers start solving tasks outside the platform. With a fixed review it is a queue, and a queue with a known waiting time is possible to live with.
93
Policy by zone

One ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣policy for the whole tenant is almost always wrong

A single policy must either be so tight that nothing can be built, or so loose that it protects nothing. The answer is not a better single policy. It is multiple policies, tied to the zones.

Connector categoryGreen zoneYellow zoneRed zone
Microsoft 365 and DataverseYesYesYes
Approved business systemsNoYesYes
Premium and third-party, approvedNoAfter assessmentYes, per solution
Custom connectorsNoNoYes, approved only
HTTP and HTTP with EntraNoNoBy exception only
Personal servicesBlockedBlockedBlocked
New, not yet assessedBlockedBlockedBlocked
Who can request an exceptionNo oneProduct ownerProduct owner and security
Notice that the red zone is the most permissive for connectors. That surprises many people. The logic is that the red zone has ALM, approvals and named owners, so the risk is handled by process. The green zone has none of those, so the reach must be limited technically.
94
The gap everyone misses

Custom ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣connectors and HTTP bypass the whole model

A carefully built DLP model can be made irrelevant by two capabilities that many organisations have not made a decision about.

Custom connectors

A maker can define their own connector to any API. If custom connectors are not classified in the policy, they can become an approved path out of the organisation that no one has assessed. They must be handled explicitly, not forgotten

The HTTP action

With HTTP, a flow can call any address directly. Data policies can classify it, but only if someone does. It is a legitimate and necessary capability for integrations, and it is also the broadest data exit in the platform

What happensHTTP is allowed broadly because one integration project needed it. The permission is never withdrawn, and after two years no one knows who uses it for what
RecommendedBlock HTTP in all zones by default. Allow it only in named environments with a known owner and a revisit date. The need is real, but it is almost never general
95
Exceptions

How ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣to say yes without opening everything

A governance model without an exception process does not hold. There will always be a real need that the rule did not anticipate, and if there is no path, the rule is broken silently instead of changed openly.

Four requirements for an exception
  • Scoped, to a named environment or a named solution, not to the whole tenant
  • Owned, by a person who can make decisions, not a mailbox
  • Time limited, with a date when it expires by itself
  • Logged, so there is a list of all active exceptions
What makes the difference
The exception must expire automatically. An exception that must be removed actively is never removed, because it requires someone to take the initiative to do something awkward for a colleague
Without processExceptions are granted in meetings and remembered by individuals. After two years, the policy on paper is not the policy that applies in reality
With processThe list of exceptions is short, known and dated. It can be shown during audit, and it can be used to see where the policy is actually wrong
The signal
If three different teams ask for the same exception, those are not three exceptions. They are a fault in the policy, and it must be corrected rather than handled three times
96
Access

Groups ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣rather than names

The most durable access control in Power Platform is not the most advanced one. It is the one that follows along when people change jobs, without someone having to remember to clean up.

Environments are tied to groups

Each environment gets a security group in Entra. Access is limited to group members, and roles come through a Dataverse group team linked to the same group. That makes access follow the employment relationship

Licences through groups

Assign licences by group, not per person. That makes it possible to see how many premium licences are used for what, and to withdraw them without a manual review

Roles rather than exceptions

Define a few roles: maker, approver, administrator, read access. Many small special permissions are the fastest path to an access model no one can understand two years from now

The test that exposes the model: how long does it take from an employee changing department until their access to the old area's environments is gone? If the answer is that someone has to remember it, then the answer is never.
97
Network

What ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣can and cannot be made private

This question always comes from infrastructure, and it is often answered imprecisely. It is worth being precise, because an imprecise answer sticks and blocks a project for months.

From the platform towards your network

Can be made private

  • Outbound traffic from Power Platform can be tied to your virtual network
  • Calls to internal APIs and data sources can be kept off the public internet
  • Requires a managed environment, an enterprise policy and delegated subnets
  • Is the direction most organisations actually need
From your network towards the platform

Cannot be made fully private

  • Traffic into Power Platform goes through public endpoints
  • It must be locked down with controls other than network isolation
  • IP firewall, Conditional Access and IP based cookie binding are the tools
  • The expectation must be set early, otherwise people design for something that does not exist
The conversation that saves months: ask infrastructure which direction they are worried about. If it is outbound, there is a good technical answer. If it is inbound, the answer is identity and policy rather than network, and that is a different discussion with different participants.
98
A different risk class

A ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣public website is not an internal app with a URL

Power Pages is the one part of the platform built for people outside the organisation. Every control in the rest of this chapter assumes a signed in employee. A public site does not.

Visibility

All sites are private by default, and developer environments cannot be made public. A governance control lets the tenant admin decide whether makers may make non production sites public at all

Anonymous data

If the Anonymous users web role has a table permission, any visitor gets the access that permission grants. A tenant control can block unauthenticated read access to Dataverse data. Write access is governed separately

Web application firewall

Built on Azure Front Door and runs in prevention mode. When it is on, use its custom rules instead of the site's own IP restrictions

One view for all sites
The Power Pages security dashboard shows anonymous Dataverse access, firewall status, external authentication, security scans and certificates across every site in the tenant
WhereSecurity, Products, Power Pages · governance controls under Manage, Power Pages
Treat a public site as an internet facing application. It needs a named owner, a penetration test before launch, a review of every table permission granted to anonymous users, and a decision on the firewall. Custom code on the site follows the pro code path described in the build chapter.
99
Chapter 12

ALM ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣and delivery

How something gets from an idea to production, and how it comes back again if it was wrong.

SolutionsManagedPipelinesPublish is not deploymentRollbackSource firstCoding agentsTest gate
Core concept

Solutions ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣from day one

This is the cheapest rule in the whole governance model, and the one that is broken most often. It costs nothing to follow from the start and is very expensive to introduce backwards.

What it is
A solution is a container around everything that belongs to a solution: apps, flows, agents, tables, connections and variables. It is the unit that can be moved between environments
Why it matters
Without a solution, a solution cannot be moved. It can be copied manually, which means that test and production slowly become different, and no one can say with certainty what runs where
Microsoft's defaultIn Dataverse environments, new apps and flows land in the shared default solution unless a preferred solution is set. It is the fastest way to start, and by far the most used
RecommendedAlways build inside a solution, including when something feels like an experiment. Half of what becomes critical began as an experiment
Why backwards is expensive
An existing app or flow can be added to a solution later, but dependencies, connections and references often need manual cleanup
101
Two kinds of solutions

Unmanaged ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣is built in, managed is run in

The difference is not technical cosmetics. It decides whether someone can make a manual change directly in production, and therefore whether your ALM is real at all.

Unmanaged

The source form

  • Can be edited. This is where building happens
  • Belongs in the development environment, and only there
  • Can be exported as managed to the next stage
  • Having unmanaged in production means someone can change it directly
Managed

The delivery form

  • Not edited directly. Changes create an unmanaged layer on top, unless managed properties block it
  • Belongs in test and production
  • Can be uninstalled cleanly, which unmanaged cannot
  • Forces changes back to development, where they belong
The rule that makes the rest possible: production contains only managed solutions. If there is a single unmanaged component in production, there is a path around the process, and then the process is used when there is time, and skipped when there is not.
102
The misunderstanding that costs most in Copilot Studio

Publish ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣is not deployment

In Copilot Studio, the button is called Publish. That word means something very different from what most people think, and the difference is usually discovered only when something has to be rolled back.

What people think Publish doesSends the agent from development onwards to test or production, like a deployment
What Publish actually doesMakes the current version of the agent available on its channels, in the environment where it already resides. Nothing moves
What people assume comes with itVersioning, approval, the ability to roll back and a test stage
What actually comes with itNone of those. No solution packaging, no pipeline stage, no rollback and no test gate. Publish is a release button, not a delivery process
The consequence in practice: an agent built and published directly in one environment has no way back. If a defect is fixed by editing the agent and pressing Publish again, the previous state is gone. If agents need the same operational reliability as apps and flows, they must be in a solution and through a pipeline like everything else.
103
Pipelines

Deployment ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣as a button rather than an evening

Power Platform Pipelines is the low-code version of a deployment process. It exists in the platform and requires neither DevOps tools nor a pro developer to set up.

What it is
A defined path from development through optional test to production, with optional approval, a history of what was deployed when and by whom, and Managed Environments as targets
What it solves
  • No manual export and import, so no forgotten components
  • There is an audit trail without anyone having to keep it
  • Approval becomes part of the action rather than an email
  • The maker can deploy themselves, within the frame, without waiting for IT
The common objectionWe do not have resources to set up DevOps for low-code solutions
The answerIt is not DevOps. A pipeline is set up in a morning in the admin portal. The need for real source control comes only when several developers work on the same solution at the same time
Right sequence
Pipelines first, source control afterwards, and only if the need is there. Many organisations skip pipelines and go straight for Azure DevOps, and then nothing happens for two years
104
What breaks deployments

Connections ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣and variables must not come across unchanged

When a deployment fails the first time an organisation tries, the cause is almost always the same: the solution has the development environment's settings baked into it.

Connection references

A solution must point to a reference to a connection, not to a concrete connection. Then each environment can have its own, and production does not need to use the developer's personal access to the system

Environment variables

Everything that differs from environment to environment must be a variable: addresses, folder names, recipients, time limits. If they are written directly in, the solution must be fixed by hand at every deployment

The symptom
The deployment succeeds, but the solution in production writes to the development system, or sends emails to the developer's own address. It is typically discovered by a recipient, not by a monitoring system
The rule
If a value would be wrong in production, then it is a variable. That is a decision taken during development and almost impossible to take afterwards
105
Rollback

Being ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣able to undo is not the same as having a backup

Most organisations think they can roll back. What they have is a backup of data. That is not the same as being able to return a solution to the state it had yesterday.

What is required
The previous version of the solution must still exist as a package that can be installed again. If it does not exist, rollback does not exist
Why managed matters
A managed solution can be uninstalled cleanly. An unmanaged one leaves components behind, and after two failed attempts no one knows what is actually installed
Data is a different matter
Rollback of a solution does not roll data back. If the defective version has written wrong data for a week, that is a separate cleanup with a separate plan
Agents are a third matter
An agent that has been published directly has no previous version to return to. That is the practical reason to package agents in solutions like everything else
The exercise that decides it: choose a solution in production and ask the team to show how they would bring it back to last week's version. Not explain it, show it. It takes twenty minutes and is more revealing than any maturity assessment.
106
Yannick Reekmans, Nordic Summit 2026

One ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣decision first, then five options

Before choosing tools, decide where the truth lives. Is it the development environment, with Git as a snapshot? Or is it Git, with environments built from it? Every option follows from that answer.

Environment first

The environment is the truth

  • Makers build in DEV, and DEV is the master copy
  • Git, if used at all, is a snapshot taken afterwards
  • Low effort, and familiar to every maker
Source first

Git is the truth

  • Environments are populated from Git
  • Branches, pull requests and review become possible
  • More effort, and more control
1
All manual

Export and import by hand. Environment first

2
Power Platform Pipelines

Built in, optional approval. Environment first

3
Azure DevOps or GitHub Actions

Scripted export and deploy. Environment first

4
Native Git and Pipelines

Environment connected to a repository. Source first

5
Full custom CI/CD

Build and release from Git. Source first

No option is wrong. Pick where you are, and move right over time. Speaker's model, retold.

107
Source control

When ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣Git is worth the trouble

Source control is right for some solutions and excessive for most. It is worth being concrete about where the line is, otherwise it is introduced everywhere or nowhere.

Pipelines are enough

The typical case

  • One or two makers per solution
  • Changes happen sequentially, not in parallel
  • Approval and history cover the audit need
  • Covers the vast majority of solutions
Source control makes sense

The exception

  • Several developers change the same solution at the same time
  • There is a need for branches, review of changes and automated tests
  • The solution is part of a larger release with pro code
  • Regulatory requirements for traceability down to change level
The demand for source control for everything is one of the most common ways a governance proposal gets rejected. It places a pro developer practice on top of low-code work, and that is almost always the point where the business loses interest in the whole model.
108
Yannick Reekmans, Nordic Summit 2026

AI ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣coding agents move the line for Git

The previous slide holds while humans do the building. When an AI coding agent writes the solution, source first stops being the exception, because Git is the only place a human can review what the agent did before it reaches a real environment.

Agent plus environment first

Risky

  • The agent changes DEV directly, with no review gate
  • No history beyond the audit log
  • Rollback means restoring the environment
  • Agent changes collide with human changes
Agent plus source first

Reviewable

  • The agent works in its own development environment
  • It syncs the change to a branch and opens a pull request
  • A human reviews before anything is deployed
  • Read only tool access is enough for schema inspection
Why now
Microsoft publishes a Dataverse plugin for AI coding agents, in preview (github.com/microsoft/Dataverse-skills), so agents can already read and change Dataverse directly. The governance question is where their changes land
The rule
If a coding agent is allowed to touch a solution, that solution is source first. Treat the agent as a developer who always needs a reviewer
109
Testing as a gate

A ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣deployment that is not tested is a hope

Tests become governance when they sit inside the pipeline: build, deploy to test, run the tests, and only promote to production if they pass. A failing test blocks the release instead of informing a meeting.

1
Static checks

Solution Checker on every export. Free and fast

2
Unit

Plugins and custom code, with a mocked Dataverse

3
Integration

Real calls against a test environment

4
UI and end to end

The Power Platform Playwright samples, which replace the deprecated Test Engine

5
Agent behaviour

Copilot Studio evaluations against a test set, automated through the Power Platform API

Start with a smoke suite

The app opens, the main form loads, the key process completes. Three tests catch most broken releases

Retest after every AI change

Code written by an assistant looks right more often than it is right. Behaviour tests are the only honest check

Test levels adapted from Yannick Reekmans and Matej Samler, Nordic Summit 2026. Tool availability verified on Microsoft Learn. Automating evaluations through the API applies to the standard harness.

110
Chapter 13

Build ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣options

There is no longer one way to build an app. It is a governance question before it is a developer question.

SpectrumCode AppsGenerative PagesVibeManaged AppsALM consequenceAI written code
The landscape is moving

Six ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣build options, not two

The discussion used to be low-code or pro code. Now there are four new options in between. Code Apps and Generative Pages are generally available, Vibe is still in preview, and each has limitations with direct governance consequences.

Build optionTypical useRequiresMaturity
Canvas AppsForms, field actions, mobileFunctional skillsGA
Model Driven AppsData heavy processes on DataverseData modellingGA
Generative PagesGuided, task focused pages inside a Model Driven AppSome React supportGA
Code AppsComplex requirements, long lifespan, own frontend on the platformReal developer skillsGA
VibePrototypes and demos, prompt to appFunctional skillsPreview
Custom Web AppsEverything outside the platformFull development teamOutside
The point for an operations function is not which one is best. The point is that four of them behave differently towards solutions, ALM and DLP.
112
Code Apps

Your ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣own frontend, the platform's backend

Code Apps let a development team bring its own code and host it as an app on Power Platform, with access to connectors and Dataverse. Generally available since February 2026, it is the option that removes the classic excuse for building outside the platform.

What it solves

Full control over UI, logic and integrations. Complex demanding solutions do not need to leave the platform to get a proper frontend

Why it is good for governance

The app stays on the platform. It inherits identity, connectors and environment structure instead of becoming a shadow IT project in a completely different cloud

What it costs

It requires real developer skills. It is code built in an IDE, not a designer. Every end user needs a premium licence, an app pass or pay as you go

The hidden line item

The team will use GitHub Copilot. That is a separate subscription and must be included in the calculation, not discovered later

The governance question: if you open for Code Apps, which environment may they be built in, and who reviews the code? This is a pro developer discipline, not a maker discipline.
113
Status moves fast

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣limitations that still bite

Limitations change between two talks. Generative Pages became generally available and solution aware in April 2026. Vibe stays in preview, and Microsoft now points app building to Copilot Cowork and Copilot Studio. Check the documentation before you write the rule.

Vibe Preview

  • Prompt to app, with plan, data and app in one process
  • Saves app, tables and plan into a solution
  • Edited by chat and inline actions, not directly in code
  • Edit it outside Vibe and redeploy with PAC CLI, and it becomes a new app cut off from its plan
  • Not available in the default environment
  • US, Australia, Asia and India regions only, English only

Generative Pages GA

  • Custom pages inside a Model Driven App
  • Solution aware. Pages built during preview must be opened once in the designer to migrate
  • Up to six Dataverse tables per page
  • Connectors, custom APIs and Application Insights telemetry are still preview
  • In the maker studio: US, Great Britain, Australia and Singapore only, US English prompts
  • External code generation tools work worldwide on public clouds
Solution aware is not the same as governed ALM. Generative Pages now travel through Dev, Test and Prod like the rest of the portfolio. Vibe saves into a solution, but its lifecycle stops at the Vibe surface. Keep Vibe in a sandbox and treat what it builds as a prototype.
114
Another stack

Managed ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣Apps: watch it, do not decide yet

Managed Apps is an alternative UX stack with its own website and its own GitHub repo. It uses Radix UI, prefers SharePoint and other data sources, and is edited inline.

What it is

A separate build experience beside Power Apps, not inside it

How mature

Very early. Described by people who have tried it as something that does not feel built by a Power Platform team

What you should do

Know the name, so you recognise it if it appears in a business unit. Do not build a policy around it yet

It is in the deck for one reason: when a new build option arrives every fourth month, the durable governance decision is not a list of approved tools. It is a principle for how a new build option is assessed. See the next slide.
115
The durable principle

Five ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣questions for any new build option

The list of tools gets old in a quarter. The questions do not. This is the slide that still works in a year.

1
Can it be packaged in a solution?

If no, it cannot be moved through Dev, Test and Prod, and it cannot be rolled back. So by definition it is a prototype tool

2
Which identity does it run under?

The user's own identity, or a service identity? That decides what happens when the builder leaves

3
Does the DLP policy catch it?

If it talks to data through connectors, it does. If it talks directly to an API outside that path, it does not, and then another control is needed

4
Can you see it in the inventory?

A build option that does not count in your inventory cannot be monitored and cannot be offboarded

5
Which environment does it belong in?

The answer is almost always sandbox first. Preview and production do not belong together

116
Structure or language

Use ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣AI for ambiguity, use an app for certainty

The most useful guardrail against forcing everything into an agent. Some tasks need predictability, others need understanding.

Structure, meaning an app

  • Mandatory fields and validation
  • Consistent calculations
  • Side by side comparison
  • Bulk editing and data review
  • Enforcement of permissions and approvals
  • Predictable and reviewable execution

Ambiguity, meaning an agent

  • Understand what the user actually wants
  • Find relevant information
  • Summarise complex content
  • Explain a process or some data
  • Draft a proposal
  • Handle variation in language and context
The good question for a business unit: what are you trying to force into an agent today that perhaps should still be an app? And the other way around, which app could use a little AI?
117
The hybrid

Three ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣ways to combine them

It is rarely either or. The three patterns cover almost everything built in practice, and each has its own governance profile.

1
Agent first

The user starts in a conversation. The agent understands the need and opens the right app or starts the right process. The agent is the door, the app is the room

2
Agent inside the app

The user is already in the app. The agent explains, summarises, searches and writes drafts. The structured action stays in the app, where it can be validated

3
Agent after the process

The user finishes the structured work. The agent summarises, recommends and prepares follow-up

In all three cases, the human stays in the loop, and the action with consequences stays in the part of the system that can enforce rules. That is the whole design principle in one sentence.
118
When the AI writes the code

AI ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣written code goes through the pro code path

Code Apps, code components and Power Pages code sites are often written with an AI assistant now, by people who may not read every line. That is fine, if the code meets the same gate as any other code before it reaches users.

What is builtThe control that existsWhat to add
Code AppsSwitched on per environment. Data policies are enforced when the app launches, and the app is solution aware. Power Platform Git integration is not supportedOnly switch it on in environments with source control and a reviewer
Code components in canvas appsAn environment setting must allow them. A component can reach the user's data and tokensTreat third party and generated components as untrusted until reviewed
Power Pages code sitesUploaded with the PAC CLI. There is no built in Git integration for single page app sitesKeep the source in your own repository and upload from a pipeline
Everything in a solutionManaged Environments can enforce solution checker at None, Warn or Block on importSet Block for production. Warn is a suggestion nobody reads
The principle from several Nordic Summit sessions: the assistant changes who writes the code, not who answers for it. Matt Beard, the ForwardForever session on AI built apps, the session on SOLID code components with GitHub Copilot and Nick Doelman on Power Pages all landed on the same point. A human owns it, a pipeline deploys it, and a checker can stop it.
119
Chapter 14

Agent ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣governance

Agents break the assumptions that governance of apps and flows rested on. They act on their own, they cost per use, they have their own identity, and their knowledge is an attack surface.

ComponentsHarnessOrchestrationIdentityCredentialsApprovalRisk factorsRegistryCoordinationKnowledgeWhat is comingComputer use
The product

What ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣Copilot Studio is

It is the tool where you build and operate your own agents. It is not a separate product beside the platform, it is a service on the platform, and that is why existing governance reaches into it.

What it is
A tool for building agents. It runs in an environment, uses Dataverse and connectors, and is covered by the same data policies as apps and flows. Everything you decide about environments and DLP also applies here
What you build
An agent consists of instructions, knowledge and tools, which the model orchestrates generatively. It is published to Teams and Microsoft 365, to a website, to other channels or to voice, and each channel has its own authentication
Who builds
Makers with a free Copilot Studio User License, which requires a prepaid credit pack. With pay as you go, admins name an Entra group in the Copilot Studio authors setting instead. Access to build is therefore a decision you make. It is not a default
What it costs
Consumption is billed in Copilot Credits from a shared tenant pool. The important exception: standard harness agents used in Teams, SharePoint or Copilot Chat by Microsoft 365 Copilot users do not draw credits for most actions. See the cost chapter
Why the conversation starts here
Because an agent breaks three assumptions at once: it acts on its own, it costs per use, and it has its own identity in Entra. Apps and flows did none of those things
WherePower Platform admin centerCopilot and the data policies under Security
121
Position

Does ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣it work for you, or for the process?

This question comes before every other governance question. Personal productivity is bought, runs as the user and needs no owner. Custom built is made for many people, and then everything in this chapter applies.

Personal productivityCustom built

Microsoft 365 CopilotBought, not built

Answers, drafts and summarises inside the Microsoft 365 apps, using only what the user can already see

Copilot CoworkBought, not built

Carries out multi step tasks on the user's behalf across Microsoft 365, within the user's existing permissions

Copilot StudioBuilt by you

An agent built for one job and used by many. Someone designs it, owns it and keeps it running

The testPersonal productivityCustom built
Who is it for?One person and their own workA team, a process or customers
Whose access?The user's own permissions, nothing moreWhat you design: the user, a maker connection or the agent's own identity
Who maintains it?Microsoft. Nobody in your organisation owns itA named owner, with ALM and a lifecycle
How is it governed?Licences, Purview, sensitivity labels and the user's permissionsEnvironments, DLP, approval, credits and monitoring

The grey zone is sharing. An agent someone builds for their own use becomes custom built the moment colleagues start to rely on it, and that is the moment it needs an owner. If something on the left already does the job, use it before building.

122
The basic concept

An ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣agent is three things and an orchestration

Agent governance becomes diffuse if the agent is treated as one thing. It consists of three parts, and each part has its own governance question.

Instructions

What the agent should and must not do. The governance question is who may change them, and whether the change can be traced. The instructions are source code in practice

Knowledge

What the agent answers from. The governance question is which sources are approved, and whether the source enforces access per user or simply returns everything

Tools

What the agent can do. The governance question is what it may execute without a human, and which identity the action is executed with

The orchestration binds them together. With generative orchestration, the model chooses which knowledge and which tools it uses in each conversation. That is powerful, and it is exactly why boundaries must be set on the three parts rather than on the flow of the conversation. You cannot predict the flow, but you can limit what is available.
123
The engine

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣agent runs on an engine you choose

A harness is the runtime layer between the agent you design and the model that drives it. It determines when the model is called, what context it receives, and which tool is used next. The build surface differs between harnesses, and so do the capabilities and cost model.

Standard

The familiar engine. Topics and triggers give fixed paths where you need them, alongside generative orchestration. The build phase is not billed, consumption begins at publication

Microsoft Copilot

(Formerly GitHub Copilot harness, the name Learn still uses.) Goal based reasoning. Skills and Workflows instead of topics, file creation in preview, full trace. Billed across the entire lifecycle

Customer Conversation

Built for customer facing voice and chat, with specialist agents that can hand over to a human representative

Three things make this a governance question rather than a product question. The choice is made when the agent is created. Conversion is one way only: an upgrade creates a copy on the Microsoft Copilot harness and leaves knowledge, Power Fx and child agents behind. And it is additive, so existing agents continue unchanged. There is no forced migration, but there is no undo button either.
124
The choice

Two ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣engines, two different bills

Most security and governance tools apply to both, but some authentication options, channels and sources differ. The difference is what the agent can work out on its own, and when you start paying for it.

CriterionStandardMicrosoft Copilot
Built forPredictable, rule based conversations and processesFlows with many steps, many sources and ambiguous decisions
The logicTopics and triggers that you controlGoal based reasoning, the engine finds the steps itself
Building blocksTopics, agent flows and promptsSkills in markdown and Workflows on a visual canvas
PredictabilityHigh where topics fix the path. Generative steps still varyLower, it adapts along the way and recovers after errors
File generationCode interpreter, opt inBuilt in file creation, in preview
TroubleshootingTrace per topicFull thinking and step by step trace of tool calls
When the meter startsAt publicationAt the first keystroke in the build phase
M365 Copilot inclusionYes, for eligible internal scenariosNo, consumption is billed regardless of licence
Governance centre of gravityApproval before publicationCeilings and boundaries before anyone starts building
Choose per agent. Agents on the two harnesses cannot call each other today, so put simple tasks in Standard agents and reasoning heavy work in separate Microsoft Copilot harness agents. Then the engine's power, and its price, match the work. The rule is the same as for all other orchestration: use the expensive engine where it makes the difference, not as the default choice.
125
What surprises the room

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣meter starts when you build

The whole experience is billed on the Microsoft Copilot harness, not only the agent's final answer to the user. That moves the budget conversation from the operations meeting to the first design meeting, and it changes who must say yes before anyone starts.

The agent description

Describing the agent in natural language and letting the platform generate it

Build and configuration

Instructions, knowledge and tools while they are being built

Every single test

Every test conversation in the canvas counts in the same way as a real conversation

Evaluations

Systematic evaluations draw consumption like any other run

Model calls and tool calls

The reasoning itself and the actions it chooses to execute

Operations after publication

The ongoing production use that everyone had already expected

Three moves make it predictable. Look at capacity in Power Platform Admin Center before anyone starts, not afterwards. Allocate capacity per environment, so development and test do not draw from the same pool as production. And set a ceiling per agent, so one agent cannot use the whole tenant's capacity. The ceiling and the economic model get their own chapter later.
126
The architecture decision that goes wrong

Connected ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣agent, capability or flow

This is the question makers most often answer incorrectly, and the error is only discovered in operations. The rule of thumb is that anything that must be right every time does not belong in a model.

CriterionConnected agentCapability in the agentFlow as tool
What it isAn independent agent called by anotherA bounded capability inside the agentA deterministic automation
ConversationCan hold its own dialogueCan ask clarifying questionsNo dialogue
Own personaYes, own instruction and toneNo, inherits the agent'sNot relevant
MemoryOwn contextShares the agent's contextNone between runs
PredictabilityLow, the model decidesMediumHigh, the same input gives the same output
Suitable forA whole discipline with its own expertiseA task in a conversationA transaction that must be right every time
ReuseCan be used by several agentsBelongs to one agentCan be used by everything
GovernanceOwn owner and own approvalFollows the agentFollows normal ALM
The rule that holds: generative freedom inside a step, deterministic control between the steps. Approvals, status changes and everything that must be auditable go into a flow or a business rule. The agent suggests, the system enforces, the human approves.
127
Identity

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣agent already has an identity

This is often a surprise in the room. The question is not whether agents should have identities. It is who owns them, who reviews them, and who can turn them off.

What it means
An agent built in Copilot Studio gets an identity in the directory. It can therefore be seen, assigned access and disabled like other principals. You cannot avoid agent identities by not taking a position
What is still missing
The identity tells you that the agent exists. It does not tell you what it is for, who owns it, or how critical it is. That context does not appear by itself, and it is the whole difference between a list and a registry
Without ownershipThere is a list of agent identities that nobody reads. During a review no one can explain why half of them exist, and no one dares turn them off
With ownershipEach agent has a human attached to it, a described task and a date for revisit. The review becomes half an hour rather than a project
The access nuance
An agent can act on behalf of the user who talks to it, or with its own access. Those are two completely different risk pictures, and it is worth knowing which one applies before the agent reaches production
Deep diveBlueprints, sponsors, Conditional Access and migration are in the Entra Agent ID chapter
128
Whose credentials

Maker ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣credentials lend your access to everyone

When a maker adds a tool and authenticates it with their own account, every user of the agent acts with the maker's permissions. The admin center can decide which options makers are allowed to choose.

PatternWho the tool acts asFits
End user credentialsEach user signs in, and gets only what their own account allowsInteractive agents on data with per user access
Maker provided credentialsThe maker's stored connection, for every userNarrow, deliberate cases. Risk of oversharing data and actions
Both allowedThe maker chooses per toolThe default. Fine for development, a decision for production
The setting
Control maker credential options, per environment or per environment group. If the environment is in a group, it can only be set on the group
Before you switch
The change is immediate for every agent in scope, and users start getting sign in prompts. Agents that run on a schedule or autonomous trigger fail, because there is no live user to sign in. Move those agents to an environment that still allows maker credentials, or redesign them, before switching
WhereManage, Environments or Environment groups, Settings, Product, Features, Copilot Studio agents
129
The largest real risk

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣agent inherits your sharing mistakes

The most common serious incident with agents is not that the agent does something wrong. It is that it does something entirely correctly with data it should never have been able to reach.

The mechanism
A document library is shared more broadly than anyone remembered. No one ever found the documents, because they were deep in a structure. An agent grounded in the library makes them searchable in natural language
Why it feels new
The access was there all along. What changed is that it became easy to use. Security through obscurity worked as long as search was poor
The wrong conclusionAgents are dangerous, so we wait. The problem does not disappear, it just remains undiscovered
The right conclusionClean up sharing on the sources the agent will use before it is pointed at them. Approve knowledge sources explicitly, and make that a condition for production
The control question
Does the chosen knowledge source respect access per user, or does it return the same content to everyone who talks to the agent? The answer determines whether the agent can be used on sensitive data at all
130
Approval

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣gate from experiment to production

Most organisations do not need a heavy approval process for agents. They need one gate that is short enough to be used, and that asks the questions that actually determine the risk.

Owner
A named human, not a team and not a mailbox
Purpose
One sentence on what it is for. If it cannot be written, it is not ready
Knowledge sources
Which ones, and whether their sharing has been reviewed
Actions
What it can do, and what happens if it does it wrong
Autonomy
Does it only answer, or does it act. Is there a human in the loop
Identity
Does it run as the user or as itself
Audience
Who can talk to it, and whether that is bounded by a group
Revisit
A date where someone looks at it again. Without a date, it becomes permanent
Eight fields, not eight meetings. The gate must be fillable in ten minutes by the person who built the agent. If it requires a meeting with four departments, it will be skipped, and then there is no gate.
131
Autonomy

Four ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣levels, four kinds of risk

All agent risk can be reduced to one question: what happens if it is wrong? The answer depends almost entirely on how much it may do without a human.

Level 1

Answers

  • Reads and formulates
  • Changes nothing
  • Risk is wrong information
  • Requires approved sources
Level 2

Suggests

  • Prepares a draft
  • A human sends it
  • Risk is poor quality
  • Requires clear draft labelling
Level 3

Acts with approval

  • Executes after a click
  • The human sees what happens
  • Risk is automatic clicking
  • Requires the approval to be meaningful
Level 4

Acts on its own

  • Triggered by an event
  • No human in the loop
  • Risk is scale and speed
  • Requires a ceiling, logging and an emergency stop button
On level 3: an approval that always says yes is not a control. If a human has to approve a hundred times a day, it becomes a click without content. Either the volume must come down, or you must be honest and call it level 4 and control it accordingly.
132
Feline Parein, Nordic Summit 2026

Risk ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣is not in the label "agent"

Autonomy is one axis. Two agents at the same level can carry very different risk. The risk comes from a combination of five factors, and an intake that asks about all five classifies better than one that asks what the agent is called.

1
Access

Which information and systems can it reach

2
Agency

What may it decide on its own

3
Reach

Who or what can it affect

4
Impact

How serious are the consequences

5
Reversibility

Can the outcome be undone

Which truth?

The same topic sits in several documents, some newer, some local. Someone must own which source is authoritative

Which conclusions?

Calendar, allocation and team data are harmless apart. Combined, they can say something no one approved

Which action?

The tool is allowed, but the action may not be. Govern parameters, identity, confirmation and reversibility at the point of action

133
The registry

You ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣get the list. You must provide the context

Building an agent registry from scratch is often proposed. It is almost always wrong, because the technical part already exists and updates itself. What is missing is something completely different.

What the platform delivers

The technical count

  • Which agents exist, and in which environments
  • Who created them, and when
  • Which identities they have
  • Consumption and activity
  • Updates automatically, without maintenance
What you must deliver

The context

  • Who is the human owner
  • What is the purpose, in one sentence
  • How business critical is it
  • Which knowledge sources are approved
  • Which autonomy level, and when it is revisited
Do not build a parallel registry. A hand maintained registry is correct on the day it is created, and wrong three months later. Instead, extend the existing count with the five missing fields, and make completion a condition for production.
134
Feline Parein, Nordic Summit 2026

Agent ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣governance is a coordination problem

Apps and flows lived in one admin center. Agents are built in four places, and each place has its own owner. No single team can govern them alone, so the first design task is deciding who decides.

Microsoft 365 admin

Microsoft 365 Copilot and SharePoint agents, and central agent management in Agent 365

Power Platform admin

Copilot Studio, environments and ALM

Pro developers

Pro code agents in Microsoft Foundry, with their own model and engineering choices

Compliance

Regulation such as the EU AI Act: literacy, inventory and risk classification

Bounded enablement
Start with a named maker population, not everyone
Tiered rights
Creating, sharing and deploying to production are three separate permissions
Separation of duty
The person who builds is not the person who promotes to production
One board
Modern work, Power Platform, pro development and compliance at the same table
Federated inventory
Reconcile the inventories of each control plane instead of building one more
Progressive maturity
Monitoring, intervention and retirement grow with the agent's reach
135
Feline Parein, Nordic Summit 2026

Keep, ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣evolve, add. The zones stay

Agents do not invalidate the governance model for apps and flows. Most of it carries over, some of it must grow up, and four things are new.

Keep

Still the foundation

  • Environments
  • DLP
  • ALM
  • Ownership
Evolve

From, to

  • Owner, to an accountability map
  • Solution approval, to a review of capabilities and actions
  • Functional testing, to behaviour and boundary assurance
  • Platform support, to multidisciplinary triage
  • Operational monitoring, to runtime observability
Add

New for agents

  • Knowledge governance
  • Behaviour boundaries
  • Accountability
  • Observability
The zones stay, the graduation criteria change. Personal, team and enterprise are still the right containers. What decides when an agent moves up is new: knowledge, reach, agency, access and tools, impact, reversibility and regulatory sensitivity. Add those to the intake, and the existing zone model governs agents too.
136
What is coming

Five ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣features that change a governance answer

Most releases add capability. These five change who can do what, or what counts as a change. Each one needs a sentence in the operating model before it arrives, not after.

CapabilityWhat it changes for governanceTargeted
Skills catalog
Microsoft Copilot harness		Reusable skills shared across agents. One skill change now changes many agents, so skills need an owner and a versionOct 2026
Roadmap 571880
Viewer and Editor maker roles
Microsoft Copilot harness		Finer sharing than co owner. Review who can edit a production agent, not only who can use itLaunched Oct 2026
Roadmap 569475
Self learning
The agent proposes a refined copy of itself and the maker accepts it. Acceptance is a change, so it follows ALMOct 2026
Roadmap 570432
Persistent agent identity
A mailbox and Teams presence for the agent. It becomes a visible colleague, with a lifecycle like oneNov 2026
Roadmap 570430
Run only sharing of autonomous agents
Others can trigger an autonomous agent without being able to change it. Separates operating from authoringJan 2027
Roadmap 567894

Dates are Microsoft 365 roadmap targets as of October 2026 and move. Roadmap 569475 has launched. Two items apply only to agents on the Microsoft Copilot harness. Check the harness before promising a feature to a team.

137
The tool of last resort

Computer ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣use: an agent with a mouse

Computer use lets an agent operate websites and desktop applications that have no API. It is powerful precisely because it bypasses the connector layer, which is also why it needs its own rules.

Allow list

Restrict the websites and applications the agent may act on. The default is any. The list blocks actions on others, it does not stop the agent from opening them

Credentials

Store sign in details in Power Platform encrypted storage or Azure Key Vault. Never in instructions, and never a personal account

Where it runs

Hosted browser and Cloud PC pools are in preview, and the hosted browser is not recommended for production. Your own machines run through Power Automate Desktop

Evidence

The transcript keeps a screenshot per action, and detailed logs are on by default with seven days of retention. Decide if seven days is enough for audit

Cost and placement. Every computer use step costs five Copilot Credits, or fifteen with a premium model, and it is not covered by Microsoft 365 Copilot licences. Keep it in the enterprise zone, require an allow list, and ask first whether a connector or an API would do. If one exists, computer use is the wrong answer.
138
Honesty

When ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣an agent is not the answer

The strongest thing an adviser can say in an agent project is when not to use one. That buys credibility for all the times the answer is yes.

When the task is deterministic

If the same input must give the same output every time, a flow is cheaper, faster and auditable. A model that almost always does the right thing is worse than a rule that always does it

When the foundation is missing

If documentation is outdated, contradictory or scattered, an agent does not solve that. It makes the problem faster to access and more convincingly worded

When errors cannot be tolerated

If the consequence of a wrong answer is legal, financial or health related, the human must stay in the loop. The agent may prepare the decision, but it must not take it

The recommendation that works in practice: let the first three agents be at level 1 or 2, with approved sources and without actions. They build trust, they are quick to put into operation, and they reveal data quality problems while they are still cheap to discover.
139
Chapter 15

Agent ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣architecture

Which runtime, which knowledge source, which tool and how many agents. Four choices that are hard to change later.

HarnessKnowledgeToolsMulti-agentStudio or FoundryAnti-patternsWell-Architected
The first choice

A ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣harness is a runtime, not a setting

Copilot Studio has three runtimes that look similar in the portal and behave differently in operations. Changing later means a one way copy without knowledge, Power Fx and child agents, then full retesting.

Standard harness

Path-driven. Best for structured, repeatable work with known requests. Topics, triggers, rules and branches. Agents and agent flows. Predictable

Microsoft Copilot harness

(Formerly GitHub Copilot harness, the name Learn still uses.) Goal-driven. Best for reasoning heavy work across several steps. Plans from a goal, chooses tools, adapts and retries. Skills, files, memory and sandbox

Customer Conversation harness

Service-driven. Best for customer voice and chat, where specialist agents resolve issues and hand over to a human representative

A practical warning about the documentation: many Copilot Studio articles on Microsoft Learn open with a note about which harness they apply to. Two articles can describe conflicting capabilities and both be correct. Read the note first, also when a vendor cites Learn to you.

Microsoft Learn: the harness is a Copilot Studio authoring and orchestration framework, not the GitHub Copilot service, and customer data isn't sent to the GitHub Copilot service.

141
What exists where

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣building blocks are not the same across harnesses

This table is the fastest way to discover that a solution sketch cannot be built on the harness it was designed for.

Building blockStandardMicrosoft CopilotComment
Child agentsYesNoSpecialist inside the same solution, with its own inputs and outputs
External agent connections (A2A, Foundry, Fabric)YesPartlySeveral of them are in preview. Verify in your own tenant
SkillsNoYesReusable way of working, markdown with optional scripts
MemoryNoPreviewMust be assessed separately for personal data
File work and sandboxPartlyYesStandard has an opt in code interpreter. File creation is in preview
Connected agentsYesYesExists in both places
MCP serversYesYesExists in both places. See the chapter on MCP and A2A
Workflows and connectorsYesYesThe deterministic foundation
Channels beyond Copilot, Teams and webYesNoNo SharePoint, messaging or contact center channels yet. MCP and A2A client channels are in preview
The design rule: prototype on the runtime you can defend in production. Not the one that is fastest to demonstrate.
142
Knowledge

Seven ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣knowledge sources, and when each one is right

The choice of knowledge source decides what the agent can answer, how fresh the answers are, and who can see what. It is a security decision disguised as a technical one.

SourceBest forDownside
SharePointPolicies, wikis, HR and IT documentsLimited indexing, large sites are heavy
Uploaded filesSmall, static document collectionsDo not update automatically. Do not inherit permissions
WebsitesProduct documentation and public information that changesThe URL may be at most two levels deep, and search uses Bing
DataverseStructured dataRequires a data model in advance. In return, synonyms and glossary
Copilot ConnectorsLarge external datasetsDepends on Semantic Index, less control
Azure AI SearchComplex or unstructured data with custom indexingExtra work and extra cost, and standard harness only
Work IQWork data: mail, chat, files, meetings and relationshipsA tool on the Microsoft Copilot harness, on by default with write access, so restrict it deliberately
The most important single line in the table: SharePoint and Graph respect the user's permissions. Files uploaded directly to the agent do not. That is the most frequent reason an agent answers something it should not be able to see.
143
Rule of thumb, not rule

Decision ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣tree: which knowledge source

Read from the top down. First yes wins. It takes one minute and prevents the conversation where three sources have been set up for the same content.

1
Does the agent need work data, meaning mail, chat, files and meetings?

Use Work IQ on the Microsoft Copilot harness, and restrict its write access

2
Is the content already in SharePoint and indexed?

Use SharePoint

3
Is it a small, fixed set of files that does not change often?

Use uploaded files, and remember that they do not inherit permissions

4
Is it public web content that changes often?

Use websites

5
Is it structured data in Power Platform tables?

Use Dataverse

6
Is it in an external system with a connector?

Use Copilot Connectors

7
Is precise control over indexing, chunking and vectors required?

Use Azure AI Search

144
Karl Johan Spiik, CGI, Nordic Summit 2026

A ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣knowledge source is a dependency with an expiry date

An agent is only as current as the content it grounds on. Many wrong answers in production are not model errors. They are a document that nobody owned any more.

Four fields for every source
Owner
A named person who answers for the content, not for the agent
Scope
The exact sites, libraries, tables or folders. Nothing wider than the use case
Refresh
How often the content changes, and how the agent picks that up. Uploaded files do not refresh themselves
Retirement
The date the source is reviewed again or removed from the agent
Test before publish, and after every content change
Stale content
Ask about something that has recently changed
Conflicts
Two sources disagree. Which one wins, and does the answer say so
Out of scope
Ask what the sources cannot answer. The agent should say it does not know
Injection
A document that carries instructions rather than facts
Structured knowledge changes the owner question. Dataverse, SharePoint lists and Azure SQL as knowledge sources move a database into the agent's grounding. The table owner now also owns the answers. Check the harness note on each Learn article, because the three are not documented for the same runtime.
145
Actions

Six ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣tool types, three to connect and three to act

Knowledge enables the agent to answer. Tools enable it to act. That is where governance starts to cost something, because actions have consequences.

ToolBest forDownside
ConnectorsFast actions against Outlook, Teams, Dataverse and common servicesFixed set of actions, limited logic
REST APIBusiness systems with an APIRequires OpenAPI definition and authentication
MCP serversReusable toolkits shared across agents and platformsMust be built and hosted if it does not exist
Agent flowsDeterministic logic across several stepsConsumes Copilot Credits and must be maintained
PromptsScoped model tasks: summarisation, classification, analysisCosts extra, and the output must be controlled
Computer useApplications with no API at allFragile, slow, requires a Windows desktop
Decision order: ready made connector, then existing MCP server, then REST API, then agent flow, then prompt. Computer use is the last resort, not the first solution.
146
Wesley Nell, Nordic Summit 2026

Deterministic ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣or ambiguous: Power Automate or Copilot Studio

The most useful single rule in the whole agent discussion. It also decides where your audit trail will sit.

Deterministic, use a flow

  • The same input always gives the same output
  • The steps are known in advance
  • It must be possible to try again and roll back
  • The audit trail must be readable by an auditor
  • Rules, limits and approvals
  • Cheaper per run

Ambiguous, use an agent

  • Input arrives in natural language
  • The path ahead depends on what is found
  • Something must be interpreted, summarised or suggested
  • Variation in phrasing is expected
  • The human confirms at the end
  • More expensive per run, but solves something a flow cannot
The architecture rule in one sentence: deterministic logic in flows, judgement in agents, truth in Dataverse.
147
Multiple agents

Two ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣patterns, covering almost everything

When one agent is not enough, there are really only two basic shapes. The choice between them is decided by whether one business domain dominates.

Orchestrator with specialists

  • Use it when one business domain dominates
  • One agent owns the user experience
  • Most calls stay within one domain
  • Watch out: the orchestrator becomes a bottleneck when the specialists become many
  • Keep the orchestrator's instructions short. The details belong in the specialists
  • The orchestrator decides. It does not execute

Specialist network

  • Use it when several domains carry equal weight
  • Each agent has strong independent ownership
  • Workflows routinely cross domain boundaries
  • Watch out: harder to reason about and harder to debug end to end
  • Publish clear agent cards
  • Keep the number of peer agents small
Both patterns require state to live somewhere that can be read outside the conversation. A case flow in Dataverse with the fields Received, Classified, Validated, Awaiting approval and Booked is the agent's contract. The chat is not the system.
148
Jennifer Krause, Holger Imbery and Wesley Nell, Nordic Summit 2026

Certify ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣the system, not only the agents

Every agent can pass its own tests while the combination fails. In a multi-agent design the risk sits in the handoffs, so that is where the approval has to look.

Handoff contract

What is passed, in which shape, and what the receiving agent may assume. Written down, and versioned like an API

Failure behaviour

What happens when a specialist does not answer, answers wrong or times out. And which agent tells the user

End to end tracing

One conversation followed across every agent it touched. Without it, nobody can explain an answer afterwards

System certification

Approve the composition as one release. A change in one agent reopens the gate for the whole system

A test worth borrowing: build the same multi-agent system twice, in two different ways. Whatever breaks on the second build shows where agents were coupled to each other's internals instead of to a contract.
149
Zsolt Zombik, Nordic Summit 2026

Copilot ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣Studio or Foundry: split by people, not features

The feature lists overlap more every quarter, so comparing them settles little. The useful question is who will own and change the agent, and the answer usually points to both.

Copilot Studio

The business facing layer, SaaS

  • Speed and Microsoft 365 native channels
  • Departmental agents
  • Owned and changed by non developers
  • Governed through Power Platform
Microsoft Foundry

The AI engineering layer, PaaS

  • Multi agent orchestration in code
  • Advanced retrieval and custom evaluation
  • Agents embedded in products
  • Owned by a pro developer team
Hybrid

The fusion team pattern

  • Makers own the experience in Copilot Studio
  • Developers own reasoning and retrieval in Foundry
  • The two connect agent to agent
  • Each side keeps its own ALM
One Purview, with a caveat
Purview covers prompts and responses from both. For Foundry, data security policies apply only when the call carries a user context Entra token. Without it, interactions show up in audit, but policies do not act on them
Same failure on both
The update succeeds, the confirmation is lost, the agent retries, and the case is updated twice. The fix is an idempotency key checked before the side effect. No platform choice removes that design duty
150
Anti-patterns

Six ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣sentences, that sound right but are not

Each of them has cost someone a rebuilt project.

"A harness is just a setting"

It is a runtime. Changing means a partial copy and rebuilding the rest

"Skills replace child agents"

Skills cover many needs, but provide neither triggers nor typed inputs

"A skill can call an API"

Network calls belong in a tool. Verify sandbox network access in your own tenant

"MCP and A2A compete"

MCP connects agents with tools. A2A connects agents with agents. Use both

"Connected agents can connect anything"

There are limits, and they depend on the harness. Verify in your own tenant

"More agents give more capacity"

Below roughly 30 to 40 actions: keep it on one agent. Simpler maintenance, less orchestration, lower response time

The last one is the most expensive: five agents where one would do means five times the governance surface, with no more functionality.
151
The design review instrument

Well-Architected: ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣a shared checklist for the enterprise zone

Architecture reviews go wrong when every reviewer brings a private checklist. Power Platform Well-Architected is Microsoft's public one, built on the same five pillars for every workload, agents included.

Reliability

Survives failure, recovers in the time the business needs

Security

Least privilege, protected data, a defended attack surface

Operational Excellence

ALM, monitoring and a team that can run it

Performance Efficiency

Responds fast enough at the load it will meet

Experience Optimization

Useful, accessible and trusted by the people who use it

How to use it. Run the free assessment at aka.ms/powa/assessment before an agent or app graduates to the enterprise zone, and attach the result to the intake. It turns the review into a conversation about named gaps instead of opinions. The assessment is generic to Power Platform, so pair it with the agent specific questions in this chapter.
152
Chapter 16

MCP ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣and A2A

Two protocols that open the agent to the outside world. They create two new trust boundaries that your current controls do not necessarily cover.

MCPA2AThreat pictureWhat admin seesControl planesSix steps
What they are

MCP ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣connects the agent to tools. A2A connects it to other agents

They do not compete. They solve two different things, and they create two different risk pictures. The confusion is the reason this slide exists.

MCP, Model Context Protocol

  • Agent to tools and resources
  • The server publishes named tools with description, input and output
  • Use it when you need functions or data from a service
  • Use it when you want standardised tool discovery
  • Do not use it if the counterparty must reason for itself

A2A, Agent2Agent

  • Agent to agent
  • The task is delegated. The counterparty uses its own logic and responds
  • Use it when the collaborator is already an agent
  • Use it when the counterparty owns its own domain
  • Use it when the conversation may go back and forth several times
The decision test: do you need a function to call, or an independent collaborator to delegate to?
154
MCP and connectors

Why ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣MCP does not behave like a connector

The MCP server appears as a connector surface and becomes covered by connector governance. But two differences have direct governance consequences, and they are not obvious in the portal.

MCPConnectors
Where it worksCopilot Studio and workflowsCopilot Studio, Power Apps, Power Automate and Logic Apps
AdditionMany tools at onceActions are added one at a time
ConfigurationAgentic capabilities without configurationActions are configured explicitly
When the server changesNo update needed. New tools are inherited dynamically while Allow all is onThe connector must be updated
DLPAt server level, not per toolAt action level
Read the bottom two lines together. The owner of the MCP server can add a new tool that the agent gets access to without a new approval from you. And DLP cannot distinguish between the tools on the server. That is not a bug, it is the design. It only means that approval must sit on the server, not on the tool. The maker's lever is Allow all. It is on by default. Switch it off, enable only the tools the agent needs, and any new tool on the server arrives switched off.
155
The threat picture

Six ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣attack shapes that come with the protocol

This is not an argument against MCP. It is the list of what a security review must ask before an external MCP server is approved.

Prompt injection

Malicious or unintended. Instructions hidden in data that the agent reads and obeys

Tool poisoning

A trusted tool does something other than what the description says

Remote code execution

The server executes code on behalf of the agent

Access without authentication

The server is open. It is the most frequently observed issue in practice

Credential harvesting

Credentials are harvested from configuration or from the call

Prompt harvesting

The instructions and context themselves are collected by the counterparty

A concrete example of tool poisoning: the user asks the agent to deploy an application. The agent calls a trusted tool. The server silently adds an extra container to the deployment. The application now runs in production together with something nobody approved. The call looked correct all the way through.
156
Not theoretical

What ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣is actually open on the internet

The figures here are from Trend Micro's mapping of exposed MCP servers, cited at Nordic Summit 2026. They are worth including because they move the conversation from principle to observation.

1,467

exposed MCP servers found in one mapping

70

of them exposed a tool that could run arbitrary SQL

Hardcoded

cloud credentials found directly in MCP configuration files

Five mitigations that can be written down today: block public IP access to sensitive services. Treat external MCP configuration as untrusted input. Use only official MCP catalogues. Run internal MCP services in a sandbox. Monitor tool calls.

Source: Trend Micro, referenced in the Nordic Summit session on MCP and A2A. Figures of this kind change continually and should be verified against the source before they are used in a decision paper.

157
Visibility

What ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣an administrator can and cannot see with MCP

This slide is the honest version. The right column is not a gap that will be closed next quarter. It is a consequence of the server belonging to someone else.

Visible

  • Connector registration in the connector list
  • Names of tools and resources
  • Descriptions of the tools plus input and output, inherited from the server
  • DLP classification on the MCP connector
  • Audit events when MCP is added to an agent
  • A runtime check against Defender before the action runs, in preview

Not visible

  • The server's internal prompts and own knowledge base
  • How the tool is actually implemented
  • The server's data, secrets and onward calls
  • Whether sensitivity labels travel to the server
  • The compliance state of a server that is not Microsoft's
  • DLP per tool. It applies to the connector, not the individual tool
The maker can turn off individual MCP tools. Central control per tool is arriving through Agent 365, for supported registered servers only. Write the rest down as an accepted residual risk, not as something you have solved.
158
A2A

Four ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣questions you cannot answer about the counterparty

A2A is the newer and less mature of the two. The risk is not the protocol, it is that the other end is a black box you do not administer.

Is it the agent you think?

It may be an agent in another tenant, an open source agent or a malicious endpoint. Today there is no good way to determine that

The conversation at the counterparty

The transcript of what actually happened in the other agent is not available to you

Labels do not travel

Sensitivity labels and DLP do not propagate to the counterparty's agent. Data classification stops at the boundary

24 hours

A data policy change that blocks an A2A connection can take up to a day to take full effect. It is not an emergency brake

The consequence for an operations function: A2A to external counterparties must be an explicit, named and approved decision per endpoint, not something a maker can turn on. Until audit trail and label propagation are in place, that is the only control that works.
159
Control planes

Four ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣tools, and where the gaps are

None of the four covers everything. This map shows what you can realistically promise, and what you must write in the risk register instead.

SurfacePPACAgent 365PurviewDefender
Agent inventory and ownershipPartialFullPartialPartial
Connectors and DLP classificationFullPartialPartialPartial
Knowledge sources and data labelsGapPartialFullPartial
Prompts and responses, auditGapPartialFullFull
MCP tool registrationFullPartialGapPartial
External MCP server internalsGapGapGapGap
A2A endpoint registrationPartialPartialGapGap
Transcript at counterparty agentGapGapGapGap
Identity, Entra Agent IDPartialFullPartialFull
Blocking unsafe action in real timeFullPartialGapFull
Data flows across tenantsGapGapGapGap

The assessment is the speakers' view, as of Nordic Summit 2026. The picture moves quickly, so use it as a conversation frame and verify the rows you intend to rely on.

160
Action plan

Six ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣steps that can be decided today

Not a maturity programme. Six concrete decisions, most of which use controls you already own.

1
Treat MCP and A2A as trust boundaries

Allowlist of servers and endpoints per environment. Require Entra authenticated connections. Ban anonymous Direct Line

2
Use DLP and environment groups

Classify MCP connectors as business or non business. Isolate production and sensitive workloads in their own groups

3
Turn on real time protection

Defender's agent protection and PPAC runtime protection. Blocking injection and oversharing before the tool runs

4
Turn on Purview for AI

Collect prompts, responses and sensitivity labels. Use retention and compliance. Watch for prompt injection signals

5
Use Agent 365 as the one inventory

All internal agents get an Entra Agent ID. Assign owners. Apply policy templates. Block risky agents centrally

6
Write down the remaining gaps

MCP internals, counterparty behaviour, data flows across tenants and label propagation. Accept them explicitly in the risk register

161
One year later

Where ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣MCP stands right now

The protocol is maturing quickly. It is a useful reminder not to write a policy that relies on a momentary limitation.

Supported

  • Tools. Functions the model can call to do something
  • Resources. Data and content exposed to the model. Was not supported one year ago

Not yet

  • Prompts
  • Elicitation
  • MCP Apps

Azure Functions

Has built in MCP bindings. The realistic path to your own hosted MCP server

Agent 365 sees them

Your own MCP servers appear in Agent 365 and can be approved centrally. That closes part of the gap

Check it yourself

Support and licensing change quarterly. This slide has an expiry date

162
Chapter 17

Entra ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣Agent ID

Every new Copilot Studio agent now gets its own identity in the directory, whether anyone asked for it or not. This chapter explains what that identity is, who is accountable for it, and what Entra can actually enforce on it.

Four objectsThe Copilot Studio blueprintSponsorsAgent usersScopesConditional AccessID GovernanceMigrationLicensingOutside the platform
The family tree

Four ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣objects, one line of inheritance

Entra Agent ID is not one object. It is a template, its presence in the tenant, the identities created from it, and an optional user account. Governance gets easier the moment the room can tell them apart.

Agent identity blueprint

The template. Holds description, app roles, publisher, credentials and the permissions every identity created from it inherits. It can do exactly one thing itself: create and delete agent identities

Blueprint principal

The blueprint's presence in your tenant. It is the actor in audit logs and the object you delete to remove the blueprint from the tenant. Blueprints can be single or multi tenant

Agent identity

A service principal with the subtype Agent. This is the identity that requests tokens and calls resources. Each one has a parent blueprint

Agent user

Optional, never created automatically. A user account tied one to one to an agent identity, for systems that only accept users. More on the agent user slide

Why the blueprint is the lever: Conditional Access applied to a blueprint covers every identity created from it, including the ones created next month. Disable the blueprint, and none of its identities can authenticate. One switch, the whole family.
164
What Copilot Studio does

Copilot ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣Studio brings its own blueprint

You do not design a blueprint for Copilot Studio agents. Microsoft owns it, and every agent identity Copilot Studio creates is one of its children.

Automatic, no opt out
Since May 2026, every new Copilot Studio agent gets an Entra Agent ID. With the standard harness it is created when the agent is created. With the Microsoft Copilot harness it is created at first publish. Agent Builder agents get none
Microsoft owned blueprint
The tenant receives the Microsoft Copilot Studio agent identity blueprint. Microsoft controls its credentials, so nobody in the tenant, global administrators included, can mint a token for a Copilot Studio agent identity
No bring your own
You cannot attach an existing identity to an agent. The agent's owner is added as sponsor. Deleting the agent deletes the identity, so the two lifecycles are the same lifecycle
The quota nobody plans for
Each identity is a directory object. The default quota is 50,000 objects, or 300,000 with a verified domain, and agents may use at most 95 percent of it. When the quota is hit, agent creation fails. A tenant with routing and many makers should look at this number once
WhereThe agent's ID is under Settings, Advanced, Metadata in Copilot Studio. The identities themselves are in the Entra admin center, Agent ID

Blueprint application ID: 25664c89-cea5-4ab6-b924-a54fd8a19ae0. The per blueprint cap of 250 identities that applies to custom blueprints does not apply to Copilot Studio. Source: Microsoft Learn, October 2026.

165
Accountability

Owners, ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣sponsors and managers are three different jobs

Entra separates technical control from business accountability. That separation is exactly what most agent governance models have been trying to describe in a spreadsheet.

Technical

Owner

  • Optional
  • Users or service principals, not groups
  • Can change configuration and credentials
  • Can re enable, restore and hard delete
Business

Sponsor

  • Required when an agent identity or blueprint is created
  • Users, dynamic groups or Microsoft 365 groups, not assigned security groups
  • Can disable, soft delete and change sponsors
  • Cannot re enable. That needs an owner or admin
Hierarchy

Manager

  • Places the agent in the organisation chart
  • Can request access packages for it
  • Answers who the agent works for
  • Not a control role
The detail that solves offboarding: if a sponsor leaves the organisation, sponsorship transfers automatically to that person's manager, and Lifecycle Workflows have dedicated sponsor tasks. The agent is never left without a named human, which is the problem the ownership chapter describes.
166
The optional object

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣agent user, for when a system only accepts users

Some resources do not accept a service principal. They need a mailbox, a Teams presence or a group membership. That is what the agent user is for, and it should be a deliberate choice, not a default.

What it is
A user account mapped one to one to a parent agent identity. Its tokens identify it as a user. It has no password and no passkey, and can only authenticate through its parent identity
What it can do
Join groups and administrative units and hold licences, like a person would. That is what lets it work in systems built around users
What it cannot do
Hold privileged administrator roles or join role assignable groups. An agent user is never a route to admin rights
The digital worker trap
An agent user created directly through Graph gets no Microsoft 365 provisioning. A mailbox and Teams presence need the agent user to be created through Teams or Agent 365
Ask before approving one: what does the agent need that an agent identity cannot give it? If the answer is a mailbox, the agent user is right. If the answer is convenience, it is a wider surface for no gain.
167
What the identity can reach

Scopes ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣on the identity are not a skeleton key

When a Copilot Studio agent is published, permissions appear on its identity in Entra. They look alarming in a review. They are narrower than they look, and they also show less than you might expect.

What is added at publishWhenWhat it means
Operations.Execute.AllA whole connector is added as a toolThe agent may call any operation on that connector
Per operation scopeSpecific actions are addedThe agent may call only those operations
Azure API Connections Runtime.AllFallbackThe runtime path to the connector

DLP still decides

The connector runtime revalidates every call against data policies and advanced connector policies. The scopes give no direct access to Graph or to the data behind the connector

The blind spot

Only first party and certified connectors add scopes. Custom connectors, MCP servers and REST tools add none, so the Entra view of an agent is not a complete list of what it can call

168
Conditional Access

Which ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣policy applies depends on who the agent is acting as

Conditional Access for agents is real, and it is easy to target the wrong object. The access pattern decides the target, not the agent's name.

Access patternWho the token is forWhat the policy must target
On behalf of a userThe signed in personThe user. Policies on the agent identity do not apply to this flow
The agent's own accessThe agent identityThe agent identity or its blueprint. A blueprint target covers every child identity
Agent userThe agent's user accountThe target Agent Users. Policies scoped to ordinary users do not reach agent users
Where it does not work
No Conditional Access when security defaults are on, and none for calls authenticated with API keys. For Copilot Studio agents, runtime enforcement on the agent's identity applies today only when the agent runs in Microsoft Teams
The scalable pattern
Put custom security attributes on agent identities, for example zone or data class, and target policies at the attribute. ID Protection for agents, in preview, adds risk detection on top
169
ID Governance

Access ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣for agents should expire like access for people

The tools that govern employee access now accept agents as the subject. That moves agent access out of maker settings and into a process with a request, an approver and an end date.

1
Access packages for agents

A package can have a policy for all agents. The agent itself, its sponsor or an administrator can request access

2
Expiry goes to the sponsor

When an assignment is about to expire, the sponsor is notified and decides. Access that nobody defends ends by itself

3
Lifecycle Workflows

Sponsor tasks run when people move or leave, so the accountability follows the organisation rather than staying with a former employee

4
The stop button for business

Sponsors and owners can disable an agent from My Account without opening an admin portal or knowing how it was built

How this fits the rest of the deck: the Agent Registry and Power Platform inventory say which agents exist. Entra ID Governance says what they may reach and for how long. A complete review uses both.
170
The agents built before May 2026

Older ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣agents run on app registrations and should be migrated

Agents created before Entra Agent ID became automatic use a classic app registration. They work, and Copilot Studio governance still applies, but Conditional Access and ID Governance on the agent identity do not reach them until they are moved.

Where to start
In the Power Platform admin center: Actions, Recommendations, Migrate Copilot Studio agents to Microsoft Entra Agent ID for enhanced agent governance. It needs Power Platform inventory and a Power Platform, Dynamics 365 or Global administrator
How it runs
In batches, so a pilot group can go first. The client ID is kept, and a migration can be reverted. The same operations exist as an API for scripted rollout
The trap
A migrated agent can work perfectly in the test pane and fail in Teams, because Teams is where Conditional Access on the agent identity is enforced. Check which policies will start to apply before the batch runs
Check the current state before you plan. The Copilot Studio documentation describes the in place migration above, in preview, and states that Microsoft has started migrating automatically. An older Entra article describes recreating agents instead. Read both on the day you plan the work.
171
Licensing

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣identity is free, governing it is not

This is the line that most often surprises a security team. Every tenant gets the identities. Doing anything deliberate with them is a licence conversation.

Included

Entra Agent ID

  • Available to all Entra customers
  • Identities are created and visible
  • Sponsors, owners and disable work
  • This is what every tenant has today
Security

Agent 365

  • Extends Entra security to agents
  • Included in Microsoft 365 E7
  • Or an add on to E5, A5 or Business Premium
  • Covered in the capacity chapter
Governance

Conditional Access and ID Governance

  • Need Microsoft 365 E7
  • Or Agent 365 together with at least Entra ID P1 or Microsoft 365 E3
  • Access packages, lifecycle and risk
  • Everything on the previous three slides
The honest summary for a steering group: you already have an identity per agent, and you cannot opt out. Whether you can put policy on those identities is a licence decision. Make it on purpose, because the default is having identities you cannot govern.

Source: Microsoft Learn, Entra Agent ID and Microsoft Entra licensing, October 2026. Check entitlements with the account team before a decision.

172
Agents outside the platform

Register ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣them, do not ban them

Agents are also being built in workflow tools, cloud AI services and code. The Power Platform admin center cannot see them, and they consume no Copilot Credits, so none of the platform controls reach them.

The blind spot is real

No inventory, no data policy and no credit cap applies outside the platform. A ban mostly moves the work out of sight

Entra Agent ID reaches further

Third party agents can be given an agent identity. Microsoft documents a sidecar pattern for custom and cloud agents, and a community node for n8n

One register for all agents

An external agent gets the same entry as a Copilot Studio agent: owner, sponsor, purpose, data reached and a review date

The governance offer that works: any agent may be built anywhere, provided it has an Entra agent identity and a sponsor, and is in the register. Then Conditional Access, access packages and disable work the same way, whatever tool built it.

The n8n integration on Microsoft Learn is a sample that uses a community node, and is described as not being production deployment guidance.

173
Chapter 18

Cost⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣

The conversation that is most often taken too late. Agents cost per use, and a consumption based model is only discovered on the invoice if no one has set a ceiling.

Two modelsThe credit cardThe exceptionCeilingRequests
The shift

From ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣licence per person to consumption per action

Apps and flows were paid per user. That was predictable, and it could be budgeted a year ahead. Agents behave differently, and that is the single thing that surprises finance teams the most.

The familiar model

Licence per user

  • Known amount per person per month
  • The cost rises with the number of users
  • Can be budgeted in advance
  • A mistake does not cost extra
  • Controlled by assigning and removing licences
The new model

Credits per action

  • The cost rises with use, not with headcount
  • A popular agent costs more than an unpopular one
  • Misconfigured automation can become very expensive very quickly
  • Cannot be budgeted without an estimate of volume
  • Controlled by setting ceilings and looking at consumption
The consequence for governance: cost control moves from an annual licence order to a monthly operations task. It is not difficult, but it must live somewhere, and it rarely lives anywhere the first time the invoice arrives.
175
The credit card

What ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣things actually cost in credits

Copilot Studio is billed in Copilot Credits. For standard harness agents, the figures are credits per event, and one credit is 0.01 USD at pay as you go list price.

What happensCreditsNote
Conversation
Classic response1A response from a handcrafted path without a generative model
Generative response2A response generated from knowledge. The normal case in a modern agent
Tenant graph grounding per message10Grounding in the organisation's content through Microsoft Graph. The most expensive single item in normal use
Action
Agent action5Also covers triggers, deep reasoning, topic changes and Computer Using Agent
Agent flow, per 100 actions13Note the unit. It is per hundred actions, not per run
Generative tools
Text and AI, basic, per 10 responses1Equivalent to 0.1 credit per 1,000 tokens
Text and AI, standard, per 10 responses15Equivalent to 1.5 credits per 1,000 tokens
Text and AI, premium, per 10 responses100Equivalent to 10 credits per 1,000 tokens. A factor of one hundred from basic
Content processing, per page8Document reading. Scales with page count, not with users
Speech
Classic speech, per minute10Core activity is included in the minute price
Generative speech, per minute35Generative voice tier. Core activity is also included
Premium generative speech, per minute75Speech is the most expensive channel, by a wide margin
Source: Microsoft Learn, Copilot Studio billing rates, and Copilot Studio Licensing Guide, September 2026. List prices in USD, subject to change, and actual price follows your agreement. Check before using in a decision.
176
The calculation that works in a room

Three ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣agents, three completely different invoices

The rate overview convinces no one. A calculation does. Below is the same organisation with three different agent types, calculated with the public list prices.

A

Internal knowledge agent

  • 500 employees, 4 questions per week
  • Generative response, 2 credits
  • Approximately 8,000 responses per month
  • Approximately 16,000 credits
  • Fits within one capacity pack
B

Agent with grounding in Graph

  • Same volume, but grounded in the organisation's content
  • 10 credits per message instead of 2
  • Approximately 8,000 responses per month
  • Approximately 80,000 credits
  • Fivefold increase, same usage pattern
C

Autonomous case handler

  • 2,000 cases per month
  • Each case: 1 trigger, 3 actions, 2 responses
  • Approximately 24 credits per case
  • Approximately 48,000 credits
  • Scales with case volume, not with headcount
The point is not the numbers, it is the shape. Agent A scales with the number of employees. Agent C scales with business volume and is the one that can surprise you. And the difference between A and B is one configuration choice that a maker can make without knowing what it costs. That is why ceilings belong on the environment and not in a policy.
177
The claim most often said wrongly

"It ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣is free, we already have M365 Copilot"

There is a real zero rate for employee facing agent use, and it is worth knowing. But it is bounded, and the difference between what is covered and what is not covered is not intuitive.

What is often saidAll our agents are free because our employees have Microsoft 365 Copilot
What appliesThe zero rate covers employee facing use where the user is signed in, has the licence, and the agent acts on the user's identity on named surfaces
What is not coveredExternal or unauthenticated use, autonomous agents without a user, Computer Using Agent, other agent flow triggers, and agents on the Microsoft Copilot harness
The consequenceThe agents that are most interesting to the business are often the ones that fall outside. A customer facing agent is almost never covered
The useful question for every new agent: who talks to it, are they signed in, and does it act on their behalf? Three yes answers probably mean low or no cost. Just one no means the cost must be calculated. That question belongs in the approval gate.
178
The control

A ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣ceiling is a brake, so give it an alarm

The strongest resistance to ceilings is that they are seen as distrust of makers. That is the wrong way to present them, and it is also wrong.

The ceiling protects the maker

Without a ceiling, the maker is the one left with an invoice they could not see coming. A ceiling is the only way to give people freedom to experiment without giving them a risk they cannot understand

Warning before stop

A ceiling without a warning along the way is a trap. Set the notification threshold below the limit. Alerts go to environment and tenant admins, so forward them to the owner. Then the conversation about an expansion is a planned conversation rather than an incident

Ceiling per environment, not per tenant

A ceiling for the whole organisation means that one agent can use everyone else's capacity. A ceiling per environment makes the problem local and makes it clear who needs to talk

What surprises development teams: test chat on standard harness agents is free, but Microsoft Copilot harness agents and AI Builder prompts in flows consume credits during build. Two weeks of intensive work can use a noticeable amount before production. Make it an expected figure, not a surprise.
179
The other ceiling

Request ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣limits, which no one knows before they hit them

Beyond credits, there is a completely different limit that does not cost money, but stops things. It is almost never seen in an app, but it is seen in an integration that runs at volume.

Who or whatRequestsNote
Paid Power Platform licence40,000 per licence per 24 hoursMultiple qualifying licences can be combined for the individual user
Microsoft 365 licence with platform access6,000 per licence per 24 hoursAlso applies to Power Apps per app and Dynamics 365 Team Member
Power Automate Process licence250,000 per licence per 24 hoursReplaces the legacy per flow plan. Assigned to one flow, and up to 10 can be stacked on it
Unlicensed identities25,000 per 24 hours in a shared poolPower Apps and Power Automate each have their own pool. They are not combined
Purchased request capacity50,000 per purchase per 24 hoursCan be stacked. They currently cannot be assigned to a specific user or flow. Use a Process licence for one flow
Source: Microsoft Learn, requests limits and allocations, September 2026. The limits are measured over 24 hours. Check before using in a sizing decision.
180
Ownership

Who ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣pays, and who decides

The technical part is easy. The hard part is that consumption without an owner always ends up as a line item on the IT budget, and therefore as an argument for slowing down.

Central budget

IT pays for everything

  • Easy to get started, no internal billing
  • Consumption is seen as a cost, not as an investment
  • The business has no reason to choose the cheap design
  • Ends with a ceiling that slows everyone equally
  • Right for the first six months, wrong afterwards
Distributed ownership

The business pays for its own

  • Each environment has a budget and an owner
  • The owner sees their own consumption every month
  • Expensive design choices become visible where they are made
  • An expansion is a business decision, not an IT escalation
  • Requires that consumption can be calculated per environment, which it can
The transition is best handled in two steps. First, a period with central budget and full visibility, where everyone can see their own consumption without paying for it. Then transition to payment. If you skip the first step, the first invoice becomes a discussion about whether the figures are correct, rather than whether the consumption is sensible.
181
Chapter 19

Capacity ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣and cost management

The cost chapter explains why consumption behaves the way it does. This chapter shows where it appears in the portal, who is allowed to change it, and what happens if no one does anything.

Four kinds of capacityPurchase modelsAgent ceilingEnvironment capacityAllocationAuto-claimFebruary 2027Agent 365
The map

Four ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣kinds of capacity, four different places

The word capacity is used for four things that have nothing to do with each other. They are purchased separately, measured separately, and run out separately. Mix them together, and the conversation becomes impossible to run.

Copilot Credits

Agent use. Purchased as a pack or by consumption, collected in one pool on the tenant

WhereLicensing, Products

Dataverse capacity

Database, file and log measured in GB. Follows the licences and can be expanded with add-ons

WhereResources, Capacity

Requests

Throughput per 24 hours. Does not cost extra, but stops things when the ceiling is hit

WhereLicensing, Capacity add-ons

Licences

Who may build, and who may run. This is where February 2027 matters

WhereLicensing, Summary
The distinction that makes the meeting work: credits and GB are money. Requests are physics. Licences are access. When someone says "we have run out of capacity", ask which of the four before you start troubleshooting. Three different people need to solve it.
183
The purchase

Four ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣ways to buy the same credit

The choice is not about price per credit, because it is almost the same. It is about whether you can estimate volume, and what happens to what you do not use.

ModelMicrosoft nameHow it works
Prepaid packMicrosoft Copilot Studio200 USD per pack per month, billed annually. One pack is 25,000 credits per month. Unused credits do not carry over to the next month
By consumptionCopilot Studio Pay-As-You-Go0.01 USD per credit, billed in arrears through an Azure subscription. No commitment, no wasted credits, but also no ceiling by itself
Annual commitmentCopilot Credit Pre-Purchase PlanDiscount from 5 to 20 percent according to drawdown size. The pool is annual, and unused credits expire at the end of the period
Across MicrosoftMicrosoft Agent Pre-Purchase PlanDiscount of 5, 10 or 15 percent. One unit equals 1 USD of consumption and therefore 100 credits. Covers Copilot Credits, Foundry, Fabric, GitHub and Copilot Cowork in one commitment
Who needs a licence
Makers need a Copilot Studio User License, at no cost with the prepaid pack, or a Microsoft 365 Copilot licence. On consumption or a commitment, the Copilot Studio Author role is assigned in the admin center instead. End users need no licence to talk to a published agent, but the run still needs funding
The practical recommendation
Start on consumption while you do not know the volume. Switch to packs when consumption is stable enough to estimate a month. Only consider a multi year commitment once you have seen twelve months of actual consumption, otherwise you are buying a discount on something that expires
List prices in USD, billed annually, subject to change without notice. Customers usually buy through an agreement in local currency with agreement specific discount. Talk to the account team before a quote. Source: Power Platform and Copilot Studio Licensing Guides, September 2026.
184
Agent capacity

Where ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣the ceiling is actually set

This is the screen most governance models describe without ever having opened it. It exists, it is concrete, and it can be set per agent.

What you see
Three tabs: Summary with total consumption, Copilot Credits capacity with the pool, and Environments with consumption distributed per environment. The last one is what makes distributed ownership possible
What you can do
The actions are called Manage Capacity, Manage Copilot Credits, Manage sessions and Manage Agents. Under the last one, monthly ceilings per agent are set
Status per agent
Each agent appears as Within limit, Nearing limit or Over limit. That is the list that must be read once a month. It does not only tell you about money, it also tells you which agents are actually used
Overconsumption
Two choices: draw from the tenant's available capacity, or bill to a linked pay-as-you-go plan. The first is also available as a group rule named Cost controls, Draw from tenant credit pool, so you can decide it per zone rather than per agent
WhereLicensing, Products, Copilot Studio
If the prepaid capacity runs out, new agent flow runs are blocked first. The agent keeps responding for a while, until overage enforcement turns it off. It looks healthy while the actions have stopped. That is the error that is hardest to discover without an alarm.
185
Environment capacity

Three ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣kinds of GB, and the mistake everyone makes

Dataverse capacity is the most common sizing mistake on the whole platform, because three completely different things have the same name. The difference is not academic, it is the whole difference between having room and not having room.

KindHow it arisesWhat it means
DefaultOnce per tenantFollows the first standalone licence you buy. If you buy more subscriptions, you do not get more default
AccruedPer licence, collected in a poolAdded on top for each standalone licence. Typically 250 MB database and 2 GB file per user licence
Add-onPurchased separatelyDatabase 40 USD per GB, file 2 USD, log 10 USD. Database falls to 30 USD at 1,000 units
By consumptionPer environmentDatabase 48 USD per GB, file 2.40 USD, log 12 USD. Approximately 20 percent more expensive than the add-on

Environments by consumption get no log capacity

They get 1 GB database and 1 GB file, and zero log. If that environment needs auditing, that is a separate purchase. In return, they do not draw on the tenant's shared pool at all

1 GB is the whole access control

As long as there is 1 GB free database in the tenant, anyone with the right licence can create an environment, unless you have restricted it. Capacity is therefore not only an invoice, it is also a door

186
Allocation and insight

Who ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣may see consumption, and who may use it

Three tenant settings decide whether distributed financial ownership is technically possible at all. By default, they are set so environment administrators may use the pool, but not see it.

Allocation of add-on capacity
Add-on capacity assignments controls who may assign purchased capacity to an environment
Microsoft defaultEnvironment administrators may assign add-on capacity to any environment in the tenant, not only their own
RecommendedRestrict to tenant administrators if cost management matters. Otherwise, a single environment can use from a pool others have paid for
Insight into figures
Tenant capacity summary view and Tenant licensing summary view decide whether environment administrators can see the tenant capacity and licence overview. Both are off
The uncomfortable combination
As shipped, an environment administrator may draw on the shared pool without being able to see what remains in it. That is the worst possible combination, and it is the default. Choose one of the two directions, but do not leave it as it is
WhereManage, Tenant settings. Consumption is seen under Resources, Capacity
The recommendation that works in practice: give environment administrators insight and keep allocation central. Seeing your own consumption is the cheapest way to make costs a shared responsibility. Being able to use someone else's pool without seeing it is the most expensive.
187
Licences that assign themselves

Auto-claim ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣is on, and that is often right

There is a mechanism that automatically assigns a licence to the person who tries to use a premium feature. It is useful, and it must be understood before anyone wonders why consumption is rising.

What it does
Auto-claim policies exist separately for Power Apps and Power Automate. When a user hits a feature that requires a licence, one is automatically assigned from the pool if one is available
The boundary that saves you
Automatic assignment applies by default only to managed environments. That is a sensible default, because it keeps assignment inside the part of the landscape that you actually govern. Leave it as it is
AI Builder credits
Unassigned AI Builder credits can be used by any environment by default. Add-ons are renewal only since November 2025, and from 1 November 2026 new or renewed licences carry no seeded credits. Existing ones last to the end of the contract term
What you should look at every month
Number of assigned licences against number of active users. Auto-claim makes it easy to get started and easy to forget cleanup. A licence that was assigned automatically eight months ago to someone who tried one thing is still being paid for
WhereManage, Tenant settings, and Licensing
188
The date that does not move

February ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣2027, when the warning becomes a stop

This is the most commercially sensitive date in the whole material, and it hits exactly the organisations that did the right thing and turned on Managed Environments.

March 2026

Messages to administrators began, through Message center and the admin center

June 2026

Messages to end users began, inside the products. Escalates from information to warning after seven days and to error after another seven days

February 2027

Users without a qualifying licence are blocked from opening apps in managed environments. The message is "You need a Power Apps license to use this app"

Scope
Only the environments you have made managed yourself. In return, every user who runs an app there, including users of apps with no premium features. Microsoft 365 use rights and Dynamics 365 Professional outside its own apps do not qualify. Dynamics 365 Enterprise and Team Members do
Trap number one
The Power Apps per app meter by consumption covers only Power Apps. Any flow consumption in the same environment must have a separate Power Automate licence
Trap number two
Developer Plan does not grant Managed Environments rights when users run their solutions. Environment routing creates developer environments as managed, and unmanaged ones must become managed by 15 December 2026. Together this is a common surprise
What you do now
Pull the list of users who run apps in managed environments, and compare it with assigned licences. Do it before Christmas 2026, so any cleanup can land in a budget rather than in an urgent case
189
The new layer

Agent ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣365 is not covered by Copilot Studio

Agent security has become a separate licence product, and functions that were previously covered have moved there.

What it is
Microsoft Agent 365 became generally available on 1 May 2026 and is licensed per user. Public price is 15 USD per user per month with annual payment, and Microsoft 365 E7 at 99 USD includes it. One licensed user activates the tenant. New purchases since June 2026 need Microsoft 365 E5, A5 or Business Premium
The shift on 1 July 2026
Three things now require a licence eligible for Agent 365 and are no longer covered by Defender for Cloud Apps: agent discovery and security posture, threat detection in real time, and investigation of agent activity in Advanced Hunting. Tenants without a licence lost access
The identity comes with it
Since May 2026, Copilot Studio automatically creates an Entra Agent ID for each new agent, and that cannot be opted out. If the identities must be governed with access packages and lifecycle, it requires M365 E7, or Agent 365 together with at least Entra P1 or M365 E3
The boundary that must be said out loud
Conditional access against the agent's own identity is currently enforced only when the agent runs in Microsoft Teams. Other channels still use the existing authentication through the connectors. Never promise conditional access on an agent in a web channel
Why it belongs in the cost chapter and not only in the security chapter: many governance models assume that Defender covers the agents. Some of that coverage now needs an Agent 365 licence, although Copilot Studio real time protection stays. If your model mentions monitoring of agents, then there is a licence line item attached to it, and it must be found now rather than at the next audit.
190
Four things

What ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣can be done in a morning

None of the four requires a project, a steering group decision or a purchase. They require someone to open the portal.

1 · Set a ceiling on the most expensive agent
Go to Licensing, Products, Copilot Studio, Manage Agents, and set a monthly ceiling on the agent that uses the most. Not to slow it down, but to get an alarm before the next invoice
2 · Give environment administrators insight
Turn on Tenant capacity summary view. It costs nothing, and it is the single change that moves the conversation about who owns consumption the most
3 · Pull the licence list against February 2027
Which users run apps in managed environments, and how many of them have a qualifying licence? The question takes an hour to answer and can take a quarter to fix
4 · Clarify Agent 365
Do you have a licence eligible for Agent 365, or have you lost agent monitoring without noticing it? This is a call to the account team, not an analysis
The habit that is worth the whole chapter: put a fixed half hour in the calendar on the first working day of the month. Three screens: credit consumption per environment, capacity consumption in GB, and assigned licences against active users. Cost management on a consumption based platform is not an annual exercise, it is a monthly habit, and it takes less time than the meeting about why the invoice became so large.
191
Chapter 20

FinOps ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣for agents

The cost chapter explains the meter and the capacity chapter shows the screens. This chapter is the operating model around them: who funds, who limits, who is told, and how a use case earns its budget.

The cycleFund, limit, budgetFour layersThree portalsSpending policiesPosturesShowback and chargebackBudget per use caseUnit economicsThresholdsWasteThe autonomy trade
The practice

FinOps ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣is a loop, not a report

FinOps is the discipline that cloud teams built when consumption billing arrived. Agents bring the same billing model to the business, so the same loop applies. The vocabulary below is FinOps practice, the tools are Microsoft's.

Inform

Make consumption visible

  • Consumption per environment and per agent
  • Each figure has a named owner
  • Showback before anyone is charged
  • Manage Agents, the consumption report, M365 Credits report
Optimize

Spend less per outcome

  • Right answer type for the task
  • Right grounding and the right model
  • Remove what nobody uses
  • Measured as credits per accepted outcome
Operate

Make it a routine

  • Limits set before production
  • Alerts with a named responder
  • Monthly review, quarterly cleanup
  • Exceptions approved, not discovered
The shift in one sentence: with licences, cost was decided at purchase. With credits, cost is decided at design and at run time, by people who never see the invoice. FinOps puts the invoice in front of them.
193
Three words that get mixed up

Funding, ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣limits and budgets do different things

Most surprises on an agent invoice come from someone believing a budget is a limit. Microsoft's guidance is explicit about where each one stops.

MechanismWhat it doesDoes it stop consumption?
Funding
Prepaid allocation, tenant pool draw, pay as you go		Decides where credits come from when an environment consumesOnly if the source runs dry and there is no fallback
Limit
Monthly limit per agent, M365 spending policy		Caps consumption for one agent, or for users of Microsoft 365 experiencesYes, for the object it is set on. An agent limit does not cap the environment total
Budget
Azure budget and cost alert		Tells someone that pay as you go spend has passed a figureNo. Azure budgets and alerts do not stop Copilot Studio consumption
The design rule: every environment needs a funding decision, every production agent needs a limit, and every pay as you go subscription needs a budget with a named recipient. Three mechanisms, three owners, and none of them replaces the other two.
194
Where control lives

Four ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣layers of control, and the fourth is people

Microsoft's guidance for Microsoft Copilot harness agents describes four layers, and the other harnesses have the same controls. The first three are settings. The fourth decides whether anyone looks at them.

1 · Tenant
Total capacity, and who is allowed to allocate it. The add on assignment setting decides whether environment admins can allocate capacity across the tenant
2 · Environment
Prepaid allocation, whether the environment may draw from the tenant pool, and whether it is linked to pay as you go
3 · Agent
Monthly limit, notification threshold, hard stop, and what happens when the agent is stopped
4 · Operating process
A cost owner, alert triage, exception approval, and how the agent's owner is told

No default agent limit

The admin center has no tenant wide default limit for new agents. If every agent must have one, an automated process has to set it

Settings drift

New environments can appear with tenant pool draw switched on. Compare inventory with the allocation API on a schedule, so the posture you chose is the posture you have

195
Three admin centers

One ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣credit, three places to govern it

Copilot Credits are consumed by Copilot Studio agents and by usage based Microsoft 365 Copilot experiences. Prepaid credits are shared across both, but the controls live in different portals.

PortalGovernsMain controls
Power Platform admin centerCopilot Studio agents and environmentsCapacity allocation, tenant pool draw, agent limits, billing plans
Microsoft 365 admin center
Copilot, Cost Management		Usage based Microsoft 365 Copilot experiencesSpending policies per tenant or group, per user limits, alerts, Credits report
Azure portal
Cost Management		Pay as you go spend from bothBudgets, alerts, tags, resource groups, invoice analysis
Who needs to be in the room: the Power Platform admin, the Microsoft 365 admin or billing admin, and whoever owns the Azure subscription. If the three have never met about credits, the shared prepaid pool is being spent by two teams that do not know about each other.
196
The Microsoft 365 side

Spending ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣policies cap people, not agents

For usage based Microsoft 365 Copilot experiences, the control is a spending policy. A Global or Billing administrator creates it in the Microsoft 365 admin center, AI or License administrators can edit it, and it behaves differently from an agent limit.

Default and additional
A default policy covers the tenant. Additional policies target groups and have their own limits. They do not inherit from the default
What can be set
A monthly policy limit, a per user limit of at least 2,000 credits a month, alerts by amount or percentage, notifications to users, and whether new services are added automatically. That last option is on by default
When the limit is hit
Users covered by the policy lose access to the usage based experiences until the first of the next month. Prepaid credits are used before pay as you go
As code
The Copilot Cost Management API in Microsoft Graph, in beta, manages policies, thresholds and per user balances. Values are in credits, not currency
WhereMicrosoft 365 admin center, Copilot, Cost Management. Usage under Reports, Usage, Microsoft Copilot, Credits
Decide the auto apply setting on purpose. Left on, every new usage based service Microsoft adds draws on the policy without a decision. That can be right, but make it a choice.
197
Choose a posture per environment

Hard ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣boundary or continuity, not both by accident

Microsoft's guidance for Microsoft Copilot harness agents starts by classifying environments as exploration, test and validation, or funded production. Each class then gets one of two postures.

Prepaid boundary

Spend can never exceed the allocation

  • A defined prepaid amount is allocated
  • Draw from the tenant pool is turned off
  • No pay as you go link
  • When it runs out, it stops
  • Right for exploration and most test
Continuity through Azure billing

The service keeps running

  • Linked to a pay as you go billing plan
  • Azure budgets and alerts per subscription
  • Agent limits on every agent
  • Remember: budgets alert, they do not stop
  • Right for funded production that must not fail
The failure mode: an exploration environment that silently draws from the tenant pool, which production depends on. That is how a pilot outspends a live service. Turn draw off where it is not needed, and check for drift.
198
Allocation

Showback ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣first, chargeback when the data holds

Showback tells a business unit what it consumed. Chargeback moves the cost to its budget. Charging on data the owner cannot verify ends the conversation instead of starting it.

Environment group per unit

Rules and the tenant pool draw setting apply per group, so a business unit's posture is set once

Billing plan per unit

An environment can be linked to only one billing plan at a time. A plan per unit, or per sub team, gives each its own Power Platform account resource in Azure

Tags and resource groups

The Power Platform account resource is an Azure resource. Tag it with cost centre and owner, and Azure Cost Management does the split

The blind spot to avoid
A chargeback model built on Dataverse storage per environment does not see credits. As agents grow, the most expensive consumption is invisible to the model that is meant to distribute it. Add credit consumption per environment before the model is used for agents
The data caveat
Environment figures are aggregates. Do not divide them into per agent percentages. Use Manage Agents or the downloadable consumption report for per agent figures
199
Before production

Every ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣use case earns its own budget

A budget per use case turns the cost conversation from a central worry into a decision the business owner makes before go live. Five steps, and the first two decide most of the figure.

1
Fix the answer type

Classic answer, generative answer, tool call or autonomous run. The rate card in the cost chapter shows why this choice dominates

2
Fix the grounding

Which knowledge sources, and whether tenant graph grounding is needed. Grounding is a design choice with a price

3
Subtract what is not billed

Employee use by Microsoft 365 Copilot licence holders is mostly free on the standard harness, but not on the Microsoft Copilot harness. Count those users separately

4
Set the limit before go live

The estimate becomes the agent's monthly limit, with a notification threshold below it. The Copilot Credit Estimator is directional, not a quote

5
Measure the first month

Compare actual with estimate after thirty days, then adjust the limit and the forecast together

200
The number that matters

Cost ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣per accepted outcome, not cost per month

A monthly total says an agent is expensive. It cannot say whether it is worth it. The unit that answers both is credits per outcome the business actually accepted.

Day 0

Baseline

  • Estimate per use case
  • Agent limit and threshold set
  • Cost owner named
  • Definition of an accepted outcome agreed
Day 30

Calibrate

  • Actual credits against estimate
  • Credits per accepted outcome
  • Conversations that ended without one
  • Limit adjusted to real use
Day 90

Decide

  • Scale, redesign or retire
  • Trend in cost per outcome
  • Move to the right posture
  • Business owner signs off
Why the definition matters: an agent that answers a thousand questions and resolves none has a low cost per conversation and an infinite cost per outcome. Agree on what counts as done before day 0, or the day 90 decision becomes an opinion.
201
Operate

Every ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣threshold has a name next to it

An alert that goes to a shared mailbox is a log entry. A ladder with a named responder per step is a process. The steps below are a recommended practice, not a product setting.

ThresholdWho is toldWhat happens
50 percentAgent ownerInformation. Is the month on track with the estimate?
75 percentAgent owner and cost ownerCheck for a design problem or a usage spike. Decide before it becomes urgent
90 percentCost owner and platform teamException request: raise the limit with a reason, or let it stop
100 percentEveryone above, and the usersThe agent stops as designed. The stop state and the message to users were decided in advance
Decide the stop state on day 0. When an agent hits its limit, what do users see, and who can raise it at 4 pm on a Friday? If those answers do not exist, the limit will be removed the first time it works.
202
Once a quarter

A ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣waste inventory pays for the FinOps work

Consumption billing makes unused things cheap and forgotten things expensive. A quarterly sweep finds most of the savings, and it uses screens you already have.

Agents with no conversations
Published, still triggered, nobody talking to them. Autonomous triggers keep consuming even when no one is using the result
Expensive answers for easy questions
Generative answers or tool calls where a classic topic would do. Look at the agents with the highest credits per conversation
Development that never stopped
Testing on the Microsoft Copilot harness and AI Builder prompt tests use real credits. Allocation stays after testing ends
Allocation without consumption
Prepaid capacity sitting in environments that do not use it, while others draw from the pool
Licences nobody uses
Auto claimed or assigned licences against active users, as in the capacity chapter
203
The model that scales

Autonomy ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣in exchange for commitments

Central approval of every agent does not survive the second hundred. The alternative that works is a trade: a business unit gets freedom to build and publish, and in return it signs up to a short list of commitments.

The business unit gets

Speed without a queue

  • Its own environment group and posture
  • Its own budget, visible every month
  • No central approval per agent inside its zone
  • A platform team that helps rather than gates
The business unit commits to

Five things, checked monthly

  • A named cost owner and a sponsor per agent
  • A limit on every production agent
  • Budget per use case before go live
  • The monthly review and the quarterly sweep
  • Accepting the stop when the limit is hit
What makes the trade enforceable: the commitments are checked with data the platform team already has, and a unit that breaks them goes back to central approval. Freedom is the default, and it is also revocable.
204
Chapter 21

Operations ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣and lifecycle

A solution is not finished when it is built. It is in operations. That is the phase no one planned for, and the phase that takes up the most after year two.

VisibilitySupportCleanupAbandoned assetsCadenceAlertsRed teamingContinuityIncidentsRetiringKeeping up
The starting point

You ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣can see more than you think

The common statement is that the platform is a black box. It is not. The problem is rarely lack of data, it is that no one has been given the task of looking at it.

Inventory

All environments, apps, flows, agents and connections with owner and latest activity. That is the foundation for any cleanup

Audit trail

Who did what when, across the services. Must be turned on and have a retention period that matches your requirements

Consumption

What costs what, and who uses it. Without this, the cost conversation is a feeling

Errors

Flows that fail repeatedly, and apps with error rates. They exist, but must be pointed at someone to become action

The real question is not "can we see it", but "who looks, and when". A dashboard without a cadence and a named person is a dashboard that is opened at launch and never again. Decide who looks at what, how often, and what mandate they have to act on what they find.
206
The uncomfortable question

Who ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣do you call, when a flow fails at three in the morning

This question reveals more about an organisation's real maturity than anything else. The answer is almost always a person, not a function, and that person often does not know it themselves.

Level 1

The maker themselves

  • Personal and team owned solutions
  • No service agreement, and that must be said out loud
  • If it fails at night, it waits until tomorrow
  • Completely legitimate, as long as the expectation is set
Level 2

The discipline platform owner

  • Solutions with multiple users in a department
  • Response during working hours
  • Requires that a documented solution exists
  • This is where you discover whether ALM is in place
Level 3

Normal IT operations

  • Business critical solutions
  • Same duty rota as other systems
  • Requires monitoring, ownership and a runbook
  • Also requires that IT has accepted owning it
The mistake that costs the most: a solution slides from level 1 to level 3 without anyone making a decision. It becomes business critical gradually, while it is still built as a personal experiment. That is why a conversation about criticality belongs in every review, not only at approval.
207
Cleanup

Thresholds ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣in days, not a cleanup day next quarter

Cleanup as a project works once and is never repeated. Cleanup as a rule with a day threshold runs by itself. The figures below are a useful starting point, not an answer key.

WhatThresholdActionResistance
Personal app, no use90 daysOwner is notified. No response within 30 days leads to deactivationLow
Shared app, no use180 daysOwner and co-owner are notified, then deactivation with option to restoreLow
Flow with no runs90 daysAutomatic deactivation. The platform already does part of thisNone
Flow that fails every time14 daysTurned off by the platform after 14 days of continuous failure. Ask the owner before turning it back onNone
Sandbox environment, inactive60 to 90 daysWarning, then deletion. Frees capacity, which is often the real scarcityMedium
Trial environment30 daysExpires by itself. Should not be extended routinelyNone
Connection with no use90 daysRemoved. An unused connection is standing access without a purposeLow
Agent with no conversations60 daysOwner is notified. Unused agents are almost always experiments that were never finishedLow
Two things make the difference in whether this can be carried out. First, there must always be a warning first, and a way back. Second, the rule must be announced before it is enforced. If you delete something someone did not know was at risk, the platform team loses trust for a year.
208
The inevitable

A ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣maker leaves every single month

In an organisation with a hundred makers, people leave continuously. The question is not whether, but what then happens to what they built. This is the most common cause of a production outage in a mature platform.

Without a procedure

What happens today

  • The account is disabled as normal
  • Flows that ran on the person's connections stop
  • No one discovers it until someone misses the result
  • Troubleshooting takes days because no one knows what existed
  • The solution is often to build it again from scratch
With a procedure

What should happen

  • Departure triggers an inventory of the person's assets
  • Shared solutions are handed over to a named new owner
  • Connections in shared solutions are changed to a service account
  • Personal solutions without users are archived
  • It takes an hour, because the list exists in advance
The preventive version is cheaper. Require two owners on everything shared with more than a handful of people, and use a service account for connections in shared solutions. Then departure is an administrative task rather than an incident.
209
Cadence

Weekly, ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣monthly, quarterly

Governance without a calendar is an intention. Below is the minimum cadence that keeps a platform in shape, and it can be run by one person with a part time allocation.

Every week, twenty minutes

New environments and new agents. Exceptions about to expire. Flows that fail repeatedly. Requests in the inbox. The purpose is that nothing stands still for a month

Every month, one hour

Consumption against budget. New exceptions and patterns in them. The cleanup run and what it caught. Sharing limits that were hit. The purpose is to catch a trend while it is cheap

Every quarter, half a day

The policy itself. Is the zone model still right, does the exception process work, which rules are being bypassed. Access review of ownerships. The purpose is to adjust the model, not only enforce it

The strongest signal of a well functioning model: the quarterly review changes something. If the policy is never adjusted, it is either because it is perfect, or because no one dares to say it does not work. The first is rare.
210
From report to alarm

PPAC ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣Monitor Alerts: get called, do not read a report

The single change that moves monitoring from something you look at, to something that looks at you. It requires Managed Environments, and that is one of the better arguments for the perimeter.

50 active rules

Per tenant. Covers Power Apps, Power Automate and Copilot Studio

What can be monitored

Any metric in the Monitor area, such as load time or error rate, against a threshold you set yourselves

Up to 5 recipients

You and up to four others get an email. Name more than one person, otherwise you have just built a new single point dependency

How to set it up

Resource type, metric, threshold and severity. Three levels: low, medium and high

Audit trail

Alert events are retained. This means you can document what was discovered when

Evaluation frequency

Alerts are evaluated once every 24 hours on daily aggregates, plus once when the rule is created

The honest expectation setting: this is not monitoring in real time, and it should not be sold as such. It is reliable, automatic discovery of what otherwise is first discovered when a user calls.
211
Four places, not eleven

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣monitoring landscape is fragmented. Choose four

Today there are at least eleven places to look: PPAC Monitor, Application Insights, Microsoft 365 admin center, Power Automate, Automation Center, Copilot Studio, analytics, Service Health, consumption reports, Agent 365 and CoE Starter Kit. No one maintains eleven places.

1
Turn on PPAC Monitor Alerts

It is the only one of the four that speaks up by itself. Start here

2
Run an agent review before anything is published

There are tools that automatically review an agent for quality, security, configuration, orchestration and test coverage in under a minute. It is cheaper than a review, and it catches routing confusion and gaps in the instructions

3
Register every agent in Agent 365

Copilot Studio agents are registered automatically. Your own agents must be onboarded. It is your one inventory

4
Troubleshoot live with Monitor

When a user reports an error, you can follow the session together with them instead of asking for a screen recording

The consequences of not choosing: blind spots, constant context switching, licence overconsumption, expensive audits, no combined health score for the tenant, and unexpected consumption of Copilot Credits. This is not a theoretical list.
212
Shubhangi Goyal, Nordic Summit 2026

Red ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣team the agent before users do

Testing the prompt box is not testing the agent. An attack can enter at six points in the loop, and the most dangerous ones arrive through a document or a tool result, not through the user.

1
User input

Direct prompt injection and jailbreaks

2
Context

Instructions hidden in knowledge and history

3
Reasoning

The model talked into a wrong plan

4
Tool calls

Allowed tools with harmful parameters

5
Tool results

Returned data that carries new instructions

6
Output and action

Leaked data or an irreversible step

Four takeaways
Whole loop
Test every stage above, not only what the user types
Untrusted by default
Treat every retrieved token and tool result as input from a stranger
Constrain first
Limit tools, parameters and memory before filtering text
Keep the attacks
Automate them, and rerun them as regression tests on every change
Where Copilot Studio helps
Built in
Copilot Studio agents block user prompt injection and cross domain prompt injection at runtime
At the tool call
External threat detection (preview) asks your security system to allow or block each tool call. Generative orchestration only
As regression
Store the attacks as an evaluation test set and run it through the Power Platform API
Measure
Attack success rate, task adherence, tool call accuracy and data leakage
213
Business continuity

Five ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣layers of recovery, each for a different failure

Recovery questions get one answer too often: we have backups. The platform has five mechanisms, and each one answers a different question. Know which failure you are protecting against before choosing.

LayerWhat it isThe failure it covers
Zone redundancyProduction environments are replicated across at least two availability zones in the region. Nothing to configureA data centre fails. Recovery point near zero, recovery time under five minutes
System backupsAutomatic for environments with a database, except trials. Seven days by default, up to 28 days for production Managed EnvironmentsSomeone deletes or corrupts data. Restore to a point in time
Manual backupsTaken on demand by an administrator. Not available for the default environment or trialsA risky import or bulk change is about to happen. Take one first
Self service disaster recoveryReplicates a production environment to a paired region. Needs Managed Environments and capacity. Setup can take up to 48 hoursA whole region fails. Replication lag is typically under 15 minutes, and failover is designed to finish within minutes
Long term retentionRetires old data out of the active environment for years. Needs Managed EnvironmentsRegulators ask for old records. Retained data is read only and cannot be moved back
Tier it, do not buy it everywhere. Zone redundancy and seven days of backup are enough for most environments. Longer retention and disaster recovery belong to the few production environments that a business process cannot run without. And restore an environment that contains an agent once, in a test, before you promise anyone what comes back. The solution rollback question is in the ALM chapter.
214
When an agent misbehaves

A ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣kill switch ladder, from one tool to the whole tenant

Agents need an incident procedure apps never did, because an agent can do something nobody designed. Decide in advance which step stops what, and who is allowed to pull it at three in the morning.

1
One tool call

Real time protection in Microsoft Defender (preview) can block a single risky tool invocation before it runs, without disabling the agent

2
One agent

Block it from Inventory in the admin center, or quarantine it through the Power Platform API. Channels stop answering, makers can still test and fix it

3
One agent in Microsoft 365

Block it in the agent registry in the Microsoft 365 admin center, so users can no longer find or run it

4
All new generative agents

Turn off the tenant setting Publish Copilots with AI features. It stops publishing, so pair it with step 2 for what is already live

Treat findings as vulnerabilities

Severity, owner, fix, retest, and a block on the next release until it is retested. The workflow from the Nordic Summit session on ethical hacking and responsible AI

Give users a way to report

A visible route for end users to flag a wrong or harmful answer, so incidents reach the owner before they reach a manager. Leo Visser, BBTG

215
The end of the lifecycle

Retiring ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣an agent is a procedure, not a delete button

Deleting an agent is fast and final. Deleting it well means deciding first what must survive it, because after a few minutes there is nothing left to decide about.

1
Decide retention

Transcripts live in the ConversationTranscript table, where a bulk delete job removes those older than 30 days by default. Export what the retention policy requires

2
Tell the users

Announce the date and the replacement. Remove the channels and the sharing first, so nobody is cut off mid conversation

3
Remove what it used

Connections, knowledge sources, flows and credentials that only this agent used. They outlive the agent if nobody removes them

4
Delete

All agent data is permanently deleted after a few minutes, including its app registration and service principals. Confirm in Entra that its identity is gone

5
Close the record

Mark it retired in the registry with the date and the reason, so the inventory and the cost report agree

Environments have a safety net, agents do not. A deleted environment can be recovered for seven days, or up to 28 days for production environments with Dynamics 365 apps. A deleted agent cannot. That asymmetry is why step 1 comes before step 4.
216
Keeping up

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣platform changes monthly. So must the review

A governance model written once is out of date within a quarter. Not because it was wrong, but because the platform it governs shipped something new. Tracking change is an operations task with an owner.

Roadmap
From September 2026 the separate release plans are no longer published. They are replaced by the AI at Work roadmap at aka.ms/AIatWorkRoadmap, with the statuses In development, Rolling out and Launched. Release Planner retires by 15 November 2026
Message center
Power Platform and Copilot Studio changes that need action arrive in the Microsoft 365 admin center, next to Service health. Route them to the platform team, not only to the Microsoft 365 team
Product pages
The Copilot Studio What's new page, and the monthly release channel for model driven apps

Monthly, one hour

The platform owner walks the roadmap and the message center with security and the CoE

Three questions per item

Does it change a policy? Does it change a licence or a cost? Does it change what makers can do?

One output

A dated list of decisions, and the slides in this deck that need updating

217
Chapter 22

Governance ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣as code

When the portal is not enough. API first, command line, and a history that is not overwritten every night.

The dilemmaInventory APIPAC CLILedgerThree steps
The dilemma

PPAC ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣is maturing. CoE Starter Kit is no longer maintained. And you are in the middle

The two shifts are happening at the same time, and they do not cover the same ground. That leaves a gap that many organisations only discover when they need to answer a concrete question from compliance.

What the platform gives you

  • PPAC Inventory with free text search, filtering, sorting and CSV export
  • Managed Environments with restrictions and policies
  • Environment groups and rules
  • Recommendations in Actions (formerly Advisor)
  • These are snapshots. They are strong for now

What it does not give you

  • History. What did this look like three months ago?
  • Tracking of whether a finding has been handled or accepted
  • A place to store a decision next to a finding
  • Repeatable actions. The portal is good for seeing, poor for repeating
The sharp formulation from Nordic Summit: the governance problem has rarely been whether you can get data out through an API. It has been how to track work and status changes on that data.
219
API first

Three ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣routes to data, without having to build a program

All three are Microsoft's own. None of them requires you to build anything first. They are worth knowing, even if you never go further than this.

PPAC Inventory
A filtered view of the raw API data. New items appear with about 15 minutes of delay. Free text search, column filtering, sorting and CSV export. It covers more questions than people expect
Azure Resource Graph
Can query PowerPlatformResources with Kusto Query Language. It is live inventory data, and it is the same language your Azure people already know. Visualisation requires you to build a dashboard on top
Power Platform CLI
The command line has grown from a developer tool into an administration tool. It can now query resources across the whole tenant, and it has a built in MCP server
Why this belongs in a governance deck: a graphical user interface is good for seeing which options and data exist. It is poor for doing the same action again and again. That is the whole argument in one sentence.
220
PAC CLI

Fifteen ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣new admin command groups, several of them pure governance

Version 2.14.1 from 21 October 2026, and all fifteen are still marked preview. The list shows where Microsoft is moving the administration surface.

governance

Rule based data policies and reports on connections across tenants

copilot-studio

Quarantine, owner reassignment, deletion and evaluation of agents

licensing

Entitlements, capacity, billing policies and assignments

resource-query

Queries across the whole tenant: environments, apps, flows and resources

environment-management

Environment lifecycle, disaster recovery, SKUs and environment groups

workflows-agent

Export and deletion of data about a registered person. Directly relevant for GDPR requests

The other nine are authorization, connectivity, analytics, app-management, dynamics, power-apps, power-automate, power-pages and user-management. The last line is the one that most often surprises people: a GDPR request for access or deletion can be answered from the command line.
221
The principle

Store ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣every scan, not just the latest state

This is the one idea from Nordic Summit worth taking with you, whether or not you ever build anything. The classic CoE model overwrites its tables every night. That means you cannot see a trend, and you cannot document that something was handled.

1
Every finding gets a stable id

A new scan updates the existing finding instead of creating a duplicate

2
Findings and decisions are kept separate

A decision that something is accepted or fixed does not change the scan result. The two are different kinds of truth

3
A finding is reopened if the problem remains

Then you can see that something was closed too early. That is the control most setups are missing

4
One administrative surface instead of four

Instead of a pair of CoE apps plus some Power BI reports that nobody opens

5
A human loop

The administrator asks the owner. The owner receives an email and fills in a short form. The administrator assesses the answer. This is the part that actually cleans up

One sentence worth taking home: you cannot govern what you do not store in a database.
222
Honesty about what this is

Community ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣practice, not a Microsoft product

This needs to be said clearly before anyone builds anything on it. There are three levels of certainty in this chapter, and they should not be mixed together.

Microsoft product

PPAC Inventory, Azure Resource Graph and PAC CLI. Documented by Microsoft, though the new admin command groups are still in preview

Community tools

Freely available consoles and dashboards built by MVPs on top of the same APIs. Useful, but without a support agreement

Your own constructions

A self built history database and an administrative surface. This is an internal development project with the maintenance that follows

The sober recommendation: start in the left column. Most organisations have not exhausted what PPAC and PAC CLI can do before they start building. Build only when you can point to a concrete question that the portal cannot answer.
223
For people who do not code

Three ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣steps into governance on the command line

Aimed at administrators who have never opened a terminal. Each step has a learning goal, not a delivery goal.

1
Open the terminal and run PAC CLI

Goal: learn to get governance data. pac auth create, pac env list, pac admin query. This is an afternoon

2
Clone a community repo and run it locally

Goal: learn to visualise and analyse that data. You do not need to understand the code to see what it shows

3
Build something small with a code agent

Goal: learn to control and automate governance data. This is where it becomes your own

Why an operations function should take this seriously: the administration surface is moving toward API and command line. This is not a community trend, it is the direction of the product. The administrator who can run a query directly does not wait for a report.
224
Chapter 23

Adoption ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣and demand

Governance without adoption is bureaucracy. Adoption without governance is debt. The two must be built at the same time, by the same people, with the same cadence.

BalanceIntakeTriageAdoption architectureEnablementMeasurementValue gatesPilot scope
Balance

Two ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣mistakes, equally expensive

Organisations fail in two opposite directions, and they feel very different from the inside. One feels like accountability, the other like progress. Both end in the same place.

Governance without adoption

The policy is impressive, and nobody builds anything

  • The model is described in detail
  • There is a four step approval process
  • The number of new solutions falls
  • The business buys something else instead
  • The platform team experiences itself as successful
Adoption without governance

Everyone builds, and nobody knows what exists

  • There are eight hundred flows, and no count
  • Half are owned by people who have left
  • The first serious incident stops everything
  • A ban arrives, not a model
  • The rebuild takes two years
The useful rule of thumb: every time you introduce a control, you must also be able to point to something that became easier. A requirement for solutions is followed by a template. A DLP policy is followed by a clear list of what people are then allowed to do. Without that, governance is seen as a deduction from speed, and then it is worked around.
226
Intake

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣request that can be handled in ten minutes

In most places, demand arrives as an email or a hallway conversation. That makes it impossible to prioritise, impossible to see patterns, and impossible to say no on a factual basis.

Problem
What do you do today, and what is wrong with it
Scope
How many people, how many times per week
Value
Time saved, fewer errors or revenue. An estimate is enough
Data
Which systems, and whether they contain personal data
Urgency
Is there a date, and what happens if it is missed
Owner
Who in the business owns the result afterwards
Capability
Is there anyone in the department who can build it themselves
Alternative
Is there already a system that should be able to do this
The last field is the most important, and it is almost always missing. Much of the demand on a low-code platform is really demand for something an existing system should do. If you build it on the platform, you have solved the symptom and made the integration debt larger.
227
Triage

Four ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣outcomes, not two

When only yes and no exist, everything becomes yes, because no is expensive to say. Four outcomes make it possible to be helpful without taking on the work.

A

Build it yourself

  • Small, bounded, low risk
  • The department has a maker
  • The platform team provides a template and a review
  • The vast majority should end here
B

Build it together

  • Larger or more sensitive
  • Fusion team with a professional developer
  • Requires an environment and a solution structure
  • This is where most real gains sit
C

Belongs somewhere else

  • The system should be able to do it
  • Or it is an integration task
  • Forward it with a reason
  • This is help, not rejection
D

Not now

  • The value does not match the effort
  • Or the prerequisites are missing
  • Save it with a date to revisit
  • A no with a date is not a no
Look for patterns in the inbox, not only in the individual case. If the same request comes from three departments, it is not three cases, it is a product. And if repeated requests arrive for the same system, that is a message to the people who own that system.
228
Adoption architecture

Organic ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣adoption does not carry on its own

Enthusiasm creates demos. Direction, evangelism and innovation require adoption to be designed as deliberately as the platform itself.

Context
What the organisation actually needs to achieve, and which tasks are worth building for. Without that, people build what they can rather than what matters
Platform
Environments, policies and access that are ready before anyone asks. Otherwise the first good idea becomes a support case
Community
A place to ask, and someone who answers within hours. This is where makers either continue or stop
Training
Sits in the centre because it only works when the other three are in place. Training without context, platform and community is entertainment
229
Enablement

Courses ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣do not create makers

The common move is a two day course for thirty people. Three months later, two of them build something. What works looks different, and it is cheaper.

A real task from day one

People learn the platform by solving something that annoys them. Ask them to bring their own task. A course without a task is entertainment

A place to ask

A channel with response time measured in hours matters more than all course material. Most makers stop at the first obstacle they cannot google their way out of

A fixed hour every week

Open sparring, same time, no agenda. It is the cheapest governance there is, because problems are corrected before they are finished

What really decides whether a maker continues: their first solution came into use. If it is built and never adopted, they do not build number two. Therefore prioritise the first solutions by how likely it is that someone will actually start using them, not by how technically interesting they are.
230
Measurement

Number ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣of apps is not an outcome

The numbers that are easiest to count are the ones that say the least. Below is the dividing line between what predicts something and what confirms something afterwards.

Predicts

Look at these every month

  • Number of active makers, not number trained
  • Time from request to first version in use
  • Share of solutions with two owners
  • Number of exceptions, and whether they expire
  • Share of new solutions that are in a solution structure
Confirms afterwards

Report these every quarter

  • Total number of apps, flows and agents
  • Time saved, stated in hours
  • Number of users affected
  • Consumption against budget
  • Number of incidents
One number is better than the others for convincing leadership: time from request to something in use. It is the only one the business feels directly, it falls measurably when the model works, and it rises again immediately if governance becomes too heavy. It is both an outcome and a warning light.
231
Chike Eduputa, Nordic Summit 2026

Five ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣gates before the next pilot

Most agent pilots do not fail. They are extended, then forgotten. Nobody refused it, so nobody adopted it, so it expired. That is an operating model failure wearing a technology costume, and no better model or prompt fixes it.

1
A value owner

A named person in the business who owns the number

2
A baseline

Measured before the build, not reconstructed after

3
A governance path

The route to production exists before the pilot starts

4
Redesigned work

The process changes, not just one step in it

5
A decision on freed time

More volume, better quality or fewer people. Say which

Time

Hours returned. The easiest to pitch and the weakest in a budget

Quality

Fewer errors. Compounds over time

Capacity

Work that was not possible before. Finance listens to this one

Risk

A consistent, auditable process

A saved hour is not a saved euro until somebody decides what the hour is for. Gate 3 is where governance earns its place in the value case: a pilot without a path to production is a demo with a budget.
232
Allan Rocha, Nordic Summit 2026

One ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣process, one metric, one stop date

The five gates decide whether a pilot may start. The charter decides how it ends. Write it on one page before anyone builds, and a pilot can no longer drift into a permanent state of almost.

One process
A single named business process, with an owner who wants it changed. Not a department, not a theme such as productivity
One metric
A single number, measured before the build starts. If it cannot be measured today, it cannot prove anything later
One stop date
In the calendar before the build starts. On that date the pilot is scaled, changed or stopped. Extended is not one of the options
Stop criteria
Written down in advance: the result that means stop, and the cost or consumption ceiling that means stop sooner
Stopping is a result. A pilot that ends on its date with a clear no has saved a year of drift, a licence line and a support burden. Report it as a finding, and make it as easy to say as yes. Otherwise nobody will ever propose a small experiment again.
233
Chapter 24

Responsible ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣AI

The regulation, the literacy requirement and the human pause. Three things that are not solved by a technical control.

EU AI ActRisk categoriesAI literacyAutomation biasPAUSE
Framework, not legal advice

Five ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣categories, and only two of them are heavy

The EU AI Act classifies by risk, not by technology. Most Power Platform agents land in the lower categories, but that needs to be an assessment, not an assumption.

1

Prohibited uses

Manipulation, exploiting vulnerabilities, social scoring, crime profiling, untargeted face scraping, emotion recognition at work or school, some biometric uses, non-consensual intimate material

2

High-risk systems

Biometrics, critical infrastructure, education and employment, essential public and private services, law enforcement, migration and asylum, the administration of justice and democratic processes

3

General purpose AI models

The models themselves and the systems that build directly on them

4

Generative AI and chatbots

This is where most Copilot Studio agents sit. The main requirement is transparency

5

Other AI

Minimal regulation

For financial services, insurance and HR heavy organisations, it matters that essential private services and employment are both on the high-risk list. An agent that helps an employee find a policy is not high risk. An agent that assesses an application or affects a customer's rights may be.

This slide is a conversation framework, not legal advice. Categorisation and dates must be verified by your own lawyers before use in a decision.

235
The literacy requirement

AI ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣literacy is a requirement, not a benefit

Since July 2026 the regulation requires providers and deployers to take measures that support AI literacy among staff and others who use the system on their behalf. This is one of the few places where an enablement programme has a regulatory anchor.

Bias

What bias is, what creates it, which effect it has, and how a user can discover and test it

Hallucinations

Understand the phenomenon, recognise the consequence, see the warning signs, validate sources, and be open about what is AI generated

Data protection

Which data is used, how it is protected, and what poisoned data and hidden instructions are

Responsibility

The user remains responsible for the output she forwards. Copyright and infringement risk belong here too

Transparency

Label AI generated content clearly. Text in the public interest must be disclosed if it has not been reviewed. Tell users when emotions are detected

Four actions

Build users' AI literacy. Make information easy to find. Create one place to report AI issues. Have an AI policy that is actually readable

The strategic point: the bottleneck limits the whole chain. Making one step faster with AI does not necessarily make the process faster. If users are not ready, users are the bottleneck, and then technology cannot solve it.
236
Automation bias

The ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣loop that removes its own control

This is not a technology problem. It is a human problem that arises precisely when the technology works well. That is why it is also invisible in telemetry.

1
The AI works
2
Trust rises
3
Checking falls
4
The AI works again
5
The loop continues until the AI fails

What removes the pause

Speed, previous success, confidence, an answer that matches the expectation, time pressure, and the cost of checking

When to slow down

Surprise, high stakes and real uncertainty. Three signals that are easy to teach a whole team

237
PAUSE

Five ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣questions between the answer and the consequence

A mnemonic that can be learned in ten minutes and used for the rest of a working life. It is not specific to Power Platform, and that is exactly the point.

P
Price the error

What happens if this is wrong? That is the only question that decides whether the next four are worth the effort

A
Answer first

What do I think myself, before I am anchored by the AI's answer?

U
Unpack uncertainty

What do I actually not know here?

S
Seek another signal

A source, a test, a person or a calculation

E
Execute deliberately

Three possible outcomes: trust it, verify it, or reject it. It must be a choice, not a reflex

The best formulation from the session: do not pause because AI is always wrong. Pause because the decision is still yours. And an explanation is not verification.
238
Chapter 25

Anti-patterns⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣

Ten ways to do it wrong that all feel right while you do them. They are gathered from real journeys, and most organisations can recognise at least three.

EnvironmentsPolicyOwnershipAgentsProcess
Anti-patterns, 1 to 4

Environments ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣and policy

Everything in the default environment

Why it feels right. That is where everyone already is, and it works immediately. Creating environments feels like overhead without benefit.

What breaks. The default environment cannot be deleted, everyone is in it, and there is one DLP policy for both experiments and business critical operations. When you later want to tighten, you hit everyone at once.

Instead. Treat the default environment as personal productivity, not production. Rename it so the name says that, and route new makers to an environment that is intended for the purpose.

One environment per project

Why it feels right. It gives clean separation, and each project can run at its own pace without disturbing others.

What breaks. After eighteen months there are seventy environments, forty of them finished projects that nobody dares delete. Capacity is tied up, DLP must be maintained in many places, and the inventory becomes unreadable.

Instead. Divide by zone and lifecycle, not by project. A project gets space in an existing environment unless there is a concrete reason for something else.

Block everything, and handle exceptions

Why it feels right. It is the cautious position, and it is easy to defend to audit on day one.

What breaks. Without a working exception process, blocking becomes the permanent state. People solve the task somewhere else, and you lose both usage and visibility.

Instead. Blocking first is defensible, but only together with an exception process with a response time. Without the response time it is not a policy, it is a ban.

One policy for the whole tenant

Why it feels right. One policy is easier to explain, easier to maintain and feels more consistent.

What breaks. It ends as the most restrictive common denominator. It prevents what production needed, and allows too much where experimentation happens.

Instead. Policy per zone. It is more to maintain, but it is the only way to be both strict and usable at the same time.

240
Anti-patterns, 5 to 7

Ownership ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣and operations

Ownership assigned to a department

Why it feels right. It seems robust. People change jobs, departments remain, so ownership should survive.

What breaks. A department does not approve anything, answer an email or notice that a flow has stopped. Ownership without a name is not ownership, it is an address.

Instead. A named person, and a deputy. The department can be the organisational home, but the decision must have a person.

Governance as a project

Why it feels right. It gives a start, an end, a budget and a steering group. That is how the organisation usually gets something done.

What breaks. The project delivers a document and closes. Six months later reality is different, and the document has not been corrected because nobody was left to correct it.

Instead. A project to get started, and then a cadence with a named owner and a fixed hour every week. Governance is an operations task.

Control before capability

Why it feels right. You want control before opening up. It seems like the responsible sequence.

What breaks. A model is built for a reality nobody has seen yet. The rules hit the wrong things because they were written without data about what people are actually trying to solve.

Instead. Open a bounded area, see what happens for three months, and write the model from that. A model written from real cases becomes both shorter and more accurate.

241
Anti-patterns, 8 to 10

Agents ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣and cost

The agent is pointed at everything it can reach

Why it feels right. The more knowledge, the better the answer. It is also technically trivial to add another source.

What breaks. The agent inherits years of accumulated oversharing and makes it searchable in natural language. The access was there all along, but nobody could find anything until now.

Instead. Approve sources one at a time, and review sharing on the source before it is added. Fewer and correct sources also give better answers.

A manually maintained agent registry

Why it feels right. You want an overview, and a spreadsheet is quick to make and easy to share with audit.

What breaks. It is correct on the day it is created. Three months later half is missing, and nobody trusts it anymore. At the same time, the technical inventory already exists in the platform.

Instead. Use the automatic inventory as the foundation, and add only the fields the machine cannot know: owner, purpose, criticality and revisit date.

Consumption without a ceiling

Why it feels right. You do not want to slow the business with a budget ceiling while you are still finding out what things consume.

What breaks. Consumption based costs are first discovered on the invoice. A single misconfigured automation can spend a month's consumption over a weekend, and nobody sees it before it has happened.

Instead. Set a ceiling per environment, and an alert before the ceiling. A ceiling is not a brake, it is an alarm with a built in stop block.

The pattern behind the patterns: nine out of ten anti-patterns arise because someone made a decision that was right at the time, and never had a reason to take it up again. Therefore the most important single guardrail is not a better first decision, but a fixed date to revisit it.
242
Chapter 26

Sequencing⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣

Everything in this material can be done. Nobody can do it all at once. The sequence decides whether the model becomes real.

Principle30 days60 days90 daysAfterwards
Principle

Visibility, ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣then boundaries, then automation

That sequence is not accidental. Each step makes the next one cheaper, and if you swap them around, the work becomes both more expensive and less precise.

Visibility first

You cannot set a boundary before you know what exists. A policy written without an inventory hits the wrong things, and it usually hits neither the dangerous things nor what people are actually making

Then boundaries

Zones, DLP per zone, the default environment put in order, and a place for new makers to land. This is the part that really moves the risk, and most of it is configuration rather than project

Then automation

Cleanup rules, approval gates, exceptions that expire, solution checks in pipelines. Automation on top of unclear boundaries simply enforces the confusion faster

The most common wrong sequence: starting with the tool. A dashboard is installed before anyone has decided who looks at it and what they may do with what they find. The dashboard is not wrong, it is just too early.
244
The first 90 days

Three ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣months, that can be done beside a job

This is set up so it can be carried by one person with a part time allocation and a decision maker who can be reached. If the plan requires a project with a steering group, it will not happen.

Day 1 to 30

See it

  • Inventory all environments, apps, flows and agents with owner
  • Appoint a named platform owner with mandate and a budget
  • Map the default environment: what is there, and who uses it
  • Find the five solutions the business cannot live without, and see who owns them
  • Decide the zone model on a whiteboard. Three zones are enough
Day 31 to 60

Set the boundary

  • Rename the default environment, and remove sharing with the whole organisation
  • Limit who may create environments and trial environments
  • DLP per zone rather than one policy for everything
  • Turn on routing so new makers do not land in the default environment
  • Write the exception process on one page, with a response time
Day 61 to 90

Make it durable

  • The approval gate for agents, eight fields, ten minutes
  • Cleanup rules with notice, start with what nobody disputes
  • Two owners on everything that is broadly shared, and service accounts on connections
  • The cadence in the calendar: weekly, monthly, quarterly
  • A place to ask, and a fixed open hour every week
245
Afterwards

Four ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣questions, that decide whether it held

Six months after a governance model has been set up, four questions can decide whether it is alive or merely documented.

Has the policy been corrected

A model that has not changed in six months is either perfect or unread. Corrections are signs of life, not poor planning

Are there exceptions that have expired

If there are no expired exceptions, they are either extended automatically, or nobody applies for them anymore. Both are a problem

Has the time from idea to use fallen

If it has risen, governance has become a brake rather than a frame. It is the most important single metric, and the first one the business feels

Can someone other than one person answer

If the whole model hangs on one person, it is not a model, it is a dependency. Test it by asking someone else a question

What most often goes wrong in months four to six: the person who drove the work gets another task. The model does not collapse immediately, it stops being maintained, and the decay is first discovered the next time someone asks about it. That is why a named deputy from day one is worth more than it sounds.
246
Chapter 27

Resources⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣

Official documentation, admin portals and a glossary, so the room talks about the same things.

Microsoft LearnPortalsGlossary
Microsoft Learn, part 1

Official ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣documentation

Public, maintained by Microsoft, no sign in. Every path below sits on learn.microsoft.com. Use it when a claim in this material needs checking.

Governance
Adoption best practices
power-platform/guidance/adoption/methodology
Governance
CoE Starter Kit, transition to the admin center
power-platform/guidance/coe/starter-kit
Governance
Admin center, overview and feature areas
power-platform/admin/admin-documentation
Governance
Tenant settings
power-platform/admin/tenant-settings
Governance
Security groups and licences for access
power-platform/admin/control-user-access
Governance
Highly privileged admin roles and self service
power-platform/admin/manage-high-privileged-admin-roles
Environments
Environment strategy
power-platform/guidance/adoption/environment-strategy
Environments
Environments overview
power-platform/admin/environments-overview
Environments
Default environment routing
power-platform/admin/default-environment-routing
Environments
Environment groups and rules
power-platform/admin/environment-groups
Environments
Control environment creation
power-platform/admin/control-environment-creation
Managed
Managed Environments overview
power-platform/admin/managed-environment-overview
Managed
Sharing limits
power-platform/admin/managed-environment-sharing-limits
Managed
Solution checker enforcement
power-platform/admin/managed-environment-solution-checker
Managed
Usage insights (weekly digest)
power-platform/admin/managed-environment-usage-insights
Managed
Maker welcome content
power-platform/admin/welcome-content
Security
Data policies (DLP)
power-platform/admin/wp-data-loss-prevention
Security
Connector classification
power-platform/admin/dlp-connector-classification
Security
Tenant isolation
power-platform/admin/cross-tenant-restrictions
Security
Security in Microsoft Dataverse
power-platform/admin/wp-security
Security
Power Platform security overview
power-platform/admin/security/security-overview
248
Microsoft Learn, part 2

Official ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣documentation, continued

Network, ALM, agents, operations, cost and security.

Network
Virtual Network support
power-platform/admin/vnet-support-overview
Network
IP address and service tags
power-platform/admin/online-requirements
ALM
Application lifecycle management
power-platform/alm/
ALM
Solution concepts
power-platform/alm/solution-concepts-alm
ALM
Power Platform Pipelines
power-platform/alm/pipelines
ALM
Environment variables
power-apps/maker/data-platform/environmentvariables
ALM
Connection references
power-apps/maker/data-platform/create-connection-reference
Agents
Copilot Studio security and governance
microsoft-copilot-studio/security-and-governance
Agents
Generative orchestration
microsoft-copilot-studio/advanced-generative-actions
Agents
Add other agents, connected agents
microsoft-copilot-studio/authoring-add-other-agents
Agents
Knowledge sources
microsoft-copilot-studio/knowledge-copilot-studio
Agents
Autonomous agents and triggers
microsoft-copilot-studio/authoring-triggers-about
Agents
End user authentication
microsoft-copilot-studio/configuration-end-user-authentication
Agents
Microsoft Entra Agent ID
entra/agent-id/what-is-microsoft-entra-agent-id
Agents
Microsoft Agent 365
microsoft-agent-365/
Operations
Application Insights integration
power-platform/admin/overview-integration-application-insights
Operations
Purview activity logs for Power Apps
power-platform/admin/activity-logging-auditing/activity-logs-power-apps
Cost
Licensing overview
power-platform/admin/pricing-billing-skus
Cost
Capacity and storage management
power-platform/admin/capacity-storage
Cost
Copilot Studio credit management
microsoft-copilot-studio/requirements-messages-management
Security
Advanced connector policies
power-platform/admin/advanced-connector-policies
249
Microsoft Learn, part 3

Official ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣documentation, final part

Security, monitoring, governance as code, build options, Entra Agent ID, FinOps and architecture.

Security
Purview for AI
purview/ai-microsoft-purview
Operations
Monitor in the admin center
power-platform/admin/monitoring/monitoring-overview
Operations
Inventory API
power-platform/admin/inventory-api
Governance as code
Power Platform CLI
power-platform/developer/cli/introduction
Governance as code
Power Platform API
rest/api/power-platform/
Build options
Code Apps
power-apps/developer/code-apps/
Build options
Generative pages
power-apps/maker/model-driven-apps/generative-pages
Agents
Agent identity in Agent 365
microsoft-agent-365/builder/identity
Entra Agent ID
Agent identity blueprints
entra/agent-id/agent-blueprint
Entra Agent ID
Owners, sponsors and managers
entra/agent-id/agent-owners-sponsors-managers
Entra Agent ID
Conditional Access for agents
entra/identity/conditional-access/agent-id
Entra Agent ID
Entra identities for Copilot Studio agents
microsoft-copilot-studio/admin-use-entra-agent-identities
Entra Agent ID
Third party agents
entra/agent-id/configure-third-party-agents
FinOps
Govern Copilot Credits, Microsoft Copilot harness
microsoft-copilot-studio/guidance/govern-credit-consumption
FinOps
Usage based billing for Microsoft 365 Copilot
microsoft-365/copilot/usage-based-billing-manage-copilot-credits
FinOps
Pay as you go billing plans
power-platform/admin/pay-as-you-go-overview
Agents
Control maker provided credentials
microsoft-copilot-studio/configure-no-maker-authentication
Agent architecture
Harnesses in Copilot Studio
microsoft-copilot-studio/harnesses-overview
MCP and A2A
Extend an agent with MCP
microsoft-copilot-studio/agent-extend-action-mcp
Responsible AI
Responsible AI for Microsoft Foundry
azure/foundry/responsible-use-of-ai-overview
250
Portals

Where ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣things are actually turned on

Almost every decision in this material is implemented in one of six places. It is worth keeping the list visible in a workshop room, because it moves the conversation from principle to action.

Power Platform admin center
admin.powerplatform.microsoft.com. Environments, environment groups, routing, DLP, Managed Environments, capacity, analytics and Security
Power Apps maker portal
make.powerapps.com. Solutions, pipelines, environment variables, connection references and solution checker
Copilot Studio
copilotstudio.microsoft.com. Agents, instructions, knowledge sources, tools, connected agents and publishing channels
Microsoft Entra admin center
entra.microsoft.com. Security groups, conditional access, service principals, access reviews and agent identities
Microsoft Purview
purview.microsoft.com. Sensitivity labels, data mapping and the consolidated audit trail
Microsoft 365 admin center
admin.microsoft.com. Licence assignment, group based assignment and self service settings
A valuable move in a workshop: open the admin center on screen while you talk. The discussion about whether something can be done typically takes twenty minutes. Looking takes two.
251
Glossary, part 1

Twenty ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣four concepts, one shared understanding

Many governance discussions stall because two people use the same word for two different things. Environment, solution and agent are the worst.

Environment
A bounded container with its own data, its own access and its own policy. Governance almost always happens at this level
Zone
Which risk level an environment belongs to, and how broadly it may reach. Answers the question how dangerous
Stage
Where an environment is in the lifecycle, meaning development, test or production. Answers the question when
Default environment
The environment that exists from day one, where everyone is included, and which cannot be deleted
Managed Environment
A set of administrative controls that is turned on per environment. Everyone who uses its apps, flows or agents needs a premium licence
Routing
New makers are automatically sent to their own environment instead of the default environment
Environment group
A group of environments that share rules, so a setting does not need to be set one place at a time
Data policy (DLP)
A policy that determines which connectors may be used together. A coarse sorting mechanism, not a content filter
Connector
A ready made connection to a system. Classified in a DLP policy as business, non-business or blocked
Connection
A specific person's saved access to a system. It is the person's access, not the organisation's
Solution
The package that an app, a flow or an agent sits in, so it can be moved between environments
Managed solution
A solution that is packaged for deployment and cannot be edited directly in the target environment
252
Glossary, part 2

Glossary, ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣continued

The second half. Use it as a shared reference, not as an exam. The important thing is that the room leaves with the same words.

Pipeline
The mechanism that moves a solution from development to test to production with a trail of who did what
Environment variable
A value that differs per environment, so the same solution can point to different places
Connection reference
A placeholder name for a connection, so the solution does not carry a person's access with it
Dataverse
The database that comes with the platform, with built in access control, audit and relationships
Agent
Instructions, knowledge and tools tied together by orchestration
Generative orchestration
The model itself chooses which knowledge and which tools are used in the individual conversation
Connected agent
An independent agent that is called by another agent as a specialist in a domain
Agent identity
The agent's own principal in the directory, so it can be seen, granted access and disabled
Agent identity blueprint
The template every agent identity is created from. Policy on the blueprint reaches all its identities
Sponsor
The person accountable in business terms for an agent identity. Required, and transferred to the manager when they leave
Showback
Showing each unit what it consumed, without moving the cost to its budget
Chargeback
Moving consumption cost to the budget of the unit that caused it
253
Credits

Thank ⁣‌​​‍‌⁢‍‌​‍​​‌​⁢‌‌‍​‌‌⁢​‍‌‍​⁢​‍​​‌‌​​‌‍​‌‌⁢​⁢‌‍​⁢‌‍​‌‌‍⁢​​‍​​‌‌​⁢⁢​​⁢‍⁢‍​‌‍⁢​‌‍⁢​‌‍‍‌‌‍⁢‍‌‍‌⁢⁣you

People who inspired my own iteration of different chapters in this master deck.

Adi LeibowitzAllan RochaAndreas AdnerArtur BagrancevCarl CooksonChike EduputaClaire EdgsonFeline PareinHenry JamesHolger ImberyJennifer KrauseJens KofodJukka NiiranenJuliane MaackKarl Johan SpiikLaura GBLee FordLeo VisserMatej SamlerMatt BeardNick DoelmanReza DorraniSara FennahScott DurrowShubhangi GoyalSigrid WallinTatu SeppalaTomasz PoszytekWesley NellYannick ReekmansZsolt Zombik

© 2026 Marc Pascal Sølling · Edition 3 November 2026 · Licensed under CC BY 4.0. Share and adapt freely, with credit to the author.

254