Power Automate Governance: Managing Flows at Enterprise Scale

M365 FM - Power Automate Governance - Managing Flows at Enterprise Scale 00:00:00 Speaker: It's two a m a flow wakes up. It reads a customer list, copies the rows into a spreadsheet, and emails the file to an address. Nobody recognises the person who built it left eight months ago. Their account is disabled. Their name is still on the flow. Here's what I want you to see. Power automate doesn't fail at scale because of the tools. It fails because of the governance model behind them. That's why this show exists, to help you find the flows you don't know about. If that's useful, subscribe. We'll cover environments, DLP connections, ALM monitoring, licensing and orphaned flows. But before any control, you need to see what happens when nobody governs. Sponsor segment. Educational break quick break. This episode is supported by stellar Migrator for exchange. It's a tool for mailbox and tenant migrations in the Microsoft ecosystem, and here's why it fits today's topic. Migrations leave things behind. Mailboxes move, but the flows that watch those mailboxes don't follow the connections still point at the old location. Nobody updates them because nobody remembers they exist. So here's one practical point before you migrate anything, list every flow and connection that touches the source. Treat that list as part of the migration plan, not as clean up afterward. If you run exchange migrations, take a look at stellar Migrator. The link is in the description. Now back to the core problem. The old model governance as clean up. In most organizations, Power Automate shows up quietly. Nobody buys it. Nobody plans a rollout. It's just there inside Microsoft three. Sixty five next to word and teams a free feature. And that word free sets the whole model in motion. Free things don't get a budget. They don't get an owner. They don't get an architecture review. Somebody in finance discovers it builds a flow that routes invoice approvals and it works. So they tell a colleague and that colleague tells a team that's how adoption happens, not through a project, through word of mouth. Now underneath that sits an assumption. Low code means low risk. It sounds reasonable. The tool is visual. You drag blocks. There's no code to review, no server to patch. So it feels like a spreadsheet with a few extra buttons. But in reality it does the opposite. Low code lowers the skill needed to build. It doesn't lower the power of what gets built. A person with no technical background can now create something that reads a mailbox, queries a database, and posts results to an outside service all before lunch. So the barrier drops. The risk doesn't. And that's where the governance model breaks, because in most organizations, governance starts after the first incident, not before the first flow. Here's what typically happens. Someone builds a flow. It works so more people build. The default environment fills up hundreds of flows, then thousands. Nobody sees it. There's no inventory. Nobody asked for one. Then something happens. A flow floods a mailbox with ten thousand emails or an audit finds customer data sitting in a personal OneDrive. Or the one person who built the payroll notification flow resigns. Now it's an incident. And now governance finally gets attention. A team forms, they run a cleanup. They send emails asking people to confirm what they own. They write a policy. They block a few connectors. Some of that helps, but look at what it is. It's cleanup. It's the model of governing after the fact. You let the platform grow in every direction. Then you go back and try to bring order to what already exists. You're not designing, you're reacting. And cleanup has a built in problem. It never ends. Every month, new flows arrive faster than the old ones get reviewed. The team that was supposed to fix things ends up chasing them. So why does this keep happening? It's not because the people are careless. It's not because the platform is weak. The flaw isn't the platform. It's the model that treats automation as a feature instead of infrastructure. Think about how you treat a feature. You turn it on. You tell people it's available. You answer questions when they come up. Now think about how you treat infrastructure. You decide where it lives. You decide who can touch it. You decide how it's monitored, how it's backed up, and what happens when the person responsible leaves. Those are completely different postures, and Power Automate is infrastructure. It runs without anyone watching. It holds credentials. It moves data between systems. It makes decisions on a schedule with permissions you granted, years ago you wouldn't let one hundred employees each stand up their own server and wire it into your finance system. But that's what the old model allows, just with a friendlier interface. So the question isn't how to clean up faster, it's whether the model itself is wrong. And to answer that, we need to stop looking at governance for a moment and look at what a flow actually is, what a flow really is. Most people picture a flow as a document. You open it. You see boxes connected by lines. It looks like a diagram, something you could print and pin to a wall so people treat it like one. They share it, copy it, forget it. But a flow isn't a diagram. It's a running identity with permissions. Once you save it and turn it on, that picture becomes a worker. It wakes up on its own, signs in as someone and does things to your data. It's closer to a new hire than to a file. So let's take it apart. A flow has three layers and each one carries its own risk. The first layer is the trigger. That's what starts the flow. A new email arrives, a file lands in a folder, a form gets submitted, or just a clock hitting two a m the trigger decides when your data gets touched and who can cause it. If anyone outside your company can send that email, then anyone outside your company can start that flow. The second layer is the actions. These are the steps. Read a row. Create a record. Send a message. Call a web address. Every action is a decision someone made once and the platform now repeats forever without asking again. The third layer is the connection. This is the quiet one. A connection is the sign in the flow uses to reach a system. It's stored, it's reused, and it decides what the flow is actually allowed to see. Three layers, three risk surfaces. The trigger is about exposure. The actions are about behavior, the connection is about access. And most reviews only ever look at the middle one because it's the part you can see on screen. Now add the part that makes this different from almost everything else. Users create flows run without anyone watching. That's the whole point. Nobody wants to click a button at midnight. You build a flow so the work happens while you sleep. And that's exactly the problem. The same quality that makes it useful makes it invisible. When a flow does the wrong thing, nobody is sitting there to notice. It just keeps going on schedule until something outside it breaks. So here's a better way to think about it. A flow is a non-human worker with access to data. It has a login. It has duties. It has a schedule. It doesn't take a vacation, and it doesn't ask questions. If you told it to email a spreadsheet to the wrong address, it will do that gladly. Every night for years. Now compare that to something you already manage well. A shared file sits still. You can see who opened it last. You can see who has access. If nobody touches it, nothing happens to it. It's risk is passive. Someone has to come along and do something. A flow acts on its own. It doesn't wait for a person. It opens other files, moves them, copies them, sends them. Its risk is active. The danger isn't that someone might misuse it. The danger is that it's already doing something right now and you haven't checked what? That's the structural difference. One is storage, the other is behavior. And most governance programs were built for storage. They ask, who can read this? Who can edit that? Good questions for things that sit still. But a flow needs a second set of questions. What does it do? As whom? Where does it run and who answers when it goes wrong? Notice that every one of those questions starts with a location. Where does it run? That's not a small detail. A flow's location sets the rules around it. Which connectors are allowed? Who can see it, how it's backed up, whether it can be moved at all. Get that wrong and nothing you build on top will hold. So before we talk about policy, before connections, before any control, we need a model for how these pieces fit together. And then we start with where flows live the governance conceptual model. Here's the model I'll use for the rest of this episode. It's built for listening, so it only has three moving parts event Reasoning. Orchestration. The event is simple something gets built. A person opens, the editor, adds a trigger, saves it. That's it. Every governance problem you will ever have starts with that moment, and most of the time nobody is told it happened. Then comes reasoning. This is where a policy looks at what was built and decides if it's allowed or not. A person reading a ticket, a rule. Can this connector sit next to that one? Can this maker create this in this place? The reasoning has to run automatically because the event doesn't wait for a meeting and then orchestration. That's the lifecycle. What happens after the flow is approved? It moves to testing, it moves to production, it gets an owner, it gets reviewed, and eventually it gets retired. Orchestration is the part that keeps going after everyone has stopped paying attention. So something gets built, a policy decides a lifecycle, carries it forward. Now that's the motion. But you also need to know what the policy is deciding about. And that comes down to four questions. I call them control planes. The first plane is where it lives, the environment, the container that sets the rules around a flow before the flow even exists. The second plane is what it touches connectors, data sources, outside services. This is where data loss prevention policies work. The third plane is who owns it? Identity the account behind the connection. The named person. The backup. This is the plane most organizations skip, and it's the one that breaks first. The fourth plane is how it's watched. Inventory. Telemetry alerts. Cost. Without this one. The other three are just intentions for planes where it lives, what it touches, who owns it, how it's watched. Notice something about them. Each one answers a question. You could ask about any flow at any time. Pick a flow at random. If you can't answer all four, you don't govern it. You just host it. And here's why I'm giving you this model. Now before the details. Every section from here maps back to it. Environments are the first plane DLP and connectors are the second connection. Ownership and service identities are the third solutions. Pipelines and monitoring give you the lifecycle. And the fourth plane licensing sits underneath all of it, quietly changing the answers and orphaned and risky flows. Those are what you find when one of the planes was never built. So when something feels confusing later, come back to this. Ask which plane it belongs to. Ask whether the event, the reasoning or the orchestration is missing because in reality, most governance programs aren't missing effort. They're missing a plane. A team will spend a year writing connector policies, which is plane two. While nobody can say who owns a single production flow, which is plane three, all that work and the model still has a hole in it. That's the difference between a list of controls and a structure. A list can be long and still leave gaps. A structure tells you where the gap is, so we'll go one plane at a time and we start with the first one where it lives. Environment. Strategy. Why the default environment fails. Every tenant starts with one environment already in place. It's called the default environment. You didn't create it. Nobody did. It was there the day the tenant was born. And it has one rule that shapes everything else. Every licensed user in your organization is automatically a maker in it. Every one of them. No request, no approval. So when someone opens Power Automate for the first time, where does their flow land? Right there in the shared space with everyone else's. And that's the first problem. Everything goes into one container the invoice approval for finance, the vacation reminders someone built for their own team. The test flow from a Friday afternoon. The flow that syncs customer records. Same place, same rules, same visibility, or really same lack of it. Now here's what makes this hard to fix later. The default environment has limits. You can't change. You can't delete it. You can't back it up and restore it the way you can with other environments. And you can't lock it down cleanly because removing the maker role from everyone breaks the thing it was designed to do. So you're stuck with a space you can't remove, can't fully protect, and can't easily restrict. What typically happens is that it fills up quietly month after month. Teams build things for themselves, for their department, for a one off task. Some of it gets shared with a colleague, some of it gets shared with a whole group, and over time, a pile forms that nobody chose to create. That pile has a name shadow automation. It isn't malicious. It's just work that happened outside any plan. A flow built by someone in sales, wired to a shared mailbox, feeding a spreadsheet that three other teams now depend on. Nobody in it knows. The sales manager doesn't think of it as a system. It's just how the report gets done until the maker changes jobs, or the spreadsheet moves or a policy blocks a connector. The flow quietly needs. Then the report stops and suddenly it's a production outage in something that was never supposed to be production. And this points to a deeper issue. The default environment mixes two very different kinds of flows. In one container. On one side you have personal productivity. Save my email attachments to my own folder. Remind me about meetings. Post a message when I get a form response. Low stakes built by one person for one person. On the other side, you have business critical flows, anything touching customer data, finance, HR, or a process other people rely on. Those two kinds need opposite treatment. Personal flows need freedom and speed. Critical flows need review, backup, testing and a named owner. But when both live in the same place, you can't give either one what it needs. If you tighten the rules to protect the critical ones, you strangle the personal ones. If you loosen the rules to keep people productive, the critical ones sit exposed. So most organizations pick the loose option because it's the one that doesn't generate angry emails. And that's how a payroll flow ends up living next to someone's lunch order reminder. So what's actually happening is not a failure of discipline. It's a failure of placement. You asked one container to do two incompatible jobs and this is the shift. Stop treating the default environment as a home. Treat it as a sandbox with hard limits. A sandbox is a place where people can try things. It's expected to be messy. Nothing in it is promised to last, and that's the message you give your makers. Build here to learn. Build here for yourself. But anything that matters moves out. Then you back that message with real limits. Tight rules on which connectors can be used. There a strict policy against sharing with large groups. A clear line that says business critical flows don't belong in this space, and ideally a regular sweep of what's accumulated. You're not trying to clean it forever. You're changing what it means. It stops being the place where flows live. It becomes the place where flows start. But that raises an obvious question if the default environment is only a starting point, where do the flows that matter actually go? Designing the environment topology. Start with the smallest set that works for types of environment, personal productivity, development, test and production. Personal productivity is where individual makers play. development is where a team builds something real test is where that something gets checked before anyone depends on it. Production is where it runs for the business. That's the minimum viable set. Fewer than that, and you're mixing jobs again, more than that. And you can add later once you know why. Now comes the harder question how do you divide the work across them? There are three common ways you can create environments per business unit. Finance gets its own, HR gets its own. You can create them per application. The expense system gets a set, the onboarding system gets a set, or you can split by risk tier. So anything touching regulated data lives apart from everything else. Each one has a failure mode per business unit is easy to explain and it matches the org chart. But org charts change every organization lens and suddenly your environment boundaries describe a company that no longer exists per application. Gives you clean ownership, one system, one team, one set of environments. But it multiplies fast fifty applications means one hundred and fifty environments, and someone has to manage them all. Paresthesia is the one most people skip, and it's the one that maps best to what governance actually needs. Because the rules you apply which connectors, who has access, how strictly you review, follow the risk, not the department. So in practice you blend them. Risk tier sets the baseline business unit or application sets the boundary inside it. The point isn't to pick one pattern, it's to know which question each pattern answers. Next. Managed environments. A managed environment is a standard environment with extra controls switched on, and those controls matter because they turn a container into something you can actually govern. You get sharing limits. So a maker can't share a flow with the whole company by accident. You get usage insights which show what's running and who's using it. You get a weekly digest sent to admins. You get rules around solution checks so poor quality gets flagged before it ships, and you get control over how makers are welcomed into the space. There's a cost, though. Managed environments require premium licensing for the users in them, so you don't turn it on everywhere you turn it on. Where the risk is. Production and shared development almost always personal sandbox is probably not. Now the decisions you make once and regret often naming. Pick a convention on day one, something that tells you the unit, the purpose, and the stage in a pattern. Someone can read at a glance because three years from now, an environment called test two final will cost somebody an afternoon tagging record the owner, the cost center, and the data classification on every environment. It feels like paperwork, but when finance asks who's paying for that capacity, you'll have an answer region. This one is almost permanent. An environment lives in a geography and it stays there. If your data has residency rules, decide before you create anything. Moving later means rebuilding. And then the question that changes your whole design, Dataverse or no Dataverse, every environment can have a Dataverse database, and Dataverse brings real capability. Solutions work properly, security roles work properly. You get a managed place for data with auditing and structure, but it brings cost. Storage counts against your capacity, and capacity is something you pay for. So the trade off is plain. A Dataverse environment gives you the tools for real life cycle management. An environment without it is lighter and cheaper, but it limits what you can do with solutions and control for production. The answer is usually yes. For throw away sandboxes, usually no. So now you have a shape, types, boundaries, controls, and a few early decisions that stick. But a topology is only containers. It says nothing about who gets to build inside them. Environment routing and maker onboarding. Here's a problem that shows up right after you design a clean topology. Nobody uses it. A new maker opens Power automate and where do they land? The default environment. Every time your carefully planned structure sits there empty, while the real work keeps piling up in the one place you want it to move away from. That's where environment routing comes in. Routing is a setting that changes where new makers start. Instead of dropping into the shared default space, each person gets sent to their own personal developer environment. It's created for them automatically the first time they open the maker portal, a private workspace, one per person, and that changes the default behavior without asking anyone to change the path of least effort. Now leads somewhere safe. Flows built there are isolated from everyone else's. They can't be shared widely, and you can attach rules to those environments like tight limits on what they can connect to without touching anyone who's doing real production work. The maker doesn't have to understand any of this. They just build. You've moved the starting line. Now, there's a related right that deserves more suspicion than it gets. Who can create environments by default? Anyone can create a trial environment, and in many tenants, anyone can create a developer environment too. Each one is a new container outside your naming, outside your tags, outside your policies. Multiply that by a few thousand users and your topology becomes a rumor. So restrict it. Limit environment creation to a small group, the platform team and nobody else. Treat the right to create a container. The way you treat the right to create a subscription in Azure, it should be rare on purpose and tied to a request that someone can trace. But restriction alone feels like a wall and walls create workarounds, so pair it with onboarding because the moment a maker lands in their new environment is the best moment you'll ever get to communicate rules. They're curious. They haven't built anything yet. They're paying attention. Use that with managed environments. You can set a welcome message that shows up when a maker enters short a few lines on what this space is for, what belongs here and what doesn't, and a link to your guidance. Then one more thing and it matters more than the rest. A contact point, a real mailbox, or a team's channel with a human behind it that turns a policy document. Nobody reads into a moment that people actually see, and it does something subtle. It tells makers that someone is on the other side, that the platform has owners, and those owners are reachable. Now, the last piece of this plane is access, and it's where the topology gets its teeth. Makers can build in personal and development spaces, but production that's gated use security groups to control who gets into each environment and security roles to control what they can do. Once inside, a maker might hold the right to create flows in development, while only a small deployer group holds any rights in production. The principle is simple building and running shouldn't belong to the same crowd. The person who experiments shouldn't be the person who can change what the business depends on, at least not directly. So now the picture is more complete. Containers exist. Makers are rooted into them. Creation rights are scarce, rules arrive at the right moment and production sits behind a gate. But a place to build only answers the first question. It says nothing about what those flows can reach once they're running. 00:18:37 Speaker: The DLP policies. The model behind the wall. Start with a name that misleads. Data loss prevention sounds like a scanner. Something that reads your files, spots a credit card number, and stops it from leaving. That's not what this is. A DLP policy and power platform never reads content. It doesn't look at a row, a file, or a message. It looks at connectors, the building blocks of flow uses to talk to other systems SharePoint, outlook, SQL, Twitter, Dropbox. Each one is a connector and the policy decides which of them are allowed to appear together in the same flow. So it's not a content scanner, it's a connector firewall. And it works by sorting. Every connector goes into one of three buckets. The first bucket is business. These are the connectors you trust with company data. Think SharePoint, Dataverse outlook teams. The second is non-business. These are connectors you tolerate but don't want near your business data. Social platforms, personal storage, consumer services. The third is blocked. These can't be used at all in any flow in the scope where the policy applies. Now here's the rule that makes the whole thing work. A single flow can't mix business and non-business connectors. Pick one group. Stay in it the moment someone tries to connect SharePoint to a personal cloud drive in the same flow, the platform refuses. That's the wall, not around a connector between two groups of them. So what's actually happening is a statement about combinations. You aren't saying SharePoint is good. You're saying SharePoint can never share a flow with a consumer service. The data stays on its side of the line because the path out doesn't exist. And that's a more honest control than it first looks. You can't stop every mistake a maker will make, but you can remove the specific road that leads from your customer list to somebody's personal account. Now, where do these policies apply? Two scopes and they stack. The first is tenant level. A tenant policy covers every environment you own, including ones created later. It's your floor. Whatever you put here, nobody gets below it. The second is environment level. These policies cover only the environments you choose, and that's where you tune strict for production, loser for a sandbox, a different shape, for an environment that exists only for one integration. When both apply to the same flow, the platform combines them and the combination is always the stricter result. A connector blocked in either policy is blocked. Two connectors kept apart by either policy Stay apart so you can't accidentally loosen things by adding a second policy. You can only tighten. That's a useful property because it lets different teams own different layers. The security group owns the tenant floor. The platform team owns the environment rules above it. Nobody has to negotiate every connector from scratch. But here's the flaw. And it's not in the technology. Most teams create a DLP policy once, usually right after an incident, usually in a hurry. They sort the connectors they know about into buckets, save it and move on. Then the platform keeps changing. New connectors appear, existing ones add actions. Microsoft Ships features partners publish connectors, makers build custom ones. And that policy, written on one afternoon, quietly stops describing reality. A new connector arrives and it lands in whatever default group you set. If that default is business, then a connector you've never reviewed is now trusted with company data. Nobody decided that it just happened. So the policy isn't a setting. It's a decision that needs a review date. And that raises the practical question. Knowing the three buckets, how do you fill them? Because there are hundreds of connectors and sorting them alphabetically gets you nowhere. The answer is to start somewhere else. DLP in practice designing for real work. Start with the work, not the connector list. Ask finance what they automate. Ask HR, ask sales. You'll hear things like approvals, onboarding steps, reminders, report refreshes, and syncing records between two systems. Write those down as scenarios. Each one is a small story with a start and end and a handful of systems in between. Now the connectors have a reason to exist. SharePoint and outlook and teams show up in almost every scenario, so they go in business. A consumer file sharing service shows up in none of them, so it lands in non-business or blocked. You're not guessing anymore. You're sorting by evidence. But here's the pressure. There are hundreds of connectors and nobody has time to review them one by one on day one. So don't sort in layers. First, the connectors your scenarios use today. Those get a deliberate home. Second, the ones you know are dangerous personal storage, social platforms, anonymous web tools those get blocked or pushed to non-business. Third, everything else. And for that last group, set the default bucket to non-business or blocked never business that way a connector nobody has reviewed starts out isolated, and you promote it only when someone asks and someone checks that one choice flips the old pattern. New connectors arrive untrusted and you grant trust on purpose. Now the loopholes. Because a policy only governs what it can see by name. And there are doors people forget. The first is custom connectors. A maker can wrap any web service in a custom connector, give it a friendly name, and use it in a flow. Unless you handle them. The policy treats them as one more connector and by default they can slip into the wrong group. The second is the HTTP action. It's a generic block that calls any web address, and it sits in a connector group of its own. If that group sits in business, then every flow with business data can call any endpoint on the internet. That's not a small gap. That's the exit sign left unlocked. So treat the HTTP connectors the way you treat an open port, block them or push them into non-business, and then allow specific exceptions where a team can explain why. And that leads to finer tools, because blocking a connector outright is a blunt move, and blunt moves create workarounds. Connector endpoint filtering lets you say something more precise for the HTTP connector and a few others. You can allow only certain web addresses and deny the rest. So a flow can call your own internal API and it can't call a random address a make or paste it from a forum. Order matters here too. The rules are checked top down with the first match winning, so you place your allow rules above a final deny all. Then there's connector action control. Some connectors have many actions and not all of them carry the same weight. Reading a file is one thing. Deleting a whole folder is another. With action control, you can allow a connector while blocking its riskiest actions. The connector stays useful. The sharp edge goes away. Both of these keep the business moving, which is the real test. A policy that stops everything gets bypassed. A policy that stops the right three things gets kept. Last piece one policy for everything is the wrong shape. Production should be strict. A short list of approved connectors. Endpoint filtering on no experiments. A sandbox can be. Loser makers need room to learn, and a mistake in a throwaway space costs nothing. A personal developer environment can sit somewhere in between. So you build a tenant floor that blocks what no one should use anywhere. Then you layer environment policies on top tune to what each space is for strict where the stakes are real, open where they aren't. That's a design you can defend in a meeting. Every rule traces back to a scenario, a risk, or a reason. But there's a cost to all this, and it doesn't land on a design document. It lands on flows that are already running. DLP rollout breaking flows on purpose safely. Here's what actually happens when a policy lands flows that now violate it don't get deleted. They get suspended. The platform flags them, stops them from running, and keeps everything else intact. The logic, the history, the owner, all still there. That's a mercy. And it's also a trap. Because suspended means silent. Nobody gets a siren. A flow that ran every morning at six just doesn't run. And the first sign is a colleague asking why the report is empty so you don't discover the damage after enforcement. You measure it before. Start with an impact analysis. The admin center can show you which flows would break under a policy you haven't turned on yet. Pair that with your inventory and you get a list which flows in which environments built by whom, touching which connectors. Now the policy has a price tag you can read and the list always surprises someone. A connector you were about to block turns out to feed forty flows across three departments. Fine. That's not a reason to stop. It's a reason to sequence. Sort the affected flows by what they do. A personal reminder can break and nobody dies. A flow that sends customer invoices cannot. So the second group gets attention first with a real conversation, and the first group gets a notice. Which brings us to communication. This is where most rollouts go wrong, and it has nothing to do with technology. Makers should hear about the change from you, not from a failed run. So write to them before enforcement and keep it short. What's changing on what date, which of their flows are affected and what they should do about it. Name the flows a message that says some flows may be impacted gets deleted. A message that says your expense approval flow uses a connector we're blocking on the fifteenth gets red, then give a window. Two weeks is common, long enough to act short enough to matter and send a reminder halfway through. Because the first message always lands during somebody's busiest week, some flow still won't be ready. A team has a real need, a real deadline, and no time. That's where an exception process comes in. And exceptions are dangerous in a specific way. Not because you grant them, because they stick. An exception made for one flow in one quarter quietly becomes the standing practice. Someone points to it and says, you let finance do it. Now it's the rule you were trying to avoid with extra steps. So build exceptions with edges. Everyone needs a name requester, a business reason, a scope limited to a single environment and an end date. When the date comes, the exception expires unless someone renews it on purpose. Put them in a place a reviewer can see so that you read the list every quarter, and not only when something goes wrong. One more habit worth having. Roll out in stages. Apply the policy to a test environment first, then to one business unit that's ready for it, then wider. Each stage teaches you something the impact analysis couldn't and each one is small enough to fix. Done this way, breaking flows isn't a risk. It's a planned event with a list, a notice, and a way back. But look at what a policy controls connectors the roads between systems. It says nothing about who is walking down them. Connection ownership. The identity problem. A connection is a stored credential. That's all it is. When a maker adds an action that reads a mailbox or writes to a list, the platform asks them to sign in. They do, and that sign in gets saved so the flow can reuse it every time it runs. Now read that again. Slowly the flow runs as whoever created the connection, not as the company, not as a system, as a person with that person's access, that person's rights and that person's mailbox. So when a flow reads the finance shared folder at two a m, it's really Sara from accounting reading it. Except Sara is asleep and she doesn't know it's happening. In most organizations, this is how nearly every flow is built. A maker signs in with their own account because it's the account they have. It works on the first try. They move on. And that's the single biggest source of fragility in the whole platform. A business process now depends on one human being's identity. Think about what can happen to that human being. They leave the company and their account gets disabled, so every connection under it fails at the next run. They change roles and their access gets trimmed so the flow can no longer see the data it was built for. Or they just get a password reset. Policy forces a change, or they forget it, or someone flagged a suspicious sign in, the stored credential goes stale and the flow starts failing. None of those events involve the flow. Nobody opened the editor. Nobody touched the logic. The flow broke because something happened to a person and nobody connected the two. There's a quieter version two A flow doesn't always stop when the owner changes jobs. Sometimes it keeps running with the old permissions, which the person no longer should have. A manager moves to a new department, and a flow built under their old role keeps reading data from the department they left. Nobody approved that. It's just what the stored credentials still allows. So the same design produces two opposite failures. Sometimes the flow breaks when it shouldn't. Sometimes it keeps working when it shouldn't. Now shared connections make it more complicated. A maker can share a flow with a teammate and the connection comes along inside it. The teammate can now edit that flow and in some cases, use the connection under the original makers identity. They didn't get access to the mailbox, but their actions reach it through a sign in that belongs to someone else. That's the hidden part. Sharing a flow isn't just sharing logic, it's sharing the authority behind it. A person who could never open the finance folder might be able to build a flow that reads it. If the connection is already there and nobody checked who it belongs to, and that matters for audits, look at the logs and every action shows the original maker's name, not the person who edited the flow last Tuesday. So the record says one thing, and what actually happened is something else and one level deeper, there's a distinction most people skip entirely. A connection reference is not the connection. The connection is the credential itself, the stored sign in tied to one identity. Living in one environment. The connection reference is a pointer inside a solution. It says this flow needs a connection of this type, and I'll find the real one when I'm deployed. That difference sounds technical, but it decides whether your flow can move. If a flow points directly at a specific person's connection, it's welded to that person and that environment. If it points at a reference, you can swap the real connection at deployment time and the flow doesn't care who's behind it. We'll come back to how solutions use that for now. Notice what it tells you. The platform already has a way to separate the logic of a flow from the identity it runs, as most flows just never use it. So the problem isn't that connections exist. A flow has to sign in somewhere. The problem is whose name is on the sign. And the fix isn't a better policy or a stricter review. It's a different kind of identity altogether. Service accounts. Service principals and run as choices. The first fix most teams reach for is a service account. A normal user account created for a purpose instead of a person. Nobody's name on it. Something like SVC finance automation. Make us sign in with that and the flow no longer depends on one employee staying employed. It's a real improvement, but it brings its own costs and they show up fast. The first is licensing. A service account that runs flows, is still a user, so it needs a license. Premium connectors need a premium license. Multiply that by a dozen business processes, and you're paying for identities that never open a screen. The second is MFA. Your tenant rightly demands multifactor sign in, but a service account has no phone and no person standing by to approve a prompt. So someone carves out an exception. And now you have an account with broad access and a weaker door. That's the opposite of what you wanted. And the third is the password. Nobody rotates. It was set once by someone who has since moved on. It lives in a shared document or a head. When policy finally forces a change, the connection breaks and nobody knows where the new secret should go. So the service account swaps one fragile identity for a different, fragile identity. Better but not finished. The next option is a service principle. This is an app registration in entra ID, an identity built for software instead of people. It signs in with a secret or a certificate, not a password and a prompt. It needs no mailbox and no seat in your user directory. And because it isn't a user, MFA doesn't apply the same way. Now the limit. Not every connector supports it. Dataverse does some Azure and Power platform connectors do. Many of the popular ones don't yet. So a service principle is where you go when the connector allows it, and a service account is the fallback when it doesn't. That's a decision worth writing down for each connector, your organization relies on record which identity type it supports. Otherwise, every team rediscovers the answer the hard way. But there's one more choice, and it sits inside the flow itself. Who does it run as when someone else triggers it? Take a flow that a user starts with a button or from a team's message, you can set it so the flow runs with the connections its owner embedded. Everyone who triggers it borrows the owner's access. Or you can make it run with the connections of the person who triggers it, their own sign in their own rights. They look similar. They behave very differently. Embedded connections are predictable. The flow does the same thing for everyone because it always acts as the same identity. That's what you want for a process, like write this record to the finance system where the user shouldn't need direct access. Invoker connections are the opposite. The flow can only touch what the person pressing the button could touch anyway. That's the safer pattern. When the flow acts on the user's own data, like their calendar or their files, no privilege gets borrowed. The mistake is choosing by convenience. Embedded is easier, so everything becomes embedded and the button in teams quietly hands a hundred people the reach of one powerful account. Then there's run only users, which is where you decide who can use a flow without being able to change it. They get to run it. They can't open the editor, swap the logic, or see how it's wired for anything business critical. That's the right line between using and building. Now put people around all of this because identity without accountability just moves the problem. Three questions need an owner who approves a new service identity, who rotates its secret and on what schedule, and who audits it to confirm it still has only the access it needs. If the answer to any of those is whoever set it up, you've recreated the original problem with a longer name. So build an ownership register a simple record, and it only has to be accurate. Every production flow has a named person and a named backup. The identity it runs as, the connectors it uses. The date someone last confirmed all of that. When the owner leaves, the backup steps up and nothing breaks because nothing depended on one person. Identity is now stable, but a stable flow stuck in one environment still can't move arm and solutions. Why? Loose flows don't scale, open any tenant and look at how most flows were built straight in the editor. Saved. Turned on. No package around them, no version behind them, no record of what changed last month. That's a loose flow. And a loose flow has a hard limit. You can't move it, you can't version it and you can't reproduce it. Try to copy one into production. You export a zip, import it, and then spend an hour fixing connections by hand. Try to answer what changed before it broke last Tuesday. There's no answer because nobody saved one. Try to rebuild it after someone deleted it by accident. You're working from memory. The flow works. But the thing that makes it work lives only in one place, inside one environment, under one person's hands. That's the gap. Application lifecycle management is meant to close. And on this platform, the tool for closing it has a plain name, a solution. A solution is a container. You put flows in it along with the other pieces. They depend on tables, apps, connection references, settings. Then the whole thing travels as one unit. It has a name, a version number, and a publisher. When you move it, everything it needs moves with it, and the platform knows which parts depend on which. That dependency tracking matters more than it sounds. Delete a table that three flows read from and the platform warns you. Without a solution, those relationships exist only in someone's head. Now, the first real choice. A solution comes in two forms. Unmanaged is the open form. You can edit every piece. It's where you build changes apply directly, and the pieces can be pulled out and reshaped. Managed is the sealed form. It's a locked package. You can install it, upgrade it and remove it cleanly, and you can't casually edit what's inside. The pieces belong to the package. And here's the rule that holds the structure together. Development uses unmanaged and everything after it uses managed test gets managed. Production gets managed. Always. Why? Because production should never be edited in place. When a fix gets made straight in the live environment, it's invisible to the pipeline. The next deployment overwrites it and the fix disappears. Or worse, the live version quietly drifts from everything you have in development and nobody can say which is correct. A managed solution closes that door to change production. You change development and you ship a new version slower by ten minutes, safer by a lot. There's also a cleanup benefit that people overlook. Remove a managed solution and its components go with it. Remove an unmanaged one and the pieces stay behind as debris. Over time. That debris is how you end up with flows nobody remembers creating. Now, a package that moves between environments has a problem. The flow inside it points at things that differ from place to place. A different mailbox in. Test a different site in production, a different connection tied to a different identity. If those were hard coded, the flow couldn't travel. Every move would break it. So two pieces make portability possible. Connection references, which we met a moment ago. The flow points at a reference instead of a real sign in at deployment, you bind that reference to whichever connection belongs in the target environment. In production, that's the service identity, not a maker's account. The logic stays the same, only the identity underneath swaps and environment variables. These hold the values that change between places a site address, a folder path, a threshold, a mailbox name. The flow reads the variable. Each environment supplies its own value so you never open the flow and edit a web address by hand on the way to production, which is exactly where mistakes get made. Put together a flow in a solution stops being welded to where it was born. It can be built in one place, checked in another, and run in a third with the right identity and the right settings supplied each time. That's what turns a pile of flows into something you can ship, but a portable package is still just a file sitting somewhere. Something has to carry it on purpose from one environment to the next. 00:37:31 Speaker: Building the pipeline. Dev test production. Now the carrying part. Something has to take that managed package from one environment to the next. The same way every time. You have two main options. The first is power platform pipelines. It's built into the platform, and admin sets up a pipeline once with a development environment at the start, then test, then production. Make us see a deploy button inside the solution. They click it, pick the next stage, and the platform does the import the connection binding and the environment variable settings. No zip files, no downloading and uploading by hand. The second is Azure DevOps or GitHub actions. This is the route for teams who already run code pipelines. Here, the deployment is a script stored in a repository triggered by a merge or a release. It's more work to set up and it gives you more control. Custom checks, approvals tied to your existing tools, one process for apps, flows and everything else the company ships. So which one pipelines fit when you want speed and low effort and your makers aren't developers? The code route fits when you have a platform team, other pipelines to match, or rules about who must sign off. Many organizations use both built in pipelines for team level work, a scripted process for the business critical set. Either way, the same few controls decide whether it's governed. Start with gates. A deployment to test can be automatic. A deployment to production should not be. Put an approval in front of it and make the approver someone who isn't the person who built the thing. Even a short check changes behavior because now somebody has to look at what's about to ship. Add solution checks to the platform, can scan a solution before it moves, and flag problems, hard coded values, broken references, patterns that will fail later. Wire that in as a requirement, not a suggestion. So a flawed package stops at the gate and never reaches users. Then there's source control. A solution file is a compressed bundle and compressed bundles are hard to compare, so you unpack it. The tooling can break a solution into readable pieces one file per flow per table per setting, and store those in a repository like GitHub or Azure Repos. Now something changes. Every edit becomes a commit with a name and a date on it. You can see who altered the approval step last month and what it looked like before. You can compare two versions side by side. You can answer the question that a loose flow never could. What changed before it broke? That history is also your audit trail. When someone asks why a flow behaves differently today, you don't guess. You open the log next roll back and this part needs honesty. People assume they can just undo a deployment. You mostly can't manage solutions, support upgrades, and in some cases a patch or a prior version you can import. Again, if a new version has a logic error, you can often redeploy the last good one that works for flows because flows are logic. But data isn't logic. If the new version changed a table, added a column, or ran a step that wrote records, importing the old version doesn't reverse any of that. The rows are already written. Some deletions in a managed upgrade can't be undone at all, so plan for rollback before you need it. Keep the previous package versioned and ready. Test the deploy path in a copy of production first, and decide in advance which changes are reversible and which ones need a backup of the data before they go. The last control is about people separate makers from Deployers. The folks building and development shouldn't hold rights in production. A small group or the pipeline's own service identity carries the package forward. That's the same principle we used for environment access applied to movement. It feels like friction. It's actually what lets you answer an auditor with a straight face. Nobody changes production by hand. So now flows can be built, packaged, checked and moved on purpose. But a pipeline treats everything the same and not everything deserves that support. Tiers and flow classification. Here's an assumption that quietly wrecks governance programs that every flow deserves the full treatment solution. Packaging source control, a test stage, a named backup, a runbook, all of it for everything. It sounds responsible, but picture what it does to the person who built a flow that posts a team's message when their form gets a response. You've just asked them to fill out a deployment request for something that affects exactly one human being. They won't do it. They'll build it somewhere you can't see. And now you've lost the very visibility you were chasing. So the model has to scale with the stakes. And the simplest way to do that is tiers. Three are enough. The first tier is personal. One maker, one purpose. No one else depends on it. A reminder a file. Save a notification. These live in the personal developer environment under the tight connector rules we set earlier, the requirements here are almost nothing. The maker owns it and the platform keeps it in bounds. If it breaks, the cost is one person's inconvenience. The second tier is team. A group of people relies on this flow, even if no one calls it a system. A weekly report for a department, an intake process for a shared mailbox. Now the rules tighten a little. There must be a named owner and a named backup. The flow sits in a shared development or team environment, and it should be inside a solution so it can survive someone leaving light documentation, a few lines on what it does and what it touches. Testing is informal, but it exists. The third tier is business critical. The business stops or loses money or breaks a rule. If this flow fails, anything touching customer records, finance, HR or regulated data lands here. No matter who built it or how small it looks, the full treatment applies a managed solution deployed through the pipeline with approvals, a service identity instead of a person, a test stage with real checks, written documentation and escalation contact, and an alert that reaches a human who can act. Notice what drives the tier. It's not the number of steps or how clever the logic is. It's the blast radius. A forty step flow that formats a personal calendar is tier one. A three step flow that updates a payroll table is tier three. That's why classification needs a question, not a feeling. Ask the owner a few plain things. Who depends on this? What data does it touch? What happens if it's down for a day? What happens if it runs wrong? The answers place it and the tier tells everyone what comes next. Now flows. Don't stay where you first put them. And this is where most organizations get stuck, because the real world has a habit of promoting things without telling anyone. The sales flow that started as one person's shortcut gets shared. Then a manager builds a dashboard on top of it, then a second team copies it. Eighteen months later, it's tier three in everything but paperwork, so you need a promotion path, one that's easy to walk and hard to skip. It starts with a trigger. Usage crosses a line, a new person relies on it, or it begins touching a more sensitive connector. Any of those prompts a review the owner or your monitoring raises a hand. Then the flow moves up a tear. It's packaged into a solution pointed at a service identity deployed into the right environment and given its documentation and backup owner, make that path visible and a little rewarding. When promotion means better support and a stable home. Make us ask for it. When promotion means paperwork and punishment, they hide. And one more point demotion exists to a tier three flow that no longer matters. Shouldn't carry enterprise costs forever, but tiers raise a practical problem. To place a flow, you have to know it exists, who owns it, and how often it runs, and that information has to come from somewhere. Monitoring. Seeing what runs. Start with what you already have. The Power platform admin center ships with analytics, run counts, success rates, failure trends, top flows by activity. Open it and it feels like an answer. A chart goes up, a chart goes down and someone says we have monitoring. But look closer at what it measures. It shows activity. It shows volume. It doesn't tell you whether a flow should exist. Who stands behind it or what data it touches. A flow that runs ten thousand times a day. Moving customer records to a place it shouldn't. Looks healthy on that chart. Green. Busy? Fine. That's the floor. These dashboards describe behavior. Governance needs identity. So the next layer is the Center of Excellence starter kit. Microsoft publishes it as a set of solutions you install in your own tenant. It pulls an inventory of apps, flows, connections makers and environments into Dataverse, then gives you reports on top. Which makers are most active, which flows, use premium connectors? Which resources have no owner or haven't run in months. It also carries compliance flows that email makers and ask them to confirm what they've built, and that's genuinely useful for many organizations. It's the first time anyone sees the whole estate in one place but know its limits. It's a starter kit. It runs on flows of its own, which need care, licensing and an owner. Or it becomes one more thing nobody maintains. It syncs on a schedule. So what you see is a recent picture, not a live one, and it reflects what it can reach in a big tenant with hundreds of environments, a misconfigured sink quietly leaves gaps and nothing tells you the gap is there. There's another constraint hiding in the platform itself. Run history Cloudflow runs. Keep the history for a short window. Around twenty eight days after that, the detail is gone. So when someone asks what a flow did six weeks ago, the platform shrugs. If you need longer memory, you have to capture it yourself and decide ahead of time what's worth keeping. That pushes you toward the admin APIs and the audit logs the admin APIs through PowerShell modules and the management connectors let you list every flow in every environment, including who created it, when it changed, and its current state. That's your tenant wide inventory built on your own schedule, not the sync of a template and the unified audit log in. Microsoft purview records. Activity flows. Created. Edited. Shared. Turned on. Deleted. Retention depends on your licensing, so check yours because a log you can't search back far enough is a log that fails the moment you need it. Notice how the three sources fit together. Admin center analytics tell you what's running right now. The starter kit gives you a browsable inventory with some built in process, and the APIs and logs give you the raw, durable record you can query, store, and combine with anything else like your HR data or your identity data. None of them is complete alone. A mature setup uses all three on purpose. Now with all that data, it's easy to build one hundred reports and answer nothing. So hold on to one question and let every report serve it. What flows exist? Who owns them and what do they touch? Three parts existence, ownership, reach. Existence means a complete list, not a sample. Every flow, every environment, including the ones in places you forgot you created. If your list has gaps, everything downstream is a guess. Ownership means a real person today who's still employed and still in a role that makes sense, not the name from the creation date. The current one checked against your directory and reach means connectors, endpoints, and data sources. Which systems does this flow read from and which does it write to? That's where risk actually lives. A flow that touches nothing sensitive can sit unattended for years. A flow that touches payroll cannot. When you can answer those three. For every flow, you've stopped monitoring activity and started monitoring the estate. That's the shift. But an inventory is a photograph. It tells you what exists, not whether it's still doing its job. Telemetry alerts and failure. Handling a flow can fail in two ways loudly or quietly. Loud failures are easy. A run turns red and email lands. Someone fixes it by lunch. The platform handles that case reasonably well because the flow stopped and said so. Quiet failures are the problem. A flow that runs but processes nothing. A trigger that stopped firing because a connection expired, a flow that got throttled, slowed to a crawl, and now finishes six hours late. Every run shows as succeeded or doesn't show up at all, and nothing looks wrong on any chart. That's the silent failure problem. The absence of an event is still an event, and most setups can't see it. Throttling deserves its own mention here. Every connector has limits on how many calls it accepts in a given window, hit the ceiling and the platform doesn't crash your flow. It delays it, retries it, and sometimes gives up. After a while, the business sees an approval that took a day instead of a minute. The platform sees a flow doing what it was told. So you need telemetry that lives outside the flow itself. Cloud flows can send their run data to Application Insights and from there into Azure Monitor. That's a connection you set up at the environment level through the data export option in the admin center. Once it's on, every run streams out, start time, end time, status errors, and the flow's identity. You get a record that outlives the twenty eight day window and you get something you can query, and querying is where it gets useful. You can ask how many runs failed this week by environment. You can ask which flows slowed down compared to last month. You can ask which ones haven't run at all when they normally run every morning. That last query catches the quiet failures, the flows that went silent. Now data nobody reads is just storage. The next piece is alerting and the test for an alert is blunt. Does it reach a person who can act? Most don't. The default failure email goes to the flow owner, the very person who might have left, or who filters those messages into a folder. So a business critical flow fails and the only notification sits in an unread inbox. Route alerts by tier instead. For tier three flows, failures should hit a shared channel, a ticket queue, or an on call rotation. For tier two, the team owner and their backup for tier one the maker and nobody else needs to care. In Azure Monitor, you build alert rules on the queries above, and you point each rule at an action group, an email list, a teams message, a webhook into your service desk. Tune them to an alert that fires fifty times a day. Teaches people to ignore alerts alert on patterns like five failures in an hour, not on every single read run. The last layer lives inside the flow because good monitoring can't fix a flow that handles errors badly. Most makers build the happy path and stop. Every action runs in order, and if one breaks, the whole flow fails at that step with no cleanup and no message. Better design uses scopes a scope group several actions into one block, like a try section. Then you add a second scope that runs only when the first one fails. That's the run. After setting, you tell an action to run after another action, succeeds or fails times out or gets skipped. So a catch scope can send a useful message, log the error details and close out cleanly. Retries help with the temporary stuff. Every action has a retry policy, and by default it tries a few times with growing delays for a flaky connection. That's often enough for a permanent error, like a deleted file. Retrying just wastes time. So set the policy to match the failure you expect. Put it together and a flow tells you what went wrong, where and with which record. Not just that something did. And here's the moment. This breaks. Nobody turned on export. Nobody routed the alert and a flow stops doing its job on a Tuesday. The first sign is a customer asking where their confirmation went three weeks later. Monitoring tells you how flows behave. It doesn't tell you what they cost. And that bill arrives on a schedule nobody planned for. Licensing surprises the model under the model. Every platform has a technical model environments, policies, connections, solutions, and under that sits a second one, a commercial model. It decides what each flow is allowed to do and what it costs when it does it. Most teams never read that second model until it reads them. Start with what's included. Power automate comes inside Microsoft three hundred sixty five, and that's the reason it spreads so fast. Makers get what are called ceded rights. They can build flows that work with the standard connectors SharePoint outlook teams, OneDrive forms, flows that support Microsoft three hundred sixty five work triggered from Microsoft three hundred sixty five events cost nothing extra. That's a fair deal. It's also where the confusion begins because the premium connectors aren't included SQL server, HTTP, Dataverse, Salesforce, and many others carry a premium label. The moment a flow uses even one, the people involved need a paid license, not the whole company, the flows users, or the flow itself depending on how you buy. And the label isn't something a maker sees while building. The editor shows a small diamond icon next to the premium connector. That's the whole warning. Miss it and the flow works perfectly in testing. Now the paid options. There are three shapes, and each one covers something different per user. Licensing ties the rights to a person. That person can run flows with premium connectors across the environments they work in. It's simple and it gets expensive when a lot of people trigger the same flow per flow licensing, which Microsoft now sells as a flow plan. Ties the rights to a single flow. Anyone can use it because the flow itself is licensed. It fits a team process where fifty people press the same button and process licensing covers unattended work. These are flows that run on a schedule or a trigger with no human in the loop, often built for desktop automation, where a robot runs on a machine. So the question isn't which license is cheapest, it's which one matches how the flow is used. A flow run by five hundred people licensed per user costs five hundred seats. The same flow licensed as one flow costs one. That mismatch is where the real surprises live. Here's the trap. And it's quiet. A maker builds a flow with standard connectors. It runs for months under ceded rights. Then someone edits it. They add an HTTP call or swap a SharePoint step for a SQL query. One action. The flow now requires a premium license that nobody bought. Nothing announces this. The edit saves the flow, keeps running. Then enforcement arrives. Microsoft has been tightening the checks on these rules for years. When a flow that needs a premium license runs without one, the platform can eventually stop it. The flow gets turned off, or it fails at the next run with a message about licensing, and it fails at the worst possible time because enforcement doesn't care that the flow feeds the month end close. So a business process breaks and the cause. Isn't a bug, an outage, or a bad policy. It's an invoice nobody saw coming. There's a second cost that shows up on the finance side, someone discovers fifty flows need licenses, and the bill for fixing that is large, urgent and unbudgeted. The team can pay it or switch the flows off. Neither is a good mandate. That's why licensing can't live as a purchasing detail. It's baked into design. Each connector choice, each trigger, each decision about who can run a flow either adds a cost or avoids one. A maker picking an action in the editor is, without knowing it, placing an order. So this belongs in the governance model next to the policies and the environments, not after them. But knowing the three license shapes only tells you the rules. The harder part is applying them to the flows you have before they ship licensing and practice avoiding the bill. Shock. So how do you stop the surprise? You move the check earlier. Not at purchase, not at enforcement. At the moment. A flow is about to leave development. Make license mapping a gate in the pipeline before a solution goes to production. Someone answers three questions which connectors does it use? Who triggers it and is it attended or unattended? Those answers point to a license. Shape a flow with a premium connector and a few hundred triggering users gets a flow plan. A flow run by two people gets per user seats. A scheduled job with no human involved gets process licensing right. That mapping into the ownership register we built earlier. One more column license basis. Now every business critical flow carries its own answer and an audit becomes a lookup instead of a hunt, the platform gives you some help. The admin center shows licensed usage by flow and by user, and it flags flows that need premium rights without having them run that report on a schedule. Don't wait for the failure to run it for you, but the license is only half the allowance. Every license also comes with request limits. These are daily caps on API calls, and they depend on the license type. A seated Microsoft three hundred sixty five user gets a modest number. A premium per user license gets far more. A flow plan carries its own pool. Go over the cap and the platform doesn't stop the flow. It throttles it, which loops back to the quiet failure we covered a moment ago. The flow slows down, runs, queue up. A job that took ten minutes, now takes ten hours and every run still shows success. This is where design and cost meet a flow that loops through ten thousand rows and makes three calls per row, burns thirty thousand requests in one run. Run that nightly, and you've spent a month of someone's allowance in a day. So you review high volume flows for batching, filtering at the source, and fewer calls per record. That's a design review, and it's cheaper than a license upgrade. Then there's storage, which almost nobody budgets flows that use Dataverse, write to it, run history process logs, audit records, and the data itself all count against your tenant's capacity. Capacity comes from your licenses, and it isn't unlimited. A busy environment can grow by gigabytes in a quarter, mostly from logs nobody reads. When the tenant goes over its entitlement, the options get unpleasant. Buy more capacity, which is priced well above ordinary storage or clean up under pressure with no plan. So set retention rules early. Decide how long each table keeps its logs, archive what the audit team needs and delete the rest on a schedule. Check capacity by environment in the admin center. Because the growth is never even. One environment usually eats most of it. Now the newer part consumption is changing shape. AI builder runs on credits. Each document scan, each text classification. Each prediction spans from a pool. Copilot studio agents run on a similar model with messages and actions counted against a capacity. A single flow that calls an AI step on every incoming email can drain that pool faster than anyone planned, because the cost is hidden inside a step that looks like any other action. None of this is a reason to avoid AI features. It's a reason to treat them like the premium connectors visible in the register, reviewed before production and watched after, which leaves the question underneath all of it. Who decides? In most organizations, nobody does. It assumes the business unit will buy what it needs. The business unit assumes it has it covered. Finance sees the invoice and asks why pick an owner and split the decision cleanly. The platform team owns the rules. Which license shapes exist? How mapping works. What the gate checks. The business unit owns the spend for its own flows because it gets the value. Finance sees a monthly report so no bill arrives as news. Do that and licensing becomes a number you forecast. But even with every control in place, one thing remains the flows that were running before any of it existed. 00:56:59 Speaker: But often flows what they are and how they appear. Take the word orphaned literally for a second. A flow with no parent. Nobody who built it. Nobody who answers for it. Nobody who'd notice if it changed. But that definition hides three different situations and they need different handling. The first is the owner who's gone. The person left the company, the account was removed. Depending on how the flow was shared, it might still run under a co-owner or under a connection that hasn't expired yet. So the flow lives on without anyone behind it. The second is the owner who's disabled. The account exists, but nobody signs in. Maybe they're on long leave. Maybe the account was blocked after an incident and never revisited. The name is still on the flow, so a quick check says it has an owner, but it doesn't. Not in any way that matters. And the third is the owner who was never real. A test account, a shared mailbox. Someone used to build in a hurry, a service account created for a project and then forgotten the flow points at an identity that no human actually watches. So an orphan isn't only a missing name, it's a flow where the name on it can't be reached. How do they appear? Not through any single mistake, through ordinary events that nobody connects to. Automation. Departures are the obvious one. HR closes a ticket. It disables an account. The onboarding checklist covers mailboxes, laptops, and badges, but flows aren't on the list because nobody knew to look for them. Reorganizations are quieter and they produce more. A team merges, a manager changes, a department gets absorbed. The people stay, but the ownership map doesn't update. Flows built for the old team now serve a team that doesn't know they exist. Then there's the accident. A test flow gets built to try an idea. It works well enough that someone points a real process at it, and nobody renames it, moves it, or writes it down. It started as a draft and it became production by use. Nobody promoted it, so nobody owns it. Now, the part that surprises people. Orphans don't go quiet. A flow doesn't know its owner left the schedule keeps firing. The trigger keeps listening. If the stored connection still works, every run succeeds and the flow goes on. Reading records, sending emails and writing files. Some of that data is sensitive. All of it is happening with no one accountable. And when the connection finally does fail, you get the other outcome. The flow breaks. The process behind it stops the first person to feel it has no idea who to call, so both versions cost you. One is invisible activity. The other is invisible. Outage detection starts with a comparison. Take your flow inventory. The list we built earlier and match every owner against entry ID is the account present? Is it enabled? When did it last sign in? A flow whose owner is missing from the directory is a clear orphan. One whose owner is disabled is almost certainly one, and a flow whose owner hasn't signed in for ninety days deserves a closer look. Run that check on a schedule not once new orphans appear every time someone leaves. And the list is only true on the day you pull it. Add a second pass for the identities that were never people. Look for owners that match service account patterns, shared mailboxes and accounts with no manager recorded in the directory. Those won't show as disabled, which is exactly why they slipped through. Once you have the list, you know what's unowned. That's progress. But unowned and dangerous aren't the same thing. Some flows on that list are harmless, others are active. They touch real data and they're doing something nobody approved. Risky flows detection and triage and orphan is defined by who's missing. A risky flow is defined by what it does. And a flow can be both. It can also be risky with a perfectly healthy owner, someone at their desk answering email with no idea what their own automation is doing. So the search changes. Instead of asking who owns it, you ask what it's built to do. Certain patterns show up again and again. The first is external sharing a flow that takes a file from SharePoint and creates an anonymous link, or one that sends records to an address outside your domain. Sometimes that's a vendor and it's approved. Sometimes it's a maker who just wanted a copy somewhere easier to reach. The second is personal email forwarding, a flow that reads a shared mailbox and pushes every message to a private gmail account. It's usually built for convenience, so someone can read work mail on their phone. The effect is that customer data now sits in a mailbox you don't control, can't search, and can't wipe. Third, HTTP calls to endpoints. Nobody recognizes the HTTP action is powerful and it's also an open door. A flow can post data to any web address. If that address isn't a system your company knows about, you can't say where the data goes, who runs it, or what they do with it. Then there's the broader category flows that move data from a business service to a consumer one. Dropbox. personal OneDrive, a free note taking app. The DLP policy should block many of these combinations, but policies have gaps, and custom connectors have a way of working around them. Credentials add another layer. Look for flows running under elevated accounts, an admin identity used for convenience, or a shared account whose password half the team knows. Those flows carry more authority than their job needs. If one gets edited by the wrong person, the damage scales with the access behind it. Now, finding these patterns takes more than one source. Your inventory gives you the flow definitions, which connectors, which actions, which endpoints. Pass them a flow that contains an HTTP action pointing at a domain outside an approved list gets flagged. A flow with a forward to external step gets flagged. Do that across every environment on a schedule. The audit logs add the behaviour they show who shared a flow, who created connections and when flows were turned on. After months of sitting off, a sudden burst of sharing is worth a look. And defender for cloud apps adds what the other two can't. The view from outside it sees traffic leaving your tenant, which cloud services receive it, and which accounts are involved when it shows unusual uploads to an unsanctioned service. You can trace them back to the flow that's sending them together. Those three give you a long list too long usually, so you need a way to decide what to look at first. Triage works on three questions. How sensitive is the data? A slow moving lunch orders isn't the same as one moving employee records match the connectors and sources to your classification, and sensitivity rises or falls fast. How large is the blast radius? One flow affecting one person is a small problem. A flow that touches a whole department's mailbox or runs against thousands of records a day is a large one. Volume matters here, and so does reach. And what's the owner's status? A risky flow with an engaged owner can often be fixed with a conversation. A risky flow whose owner is gone, disabled, or unreachable has nobody to talk to. So it moves up the list. Score each flow on those three and the pile sorts itself. Sensitive data wide reach. No reachable owner. That's your first day. Low sensitivity. Narrow reach. Active owner. That's a message in the queue. What you're building is a ranked list, not a verdict. Every flow on it still needs a decision and the decision shouldn't be improvised under pressure. Remediation. Playbook. Reassign. Fix. Retire. Every flow on that ranked list ends in one of three outcomes. Reassign it, fix it, or retire it. That's the whole tree. The skill is in choosing the right branch for each flow and doing it the same way every time. So the decision doesn't depend on who happens to be on shift. Start with one question does anyone still need this flow? Ask the people closest to it the department. The data belongs to the team that receives the output. The last known co-owner. If the answer is yes, the flow stays and you move to the next question. Is it built in a way you can support a flow that's needed and already sits in a solution with a clean connection? Setup only needs a new owner. That's the easy branch. Pick the person, update the ownership register, rebind the connection to a service identity and add a backup. Ten minutes of work and the flow is no longer an orphan, but a flow that's needed and built loose is a different job. It's a personal account connection. Living outside a solution in an environment it shouldn't be in. Reassigning the name changes nothing about how fragile it is. So you repackage it, move it into a solution. Swap the connection for a reference, pull the hard coded values into environment variables and push it through the pipeline into the right home. That's the fixed branch. It takes real effort and it's worth it for anything in tier two or three. Then the third branch, nobody needs it. Nobody claims it, or it does something that shouldn't happen at all. That one gets retired. Now, how you retire matters more than the decision itself, because the fastest way to turn a governance program into an enemy is to switch off a flow someone quietly depended on. So contact people first, email the last known owner, their manager, and the team named in the flows description. Say what you found, what you planned to do and the date. Give them a grace period and make it real. Usually two to four weeks depending on the risk. For a flow that's actively leaking data, the window shrinks to days, or you act first and explain right after. That's a judgment call, and it should be written down in advance, not invented at the moment when the date arrives. Turn the flow off. Don't delete it. The reasons are practical. An off flow can be turned back on in seconds. A deleted flow has to be recovered, and recovery has limits because deleted flows are kept for a short window and then they're gone for good. If it turns out the month end report needed that flow. You want a button, not a rebuild from memory. So the sequence runs like this. Notify wait. Turn off, wait again long enough to cover a full business cycle, a month end, a quarter end, whatever rhythm the company has. If nobody complains, export the flow and its definition to an archive, then deleted. That archive is the safety net, and it costs almost nothing to keep. The last piece is the record. Every decision gets written down the flows. Name the environment, the old owner, the finding, the branch you chose, who approved it, and the date one row in a table is enough. As long as it's accurate. It sounds like paperwork. It's the opposite. When an auditor asks why a flow vanished in March, you don't reconstruct it from email threads and fading memory. You read a line and the record protects the next cleanup. Without one, every review starts from zero and the same flows get rediscovered. Re-argued and re decided by whoever has time that quarter. But a playbook like this only works on the pile you already have. It does nothing about the flows that will become orphans next month and the month after that. For that, you need a process that runs on its own lifecycle governance, making clean up continuous. A clean up is an event. It has a start date, a finish date, and a slide deck. And the day after it ends, the count starts rising again. That's the flow in treating orphans as a project. People keep leaving. Teams keep merging and test flows. Keep going. Live by accident. The pile refills at the rate your company changes. So the fix can't be a bigger broom. It has to be a process that runs on its own, wired into the events that create orphans in the first place. Those events have names joiner. Mover, leaver. Start with the leaver because that's where most orphans are born. When HR closes out a departure, the Offboarding checklist already covers the mailbox, the laptop, the badge. Add one line flows a trigger, fires when the account is disabled, and a process pulls every flow, connection, and app that person owns. Each one lands in a queue with a short deadline. The manager gets a message that says, here's what your departing employee built. Pick a new owner or approve retirement. That single line changes the math. Ownership moves while the person is still reachable. Not eight months later, when nobody remembers who to ask. Movers are quieter and they matter just as much. Someone changes Departments and their old flows now serve a team they've left. The same trigger applies. A role change in the directory starts a review. Do these flows still belong with you or do they go back to the team they serve? Join us. Get the other half. A new maker shows up through the onboarding path we covered earlier and ownership starts clean. A name goes in the register from the first day along with a backup. Now add a second mechanism for everything. The events miss attestation on a fixed rhythm quarterly for tier three, twice a year for tier two, every owner gets a short list of their flows and a plain question does this still matter and is it still yours? Three answers are allowed. Yes. Keep it, reassign it, retire it. Silence counts two and silence has a consequence. No response. After two reminders and the flow goes to the owner's manager. No response after that. And it's switched off with the same grace and archive rules from the playbook. That last step is what makes the process real. Attestation without a consequence is a survey, and people stop answering surveys, then automate the stale ones, pull the run history or your exported telemetry, and look for flows that haven't fired in a set number of days. Ninety is a common line. A flow that hasn't run in a quarter is either dead or waiting on a rare event, and the owner can tell you which flag it, ask and set an expiry date. If nobody extends it, it turns off and moves to the archive path. Think of it as a lease. Every flow in a lower tier gets a term, and renewal takes one click from a person who's still paying attention. Here's what ties all of it together. Each of these signals comes from a system that already knows the truth. HR knows who left the directory, knows who moved the telemetry, knows what, stopped running. Governance doesn't need to discover those facts on a yearly hunt. It needs to listen for them as they happen. That's the shift. The annual cleanup asks what went wrong this year. The lifecycle asks what changed today and who needs to act on it. One catch remains triggers, cues, attestations and expiry rules all need people to run them and to answer when they fire. Someone has to own that process and decide who can overrule it. Roles in the operating model. Every control we've built so far has the same hidden dependency. A person, someone approves the exception. Someone answers the attestation that went unread. Someone decides whether the policy changes on Thursday or next quarter. And in most organizations, nobody was ever asked to do any of it. So the first question isn't which tool? It's who owns what. Start with four groups the platform team, security, business owners and makers. Each one holds a different piece. The model breaks when two groups think they hold the same piece, or when everyone assumes someone else does. The platform team owns the machine environments, the pipeline, the monitoring, the inventory, the license rules. They build the paved road and keep it open. They don't own the flows themselves. That distinction matters because a platform team that quietly becomes the owner of every flow will drown within a year. Security owns the boundaries, the DLP baseline, the risk patterns, the triage criteria, and the call on which connectors cross, which lines they set, the limits. They review the exceptions that push against them, but they don't operate the platform day to day. So their rules have to be something the platform team can actually enforce. Business owners own. The outcome this is the person whose department depends on the flow. They carry the ownership register entry. They pay for the license. They answer the attestation. When a flow processes their customer data, the accountability sits with them, even if they've never opened. The editor and make us own the build. They create, they test. They fix what breaks. They follow the road that's been laid for them. Notice what's missing from that list. A single owner for everything. That's the point. Now, how do you hold this together? Microsoft's answer is the center of excellence. Most teams hear that name and think of the starter kit, the templates, the dashboards. They install it and call it done. But the kit is a tool. The center of excellence is a function. It's a small group of people, sometimes three, sometimes ten with a written purpose. Run the platform, support the makers, keep the estate visible. It has a backlog, a meeting rhythm, a named lead. The kit helps it see the function, decides what to do about what it sees. If you have the dashboards and no function, you have a very nice view of a problem nobody's working on. That function gets stronger when it has allies, and the best ones are already in your tenant, the makers themselves. A maker community works because makers listen to makers faster than they listen to policy. A champion in finance who shows a colleague how to move a flow into a solution, does more than one hundred emails from it. So give them a channel, a monthly session, early access to changes and a real voice in the rules. Treat them as a governance asset because they carry the standards to places the platform team never reaches. Still, no model survives its first disagreement. A maker needs a connector that's blocked. A business unit wants to skip the test stage for a deadline. A department asked for its own environment, so write down the escalation path before the argument starts. First, the platform team decides what falls inside the standard. Anything outside it goes to a small review group, usually the platform lead. A security representative and the business owner involved. They decide. They record the reason they set an end date because an exception without an expiry quietly becomes the new rule. Decision rights matter here more than meetings do. Who can approve a connector exception? Who can create an environment? Who can override a deployment gate in an emergency? If those answers live in someone's head? They'll change when that person leaves. And there's one more test for the whole model. Does it speed people up governance that only blocks gets routed around make us go back to the places you can't see. Your inventory shrinks while the real estate grows, so measure the time it takes to get a new environment, an approved connector, a deployment into production when the governed path is also the fastest path, make us choose it without being told that speed with guardrails. But all of this costs money, headcount, and attention, and somebody above you has to agree to pay for it. Executive framing risk, cost and value. Here's the first mistake most platform teams make in that room. They talk about connectors, policies, and environments. The executive across the table. Here's a list of technical chores with no price tag and no deadline. Executives don't track governance. They track exposure, spend, and speed. So the job is translation. Every control you've built has to land as an outcome they already measure. Start with a small set of numbers. Four is enough. Each one comes straight from the inventory. You've been building percent of flows with a named active owner. This is the orphan rate flipped into a positive if it was sixty percent last quarter and it's eighty five now, that's a story anyone can follow. Percent of business critical flows inside managed solutions. This tells them how much of the estate can be moved, rebuilt and recovered. It's a resilience number, even though nobody calls it that incident count split by cause. Not just how many flows broke, but how many broke because of an expired connection, a license gap, or a policy change? Nobody announced that split shows whether the incidents are shrinking or just changing shape and license waste flows running on the wrong license basis, seats assigned to people who never trigger anything. Capacity eaten by logs nobody reads. That's the one finance will lean in for. Put those four on one page, Trent. Them direction matters more than any single reading. Now the harder part making the case for what happens if you don't be concrete. Keep it to things that have already happened somewhere. An audit finding that says a regulated process ran through a personal account with no review, customer records sitting in a private mailbox because a forwarding flow outlived its owner. An invoice for premium licensing that arrives as a surprise with a deadline attached. You don't need to scare anyone. You need to show that each of those costs lands on a specific budget, and that the controls you're proposing are cheaper than any one of them. A single data exposure review can eat more hours than a platform team uses in a year. There's a quieter cost, too, and it's worth saying out loud fear when leadership can't tell what's running. The safe move is to restrict everything, block the connectors, freeze new makers say no to the next request. Poor visibility doesn't just create risk, it creates a slower company. That's where the funding argument turns around. A platform team isn't overhead on top of automation. It's the thing that determines how much automation the company can safely carry. Without it, you hit a ceiling set by whatever your risk appetite is on the worst day. With it, the ceiling moves up because every new flow lands in a place you can see support and shut off from the ask. That way you're not requesting a team to say no. You're requesting capacity to say yes at scale, with a known cost per flow and a known response when one goes wrong and give them a way to check your work. Offer a ninety day review. Same for numbers. Same page, same direction of travel. If they haven't moved, change the plan. If they have, the budget conversation gets a lot shorter. One last point on delivery. Don't walk in with the full architecture executives. Remember one sentence, so make it the one that matters. We can't name what's running in our own tenant, and in ninety days we'll be able to. That's a promise you can measure. Which leaves the matter of order. Because even a funded program fails when it tries to start everywhere at once. 01:15:02 Speaker: The maturity path. Where to start on Monday. Start with the order because the order is the plan. Phase one is inventory and ownership before any policy, before any new environment, before a single connector gets blocked, you pull every flow from every environment through the admin APIs, match each owner against entry ID and write the first version of the ownership register. It will be ugly gaps everywhere. Names that don't resolve flows. Nobody can explain. That's the point. You can't set rules for an estate you haven't counted, and this phase pays for itself fast. Within a few weeks, you can name your orphans, flag the obvious risky patterns, and walk into that executive room with a real number instead of a worry. Phase two is the environment strategy and a DLP baseline. Now that you can see what exists, you decide where it should live. Lock the default environment down to its sandbox role. Build the minimum set personal development test production, turn on environment routing so new makers land somewhere safe on their own. Then write the first DLP baseline, starting from the business scenarios you actually found in phase one, not from the connector list. Roll it out the careful way. Impact analysis first communication. Second. Enforcement. last. Nobody should learn about a policy by watching their flow fail. Phase three is solutions, pipelines and connection standards. This is where the engineering lands and it's the slowest phase. Take the business critical flows from your register and move them into solutions one by one. Swap personal connections for service identities. Pull hard coded values into environment variables, stand up the pipeline, and separate the people who build from the people who deploy. Don't try to migrate everything. Start with tier three, the flows where a failure costs real money and let tier two follow as capacity allows. Phase four is monitoring, licensing, control and lifecycle automation. Turn on telemetry export route alerts to people who can act. Add the license gate to the pipeline. So mapping happens before production, not after enforcement. And why are the lever, mover and attestation triggers into the systems that already know the truth? By this point, the process runs on events instead of heroics. That's what separates a program from a project. Notice the dependency chain. Each phase feeds the next inventory tells you where policy matters. Policy gives the pipeline a clean place to deploy. The pipeline gives monitoring something stable to watch, skip a phase, and the later ones rest on guesses. Now for the harder advice. What to resist? Resist fixing everything in the first quarter. The temptation is real because the inventory will show you hundreds of problems at once, and each one looks urgent. But a team that tries to remediate every flow, redesign every environment, and rewrite every policy in ninety days produces one reliable outcome. Burnout, broken processes and makers who stop trusting you. Pick the top slice of your ranked list. The sensitive wide reach no owner flows. Fix those and let the rest wait for their turn. Resist the big announcement to a launch email with a forty page standard teaches nobody anything. Rollout controls in small steps with a named contact, a short explanation and a date make us adapt to a change they understand and resist building the perfect tool. Before you've done the manual version, a spreadsheet with honest data beats a dashboard fed by a flaky sync. Automate what you've already proven by hand. So what does Monday look like? One person, one export every flow in the tenant with its owner and its last run date. Then a second column. Is that owner still here? By the end of the week you have a number. Maybe it's twelve percent, maybe it's thirty. Either way, it's the first true thing anyone has known about the estate and everything after it gets built on that number. That's the whole model in sequence. And it points back to the idea that's been running under every section so far. Conclusion from navigation to context. Go back to where we started a flow running at two a m, touching customer data with an owner who left eight months ago. That flow wasn't a tooling failure. The platform did exactly what it was built to do. The failure was the model around it, the one that waited for an incident before it started caring. That old model treated governance as clean up. Build first, find out later, fix what hurts. It treated flows as a feature that came with the license, as if automation were a setting. You switch on and forget the new model starts somewhere else. A flow is an identity. It has permissions, a home and owner, a cost, and a life that ends on purpose. Once you see it that way, every control in this episode stops looking like a separate chore. Environments decide where it lives. Policies decide what it touches. Connections and the register. Decide who answers for it. Monitoring decides whether anyone notices when it stops, and the life cycle keeps all of that true after the first clean up ends. That's the shift from navigating a mess you already made, to building the context that stops it from forming. And notice what it doesn't require. A giant budget, a perfect tool, a tenant with no history. It requires a number, an owner for that number, and the discipline to do things in order. So if this changed how you think about your own tenant, leave a review. It helps more admins find this episode, and the ones who need it most are usually the ones who don't know to look. Share it with your platform team, especially if you're the person who suspects the count is higher than anyone admits. And if you want to keep going, follow me. Mirko Pieters on LinkedIn. Tell me what to cover next. Licensing deep dives. Copilot. Studio. Governance. A closer look at pipelines. The next episode gets built from what you ask for. Now, one last thing. Right now, while this episode is playing, a flow is running somewhere in your tenant. It's reading a mailbox or moving a file or sending a message to an address you've never seen. Someone built it. Someone approved nothing. And if you asked your team who it belongs to, nobody could give you a name. That's not a hypothetical. It's a count you haven't pulled yet, so pull it.