Tag: Governance

Introduction

There is a scene in A Beautiful Mind that I did not understand at the time. Russell Crowe walks into the facility, looks up at the mezzanine, and sees a figure watching from the shadows. His question is immediate: “Who is Big Brother?”

I was fourteen. I did not know “Big Brother” was shorthand for the government. Moving on.

For years, whenever I heard the word governance, my mind went straight back to that moment, and that one question: “Who is Big Brother?”

Governance. Two syllables, but the root does all the heavy lifting: govern. To direct, to guide, to exercise authority over how a system operates.

Governance is the conversation nobody wants to have. It is also the one that reveals everything.

It exposes where an organization lacks discipline, or it proves how deliberate you are with your data, your environments, your applications, and the people who build them.

Governance is not about slowing innovation down. It is about establishing the guardrails that let you build useful things safely, repeatedly, and at a scale the business can sustain.

Governance in Dataverse

Too many organizations admit they have never had the Dataverse governance conversation. When asked why, the answer is almost always the same: we didn’t have the time. You make the time upfront, or you pay for it later.

Dataverse has governance built into its foundation. Configured correctly, it protects your data like a vault. When a CTO asks me directly if Dataverse is secure, I take it as a sign of leadership: they understand that convenience cannot outrun security.

With AI moving into every workflow, unmanaged data is an active liability. Without boundaries, models expose what should have stayed private. Do not wait for a Day Zero to start governing.

Governance is not one thing

Governance is not a switch you flip. It is not a single toggle, a compliance policy filed in a drawer, or “big brother” in IT approving access requests.

Governance is built on nouns: people, places, and things.

• People: Who build, administer, support, and use the solution.
• Places: Where the work lives: tenants, environments, and data boundaries.
• Things: What is being governed: tables, flows, applications, credentials, and security roles.

If you cannot account for every person, place, and thing inside your architecture, you are not governing. You are guessing.

When you can account for the people, places, and things, governance stops being an abstraction. You can finally ask the questions that matter:

• Who is accountable for the business outcome?
• Where should the solution be built and operated?
• What data is being managed?
• Who can access the data?
• Where is it allowed to go?
• How do we safely change and support the solution over time?

Governance is a framework, not a finish line.

It is the operating model that defines who owns the outcome, where data can travel, and how systems evolve without breaking.

You do not become governed because you bought a platform. You become governed when your organization can answer those questions consistently, long before something goes wrong.

Risk Is the Starting Point

The governance model should scale with the consequence of getting it wrong. I’ve spent time on the other side of policy, building it rather than just living under it. When I started on the Power Platform, none of us knew what we had. My first few solutions were lucky: no sensitive data involved. Not every organization gets that luck and luck is not a governance model.

The solutions solved real problems, but the risk stayed low. If something broke, we could fix it. If it didn’t land, there wasn’t much on the line.

A change management app is not a department app. A department app is not a solution that manages client data, automates financial approvals, connects to an ERP, or becomes part of a process people rely on every day.

Governance should be proportional to risk. The more people, processes, money, customer data, or compliance obligations a solution touches, the more intentional its controls need to be. That intention has to rest on something: a foundation built before the risk arrives, not assembled after it does.

The Governance Foundation

Governance is a framework, and every framework needs a foundation: a north star to return to when things go wrong. That foundation rests on six pillars, and each one is a conversation you can have with your customer.

Pillar	Question it answers	What it looks like in Dataverse and Power Platform
Environment strategy	Where does this work belong?	Purpose-specific environments for development, testing, UAT, production, and lower-risk maker work
Identity and access	Who can do what?	Entra identity, environment roles, Dataverse security roles, teams, ownership, table/row/field permissions
Data classification	How sensitive is the data?	Clear classification, retention, audit, sharing, export, and external-access expectations
Integration and DLP	Where can the data go?	Connector policy, approved connector groups, external-system review, service account/connection approach
Application lifecycle management	How does change reach production?	Solutions, source control, release process, sandbox testing, managed solutions, pipelines
Ownership and operations	Who is accountable after go-live?	Business owner, product owner, technical owner, support path, documentation, monitoring, recovery plan

For years, on the other side of “big brother,” I never really considered these things. I was given a spec sheet and built where I was allowed to build. As I evolved into more of an architect role, these conversations became pivotal to how we designed solutions. This conversation is specific to Dataverse, but the six pillars aren’t. They apply, in some form, to every technology stack.

Environment Strategy

Environments are containers that house our solutions, and they have to be purposeful in how they’re built. Your environment design expresses what kinds of work the organization considers safe, experimental, supported, and production-ready.

Practical Baseline

Environment	Purpose	Who should work there	What belongs there
Personal/maker environment	Learning, prototypes, personal productivity	Individual makers	Low-risk experiments; no business-critical process or sensitive production data
Team or department environment	Shared but lower-risk solutions	Approved makers and team users	Department workflows, internal collaboration apps, limited-scope data
Development	Controlled build environment	Makers and developers	Unmanaged solution development, configuration, unit-level testing
Test/UAT	Validation environment	Testers, product owners, admins	User acceptance testing, integration validation, release verification
Production	Live business operation	End users, administrators, support personnel	Managed solutions, governed data, monitored flows, approved integrations

Best practice treats development, test, and production as separate worlds with separate occupants: makers and developers build, testers and administrators validate, and administrators and end users run what’s live. Each environment should be built with intent, not left to double as production by default.

Production is not a sandbox. It’s where the organization runs the process it has agreed to stand behind.

Security is about the business model

Environments decide where work happens. Security decides who can act once they’re there. A security model has to be functional, not just correct on paper. It should mirror the jobs people actually do, and the responsibility that comes with each one. I’ve seen security built too loose, exposing far more than it should. I’ve seen it built too tight, locking out the very users it was meant to serve. The details are where it lives or dies: does a requester get admin functions? How many rights does an admin actually need?

Project Intake Security Model

Example

Persona	Typical Dataverse access
Requestor	Create requests; read their own submissions and status
Delivery manager	Review, assign, update project/workstream records; manage delivery risks
Finance reviewer	Read and approve commercial/financial components; access restricted financial fields
Executive sponsor	Read portfolio rollups and selected initiatives; approve stage gates
System administrator	Manage platform configuration; not automatically the business owner
External Notion audience	Receive only intentionally published, approved, minimized information, not direct unrestricted access

Security should mirror the business itself. Some roles operate on a need to know basis. Others, further up, carry broader access. The two should never intersect. The controller isn’t the CFO. The CFO isn’t the CEO. Separation of duties isn’t a technicality here, it’s the model.

Security should answer one question: what is this person responsible for? It should never be an accident of who happened to build the app.

Data Classification Drives the Controls

Before you decide what environment a solution belongs in, who should have access, or whether a connector is allowed, there’s a more basic question to answer: what kind of data are we actually working with?

Data classification is how you make that answer explicit. It’s the practice of identifying the sensitivity and business impact of the information a solution creates, stores, reads, changes, or sends somewhere else.

Classification isn’t about making every record feel important. It’s about understanding what happens if that data is exposed, changed incorrectly, lost, kept too long, or connected to the wrong system.

My first few Power Platform solutions were lucky. No sensitive data. No connections to critical systems. They never became business dependencies. But luck isn’t a governance strategy. The moment a solution touches client information, employee data, financial data, personally identifiable information, or anything regulated, the conversation changes. The classification should change the design.

A simple model

Four levels are enough for most organizations to start with.

Classification	Typical data	Governance implication
Public	Approved for anyone to see	Broad access is fine; validate publication and ownership of changes
Internal	Routine business information, not for public distribution	Authenticated internal access; normal ownership, retention, and sharing controls
Confidential	Client, employee, commercial, or business sensitive information	Access tied to role, controlled sharing, audit expectations, careful integration review
Highly confidential	Regulated, financial, legal, credential, or highly sensitive personal data	Need to know access only; minimize use and copies; dedicated review and monitoring

A project name might be internal. A client’s delivery status might be confidential. A commercial estimate, a legal issue, an employee performance record: highly confidential. They can all live inside the same business process without sharing the same access model, integration path, or visibility.

Classification is not DLP

People blur these two constantly.

Data classification tells you how sensitive information is and how it should be handled. DLP, data loss prevention, is one of the controls that enforces part of that handling: specifically, how data moves between connectors and services.

Power Platform sorts connectors into business, non-business, and blocked groups, then controls which ones can be used together. That’s enforcement. Classification is the judgment that comes before it.

Concept	Question it answers
Data classification	How sensitive is this information?
Data ownership	Who decides how it should be used?
Dataverse security	Who can access or change it?
DLP policy	Which services can it move between?
Integration design	What data actually leaves, and why?

This matters even more with Notion

When we talk about surfacing Dataverse data somewhere else, like Notion, the question isn’t “can I connect these two systems.” The question is which fields are appropriate to publish, for what purpose, under whose approval, and what stays authoritative and protected in Dataverse.

A good integration doesn’t copy everything. It publishes the minimum useful information on purpose.

Questions worth asking

• What data does this solution collect, create, update, display, or send elsewhere?
• Which tables and fields hold personal, client, financial, employee, or regulated information?
• Who owns the business definition and handling of that data?
• What is the authoritative source for each important object?
• Who should read, create, update, approve, export, share, or delete it?
• Which systems are allowed to receive it?
• What should stay out of reports, exports, copilots, and external workspaces?
• How long do we keep it, and when does it get archived or deleted?

Data classification isn’t a sticker you put on information after it’s stored. It’s an architectural input. It should shape where the data lives, who can see it, how it moves, and whether it belongs in the solution at all.

DLP and Integrations

Once you know who’s responsible for what, the next question is where the data they touch is allowed to go. A connector is not a technical footnote. It is an exit door for your data.

Connecting Dataverse to another service is an architecture decision: where the data can go, what can move, who authorizes it, how that movement gets watched.

A conversation builders resist

This is the pillar that has annoyed me more than once, and the friction is by design. As a builder, I wanted to build the thing and move on. I knew how to use connectors. That didn’t mean it was the right use for the organization I was working with. Commercial cloud and government cloud don’t treat the same connector the same way. An industry can deny a connector outright. The conversation frustrates builders, sometimes architects too. It’s worth having anyway.

Questions to ask before you connect

• Is the target system approved for this classification of data?
• Is the integration one direction or bidirectional?
• What is the authoritative system for each field?
• Which fields are intentionally published, and which fields must remain in Dataverse?
• Who owns the connection, credentials, and failure response?
• What happens when a record is deleted, a schema changes, or an integration fails?
• Does the DLP policy permit these connectors to be used together in the relevant environment?

The goal isn’t to stop data from leaving Dataverse. It’s to make sure every movement is intentional, appropriate, and accountable.

ALM turns a solution into Product

DLP protects data while it’s moving. ALM protects the solution itself as it moves through environments. If a solution matters, it has to be deployable and supportable without depending on memory or manual changes in production. The moment the business decides a solution matters, it stops being something someone built. It becomes a product.

A product gets everything it needs to succeed: automated deployments, lifecycle management, version control, and a release process the team can repeat without guesswork.

The baseline path

1. Build in a development environment.
2. Package tables, apps, flows, components, and configuration into a solution.
3. Test in a separate test or UAT environment.
4. Deploy approved changes to production.
5. Monitor behavior, document ownership, and manage future releases.

Microsoft treats solutions as the mechanism for moving Power Platform components between environments, and its own environment strategy guidance requires ALM for enterprise development: sandbox preproduction environments, managed solutions in production.

If the only deployment plan is “ask the person who built it to make the change in production,” the solution isn’t ready to be a business dependency. Pipelines, whether DevOps or Power Platform, exist so no one has to move a solution by hand. But once change stops depending on memory, someone still has to own what ships. That’s the last pillar: who’s accountable once the lights are on.

Ownership and Operating model

Governance isn’t governance without the people behind it, call it “big brother” if you like. Watching the solutions and environments matters, but watching alone isn’t enough. Most Power Platform risk is not caused by a table. It is caused by unclear accountability. Every part of the process needs a sponsor, an owner, a champion. Without one, the process fails. Identify these people early, and build a Center of Excellence around them.

For every production Dataverse solution, establish at least these roles:

Role	Accountable for
Business owner	Desired outcome, funding, process decisions, and prioritization
Data owner/steward	Definition, quality, retention, access expectations, and source-of-truth decisions
Product owner	Backlog, user needs, adoption, release priorities, and value realization
Technical owner	Architecture, integrations, ALM, technical health, and engineering standards
Platform administrator	Tenant/environment controls, capacity, policies, access administration, monitoring
Support owner	Incident routing, user support, documented response and escalation path

These roles don’t have to be six different people. A small team might combine several under one name. What matters is that each responsibility has a name attached to it, not a department.

When ownership is clear, incidents get resolved faster and decisions get made without escalation theater. When it isn’t, everyone assumes someone else is watching.

That’s the sixth pillar, and it closes the loop the other five opened. Environment strategy decides where something lives. Identity and access decide who can touch it. Data classification decides how sensitive it is. Integration and DLP decide where it’s allowed to go. Application lifecycle management decides how it changes. Ownership and operations decide who answers for all of it.

Governance Makes Scale Possible

Governance is not what you add after innovation. Governance is what lets innovation become reliable enough to scale.

It gives makers a safe place to experiment. It gives business teams confidence that the processes they depend on are supported. It gives IT a way to protect data without becoming the bottleneck for every idea.

Dataverse gives you the platform capabilities. Governance decides whether those capabilities become trusted business outcomes.

In Part 3, we get practical: what kind of work actually belongs in Dataverse? Because governance doesn’t start once data lands in the platform. It starts earlier, with the architecture decision of whether Dataverse is the right place for that work at all.

I don’t ever remember being excited about the things my parents told me I couldn’t do. It always felt like big brother was infringing on my first amendment rights. “Don’t say this”, “Don’t do that”, “Don’t hang out with them.” As a child I wanted to rebel because I knew best, they were lame, they didn’t have a clue. But there is a scripture that says there is nothing new under the sun and that has never been more true than in the world of Power Platform.

Sure, governance conversations are boring. Sure, the proliferation of AI and low-code tools has made building easier than ever. But easier to build doesn’t mean ready to build. Handing a citizen developer access to every connector in the Power Platform ecosystem without guardrails is like handing a kid a lightsaber and calling them a Jedi. The force may be with them but a Jedi they are not.

The Pattern I Keep Seeing

I have a number of Power Platform engagements during the year and the pattern I see most is building in the default environment and it grinds my gears. To be fair, it’s not the organization’s fault. It’s Microsoft’s and I say that tongue in cheek but with an air of seriousness. Power Platform was designed with the business user in mind and the best way to get users building is to give them somewhere to build. So every user with an M365 license gets access to the default environment straight out of the box. This one is easy to spot unless I run into that one sweetheart customer who says “Duke, we have an environment strategy” and trust me, more on that later.

Here is where it gets interesting. It is not just that every licensed user has access to the default environment. Every user lands there with the Environment Maker security role already assigned. That means they don’t just have read access. They can build. They can create apps, flows, and connections from the moment they are provisioned. No request, no approval, no conversation. They didn’t sneak in through the back door. Microsoft handed them the keys at the front.

What Governance Actually Covers

When most people hear the word governance they tune out. It sounds like paperwork, like red tape, like the IT department trying to slow everyone down. But governance in the context of Power Platform is not about slowing anyone down. It is about making sure the things you build actually work, stay secure, and don’t become someone else’s emergency six months from now.

An environment strategy is an organized approach to defining, classifying, and managing the separate workspaces where solutions move through their lifecycle from development, to testing, to production. As an advisor, one of the topics I frequently cover is risk and without a proper environment strategy you are essentially saying you are happy to assume all of it. I think of an environment strategy like the old Amex commercial. Don’t leave home without one.

In my experience I have seen one too many clients without one and it is problematic for a number of reasons, primarily security. When we skirt security we shuck responsibility. Separation of environments speaks to separation of duties and separation of access controls and that matters more than most organizations realize until it doesn’t.

I have clients who are comfortable letting users test in the dev environment. I am not. When I am in the throes of building a solution I do not want testers in the same space because they are testing a moving target. I may be working on an app and a flow simultaneously and a tester could trigger something that is not ready to be triggered. That creates noise, wastes time, and muddies the environment. Beyond that, working this way means there is no meaningful promotion process. Solutions should move deliberately from dev to UAT to production. That discipline is what keeps untested changes from making it somewhere they should not be.

Beyond environment strategy, governance also covers data loss prevention policies, connector management, security roles, and application lifecycle management. DLP policies are not an IT concern. They are a business concern. They define what data can talk to what systems and what connectors are available to makers. Without them, a well-meaning citizen developer can inadvertently connect a business process to a consumer service and move sensitive data outside the organization without anyone knowing it happened.

The Cost of Doing Nothing

This is the part nobody wants to sit with. Governance feels optional right up until it isn’t. I have seen organizations running automations built by employees who left the company two years ago. The flow is still running. Nobody knows what it touches. Nobody knows what it does. It just runs. That is not a Power Platform problem. That is a governance problem.

When there is no environment strategy, no ALM discipline, and no access controls, what you end up with is an estate you cannot audit, cannot support, and cannot explain to a regulator. You have apps in production that were never tested. You have flows connecting to systems that the business no longer uses. You have connectors touching data that nobody approved. And when something breaks, and it will break, everyone looks at IT and IT looks at a tangle they had no part in creating.

The conversation about governance is uncomfortable. The consequences of not having it are worse. There is a scripture that says there is safety in a multitude of counselors. Governance is that counsel. It is the voice in the room that asks the question nobody wants to ask before something goes wrong instead of after.

The Agentic Era Changes the Stakes

Everything I have described so far applies to the Power Platform as most organizations know it today. Apps, flows, and automations built by makers with varying levels of skill and oversight. The governance conversation is already overdue for most organizations. But there is a new layer coming that makes the urgency significantly higher.

We are moving into the agentic era. Copilot Studio now allows organizations to build AI agents that act autonomously on behalf of users and business processes. These are not apps that wait for someone to click a button. These are agents that reason, decide, and act. They can send emails, update records, trigger workflows, and interact with external systems without a human in the loop.

Think about what that means in an environment with no governance. The Environment Maker problem we talked about earlier gets multiplied. Now it is not just that anyone can build an app. Anyone can deploy an agent. An agent with access to your business data, your customer records, your operational systems. An agent that can take action on your behalf without you knowing it happened until the damage is done.

Agents are not apps. The risk profile is fundamentally different. An ungoverned app can expose data. An ungoverned agent can act on it. That distinction matters and most organizations are not having this conversation yet. Governance was optional for some when we were talking about canvas apps and simple flows. It is not optional when we are talking about autonomous agents operating inside your business processes.

Agent governance means knowing who can build agents, what systems those agents can connect to, what actions they are permitted to take, and how their activity is logged and audited. It means having environment strategy that accounts for agent development and deployment separately from general maker activity. It means DLP policies that have been revisited with AI capabilities in mind. This is not theoretical. It is happening now and the organizations that treat agent governance as an afterthought will feel it.

What Good Looks Like

I promised earlier I would come back to that sweetheart customer who told me they had an environment strategy. That is always a good day. It means the conversation shifts from remediation to optimization. That is where I want every client to be.

Good governance looks like a deliberate environment strategy with dedicated environments for development, UAT, and production. It looks like DLP policies that were designed with the business in mind, not just bolted on after the fact. It looks like ALM discipline where solutions are packaged and promoted through environments properly before they touch live data and live users. It looks like security roles that were assigned intentionally, not inherited by default.

For organizations moving into Copilot Studio and agent development it looks like all of the above plus a clear framework for how agents are built, reviewed, approved, and monitored. The Center of Excellence toolkit that Microsoft provides is a strong starting point. It gives you visibility into what is being built across your tenant, who is building it, and where the risks are concentrated. It is not a silver bullet but it is a foundation.

The goal is not to lock everything down. The goal is to enable makers and agents to do what they do well inside a structure that protects the business. Governance done right does not slow innovation. It makes innovation sustainable.

Have the Conversation Before Something Breaks

I started this article talking about my parents and the rules I didn’t want to follow. Looking back, most of those rules existed because they had seen something I hadn’t. They were trying to keep me from a problem I couldn’t see yet. That is exactly what governance is doing for your Power Platform environment.

The organizations that treat governance as a checkbox exercise will eventually have the conversation they were trying to avoid, except they will have it under pressure, after something has already gone wrong. The organizations that treat it as a business enabler will move faster, build with more confidence, and scale without the chaos.

You don’t have to have it all figured out on day one. But you do have to start the conversation. An environment strategy, even a simple one, is better than none. A DLP policy reviewed annually is better than one that was never created. And if you are already building with Copilot Studio or planning to, start the agent governance conversation now. Not after the first incident.

There is safety in a multitude of counselors. Governance is that counsel. Have the conversation before something breaks.