Category: Power Platform

When people ask what makes Power Platform powerful, they point to the tools. Power Apps for the interface. Power Automate for the workflow. Copilot Studio for the agent. After a couple of years of building with it, I think the answer sits somewhere else.

The power is in what the platform rides on.

Power Platform sits on Azure, Microsoft 365, Entra ID, and Dataverse. Identity is solved. Security is inherited. Your users already live in these tools. So the useful question stops being “what can this tool do?” and becomes “what does the Microsoft cloud already do that I can pull in?”

Here is what that looked like in practice.

A word about connectors

In Power Automate, almost everything is a connector. SharePoint is one. Outlook is one. The HTTP action is one too, so calling an Azure Function is still using a connector.

The difference is what each one gives you. A prebuilt connector wraps a service and hands you actions someone else already built: get a file, send a message, create a row. The HTTP action gives you only a pipe. It carries a request out and a response back, and it does no thinking in between.

That distinction shapes everything below. Connectors move data between systems. They don’t interpret it. When a solution needs something understood, calculated, or reshaped beyond what the actions allow, the logic has to live somewhere else, and the flow reaches it through that pipe. Each section that follows is a different answer to the same question: where should this work live?

When no connector understands the work

I needed to run construction takeoffs from CAD drawings. A drawing arrives as a DXF file, and the questions are practical ones. How much floor? How much wall? How many doors? No connector I know of opens a drawing and reports its geometry.

An Azure Function does. It uses a Python library called ezdxf. The flow sends the file over HTTP, the function reads the drawing and walks every entity, the lines, arcs, polylines, hatches, and text labels, and it returns structured JSON: counts by type, total length, enclosed area, and the room annotations. One hospital floor plan came back with more than fifty thousand entities, summarized in a payload a flow can handle.

Then the flow goes back to what it does well. It stores the result, routes it for review, and notifies the right person.

Two lessons came out of it. Files travel in more shapes than you expect. The content can arrive wrapped in JSON, as raw base64, or as a stringified byte object, and my function had to learn to accept all three. And know what your library can read. ezdxf handles DXF and DWG, not DWF, so a different file format meant a different step before the function ever ran.

When the loop is the problem

Some flows turn into nested loops with actions stacked inside each one. They work, but they run slowly and they are painful to maintain.

I moved that logic into functions. One example compared two lists of tasks, treating one as the source of truth, and returned three things: items to update, items to add, items to remove. The flow’s only job was to apply those results through an HTTP call. The function did the thinking and the flow did the delivering.

It also costs less than people expect, and the setup is modest. Secrets go in Key Vault, and the function reads them through a managed identity. The API key never appears in the flow.

When the work outgrows a flow

Contract analysis is one of my favorite examples. A user uploads a PDF to a record in Dynamics 365. A Logic App watches that table, notices the file, downloads it in chunks, and sends it to an Azure Function for analysis. The function is given thirty minutes, because contracts are not quick reading. The result is cleaned, written back to the record, and the user gets an in app notification.

The Power Platform front end stayed simple. The user uploads a file and receives an answer. Behind it, a Logic App, a Function, and a vector store did the heavy work. Nobody on the business side needed to know.

When the answer lives in Excel

This is the one people overlook, and it fits the definition in an interesting way. Running an Office Script from a flow is itself a connector action, the Run script action in the Excel Online connector. The connector is only the pipe. The script is where the work happens.

In one solution, scripts read the column headers from an uploaded file and from the target import template. An AI prompt mapped one to the other, and a final script wrote the clean CSV. A practical note from that build: return arrays from a script as JSON strings. Power Automate will not surface a native array as usable dynamic content, and you will lose an afternoon finding that out.

In another, a script wrote summary values to fixed cells and built a named table, while the bulk rows went in through the Microsoft Graph API using the HTTP with Entra ID connector. Excel stayed the output, and the platform did the rest.

One caution. Office Scripts can be switched off in a tenant, and mine was at first. Know what your environment allows before you design around it.

What reaching costs

Every piece of this has a price, and I do not mean only the invoice.

Logic Apps Standard needs a storage account. Managed identities need role assignments on every resource they touch. Choose a model in Foundry without understanding its pricing, and you can pay for reasoning tokens to summarize an email. I have seen that mistake multiply a cost by seven. I have also cost an organization 23,000 dollars in a single day through one careless configuration. The lesson was simple. Ask questions before you configure, of your stakeholders and of yourself.

Reaching into the platform is worth it. It just is not free, and it rewards builders who know what they are reaching for.

The shift

A solution built on one tool inherits that tool’s limits. A solution built on a platform inherits the platform’s reach.

Power Platform is the front door. The Microsoft cloud is the building behind it. Good architects learn to use the whole building.

Most security gaps in Dataverse don’t look like gaps. A reviewer opens a list, sees only their rows, and everyone assumes the boundary is real. A view decides what people see. Filtered record ownership decides what they can reach. I built a small compliance lab in a Dataverse sandbox to test that line, and most of it held. One result did not.

Filtered record ownership is in preview. Microsoft can change how it behaves before general availability, and preview features aren’t meant for production. Everything below comes from a sandbox.[1]

The question every maker asks

Dataverse makers already understand views.

We create views to focus people on the records that matter to their work. We filter them by status, region, legal entity, assigned team, or any number of other attributes. We can even control which security roles see particular public views.

So when Microsoft introduces filtered record ownership, still in preview, a reasonable question follows:

Isn’t this just another way to create a filtered view?

No.

A filtered view decides what appears in a saved list. Filtered record ownership decides which records a user is allowed to access in the first place.[1][2]

The familiar approach

Imagine a custom table called Compliance Evidence.

Each record has a Legal Entity field. You create a public view named US Corp Evidence Awaiting Review with these criteria:

• Legal Entity equals US Corp
• Evidence Status equals Submitted

You then make that view visible only to the US Compliance Reviewer security role.

That is useful. It gives US reviewers a relevant list and keeps the application easier to navigate. Microsoft supports managing access to public system views through security roles.[2] Two details trip people up: role-based view access only works after an administrator turns on the environment setting EnableRoleBasedSystemViews, and it only applies to public views that aren’t the table’s default view.[2]

But that configuration answers only this question:

Which saved view should this user see in the application?

It does not answer this question:

Which evidence records is this user allowed to access?

Microsoft explicitly distinguishes view access from data access: being able to use a view does not grant access to the records in it, and the user’s underlying Dataverse privileges still control which rows are returned.[2]

The difference

Capability	View limited by role	Filtered record ownership
Primary purpose	Give a role a relevant saved list	Enforce access row by row, based on record values
Filter means	“Show matching rows in this view”	“Authorize access only to matching rows”
Controls	User experience	Data access
Another view can show other rows	Possibly, if normal privileges allow it	No, not for the same restricted identity
API, SDK, or flow access	Normal table permissions determine results	Filter privileges limit results for the identity making the request
System Administrator	Sees whatever the role’s privileges allow	Sees every row, through a built-in “All records” filter
Record owner	Existing ownership model remains	No user or team owner (on tables with Filtered ownership)
Assignment and record sharing	Available when supported by ownership model	Not available because rows under filtered ownership have no owner
Status	Generally available	Preview

Filtered record ownership uses filters assigned through roles as security predicates. Dataverse evaluates the record’s column values against those privileges when deciding whether to allow actions such as Create, Read, Write, Delete, Append, and Append To.[1]

Record filters aren’t limited to the new ownership type. You can also add them to existing tables owned by a user or team, where they grant access on top of ownership rather than replace it.[4]

One filter, two meanings

The same-looking criteria can do two very different jobs.

In a view:

Legal Entity = US Corp

Means:

“When someone opens this saved list, display US Corp evidence.”

In filtered record ownership:

Legal Entity = US Corp

Means:

“A user with this filter privilege is authorized to access only US Corp evidence.”

The criterion is identical. Its role in the platform is not.

A view filter shapes a query. A filtered ownership rule shapes authorization.[1][2]

A compliance example

Consider this simple model:

• Parent table: Silver Compliance Tracker
• Child table: Compliance Evidence
• Evidence classification fields: Legal Entity, Region, Sensitivity, and Evidence Status

The parent tracker represents the overall audit, certification, or compliance cycle. It can remain a normal table owned by a user or team, because there may be an accountable compliance manager or team.

The child Compliance Evidence table represents individual evidence items. This is where filtered ownership earns its place, because access may need to depend on the evidence item’s classification rather than who owns it.[1]

For example, the US Compliance Reviewer role might receive a record filter:

Legal Entity = US Corp

An EU Compliance Reviewer role might receive a different record filter:

Legal Entity = EU GmbH

Now the US reviewer may see the overall tracker but only the evidence items that match the US filter. The EU reviewer sees only EU evidence. That is need to know, enforced by the platform.[1]

What I tested

Documentation tells you what a feature should do. A lab tells you what it does. So I built this model in a Dataverse sandbox and tried every route I could find. The setup:

• The two tables above, with Compliance Evidence created as Filtered ownership
• Two record filters (US Corp and EU GmbH) and two reviewer roles, each granted its own filter
• Six evidence rows: three US Corp, two EU GmbH, and one Canada Ltd row that no reviewer filter covers
• The same data surfaced through a model-driven app, the Web API, a Power Automate flow, a code app, and a Copilot Studio agent
• One test user without admin rights, switched between the two roles

The clearest result is the second row of the table below. The Evidence Submitted view has no Legal Entity filter at all, yet each reviewer still saw only their own entity’s rows. The record filter did that, not the view.

Route	US reviewer	EU reviewer	System Administrator
View: All Compliance Evidence	3 rows	2 rows	6 rows
View: Evidence Submitted (no Legal Entity filter)	2 rows	1 row	4 rows
View: US Corp Evidence Awaiting Review	In the list, 2 rows	Not in the list; 0 rows when opened through Manage and share views	2 rows
Other entity’s record by direct link or Web API	Not returned	Not returned	Returned
Web API list	3 rows, all US Corp	2 rows, all EU GmbH	6 rows
Power Automate flow (run as the user)	3 rows	2 rows	6 rows
Code app	Own rows only	Own rows only	Not tested
Copilot Studio agent (Authenticate with Microsoft)	Own rows only	Own rows only	Not tested
Create a record for the other entity	Blocked	Blocked	n/a
Change own record’s Legal Entity to the other entity	Allowed	Allowed	n/a

The last row is the one that matters most. I come back to it below.

The administrator column is a warning, not a feature. Dataverse automatically gives the System Administrator role a built-in “All records” filter on every filtered table, so an admin always sees everything. If you test with an admin account, you prove nothing.[1]

The agent result is what I observed in one test, not documented behaviour. Treat it as something to verify in your own environment.

The security layer

So what is it, then? A security control at the data layer, for reading and creating records.

A user cannot get around the filter simply by selecting a different view. Whether the user reaches Dataverse through a model-driven app, a code app, the Web API, or a flow that runs as that user, Dataverse evaluates the same filter privilege.[1] In my tests, every one of those routes returned the same rows for the same role.

When a client asks, I put it this way:

A view controls the screen. Filtered ownership controls the record.

Or:

Views organize data; filtered ownership authorizes data.

An important qualification

Dataverse always evaluates the permissions of the identity making the request. That sounds obvious until you meet a cloud flow.

A flow does not run as the person who presses the button by default. It runs with the connections saved in the flow, which are usually the maker’s. In my lab, the Evidence Read Test flow returned all six rows to every user until I opened the flow’s Run only users panel and set the Dataverse connection to Provided by run-only user. Only then did it return three rows for the US reviewer and two for the EU reviewer.[3]

Two details matter:

• The connection’s account needs a privilege. For Dataverse in the same environment, “provided by run-only user” makes Dataverse act on behalf of whoever runs the flow. The account behind the flow’s Dataverse connection must hold Act on behalf of another user (or the Delegate role). When I pointed the flow at a connection for a regular user, saving failed with a missing prvActOnBehalfOfAnotherUser error.[3]
• Data that leaves Dataverse leaves the filter behind. A flow co-owner can open the run history of someone else’s run and read everything that run returned. In my lab, that meant all six evidence names, including rows the co-owner’s own role could never read. The filter protects rows in Dataverse. It does not protect copies of them in run history, exports, emails, or logs.

A flow or integration running under a service account, application user, or service principal is the same case: a separate security principal with its own permissions. That does not bypass security, but it can return more than an individual reviewer could see.[5][1]

So the honest version is:

Filtered ownership applies consistently everywhere Dataverse evaluates the same identity’s permissions. Check which identity each route actually uses.

One flow, two answers. As the administrator, it returns 8 records. As the EU reviewer, it returns 3. The flow didn’t change. The identity did.

A gatekeeper on create, not on edits

The filter is not auto-fill

Filtered ownership does not automatically populate fields.

Suppose a US reviewer can create only records where:

Legal Entity = US Corp

The application still needs to set the Legal Entity field, through a form default, Power Fx, automation, a plug-in, or another controlled process. The filter acts as a gatekeeper: it allows the new record only if its value satisfies the user’s Create filter.[1] In my tests that held. Each reviewer could create a record for their own entity, and an attempt to create one for the other entity was refused.

The filter is a gatekeeper, not an auto-fill rule.

When it fits

Filtered ownership is useful when access should follow a trustworthy record attribute:

• Legal entity
• Geographic region
• Data classification
• Customer segment
• Business division
• Control area
• Regulatory scope

This makes it useful for need-to-know scenarios, provided those classification fields are required, accurately maintained, and governed. The security rule is only as reliable as the data used to evaluate it, and, as the edit test shows, only as reliable as the controls on who can change that data.[1]

When teams still fit better

Filtered ownership is not a replacement for tables owned by a user or team.

Use a traditional design built on ownership when you need:

• A clear individual or team accountable for each record
• Assignment and reassignment
• Record sharing
• Ownership-based processes and reporting
• A regional or functional team that truly manages the work

Use filtered ownership when the central access question is:

“Does this record’s classification authorize this person to access it?”

Use team ownership when the central question is:

“Which person or team is responsible for this work?”

The two aren’t mutually exclusive. A table owned by a team can also carry record filters that grant extra access, based on record values, on top of ownership.[4]

Choose the pattern that matches how the work runs, not the one that shipped most recently.[1]

Where the boundary lives

Filtered record ownership is not a new way to make filtered views.

It is a different security model for custom tables, one where a record’s values, rather than a user or team owner, determine who can access it.

A view limited by role may still be valuable. It gives each user an appropriate experience and reduces navigation clutter. But it does not establish the data boundary.

Filtered record ownership is still in preview, and that matters more than it sounds. A table’s ownership type can’t be changed once it’s created, so a table you build on it today is a commitment to a feature that isn’t finished. The edit behaviour above is exactly the kind of detail that may change before general availability. Approach it as a sandbox exercise and a pattern to evaluate, not yet a production security foundation.[1]

The view says, “Start here.” The filtered ownership rule says, “Only these records.” Your own controls on the classifying field say, “And they stay that way.”

Sources

1. Filtered record ownership (preview) – Power Apps
2. Manage access to public system views – Power Apps
3. Manage connections for the Microsoft Dataverse connector – Power Automate
4. Filter-based security in Microsoft Dataverse (preview) – Power Platform
5. Security roles and privileges for Dataverse – Power Platform

Introduction

One of the fastest ways to build a bad platform strategy is to turn a platform you like into the answer for every problem.

That is usually where good intentions begin creating long term complexity.

The purist answer is, “We can build it.” The practitioner’s answer is more useful: let products do what they are already good at, and be intentional about what you add around them.

That matters even more now. AI is changing how people interact with business systems, and Power Platform can connect to APIs, events, data sources, and existing applications. In that world, rebuilding a product’s core capability is rarely as inventive as it sounds. More often, it means recreating something the organization already owns, then accepting the responsibility to maintain it forever.

For example, I do not need to build a full project management product in Dataverse just because I want better delivery governance. The project management platform can continue to own schedules, tasks, assignments, and dependencies. Dataverse can own the governed operational work around it: engagement health, delivery risks, decisions, approvals, exceptions, portfolio reporting, and the automations that connect delivery activity to leadership and other systems.

Dataverse does not need to be everything.

It needs to be the right thing: the governed operational layer for work that requires structure, ownership, security, workflow, automation, and reuse across the organization.

That is the real decision in front of us.

Not, “Can Dataverse store this?”

It usually can.

The better question is, “Does this work need the kind of governed, connected, actionable operational data platform that Dataverse provides?”

Some work needs a place to be discussed. Some work needs a place to be documented. Some work needs a place to be analyzed.

But some work needs to be owned.

It needs structure. It needs a lifecycle. It needs accountability. It needs to move through a process, trigger action, respect security boundaries, and remain available to the next application, flow, report, integration, or person that depends on it.

That is the kind of work that belongs in Dataverse.

Look for the Signals

There will be signs.

Including Dataverse in a solution architecture should be an intentional decision, not a reflex. Certain signals tell us when work has outgrown a simple list, spreadsheet, or lightweight collaboration tool.

And, to be clear, these signals are not exclusive to Dataverse.

Meaningful relationships. A defined lifecycle. Different levels of access. Automation. Auditability. Reuse across applications and systems. Data that drives action or decisions.

Those signals do not automatically mean, “Use Dataverse.”

They mean the work deserves an intentional operational architecture.

Dataverse may be that architecture. Another product may already own the domain. Or Dataverse may become the governed layer around the system that remains authoritative.

The question is not whether Dataverse can store the data. The question is what should own the work, and what role Dataverse should play around it.

When several of these conditions appear together, the work is telling you something. It is no longer just information someone wants to keep. It is becoming an operational process: something that coordinates people, carries responsibility, moves through stages, triggers decisions, and needs to remain dependable after the original maker has moved on.

That is when we need to slow down and look carefully at the data, the process, the people involved, and the systems that already own part of the work.

A workstream may be ready for a more intentional operational foundation when several of the following statements are true.

Signal	What it means
Meaningful relationships	Start with the data model. Does the work involve more than a flat list? Are there customers, projects, requests, approvals, tasks, risks, decisions, and documents that need to relate to one another?
A defined lifecycle	Does the record move through recognizable states, handoffs, decisions, exceptions, or approvals that the business needs to understand and trust?
Different responsibilities require different access	Do different people need different levels of control over who can create, view, update, approve, assign, share, delete, or export the information?
The process needs dependable action	Do status changes, thresholds, dates, or decisions need to trigger automation, notify people, update another system, or create the next step in the process?
The organization needs accountability	Does the business need to know who changed something, when it changed, and sometimes why a decision was made?
The same record must be reused	Does the same record need to appear in multiple apps, flows, reports, agent experiences, or integrations without creating competing versions of the truth?
The data drives decisions	Is the information used to approve funding, escalate a delivery issue, manage risk, prioritize work, or run part of the business?

The presence of these signals is not a shortcut to a product decision. It is a prompt to design intentionally.

Sometimes Dataverse should be the foundation. Sometimes the product already built for the domain should remain the system of record. And sometimes the best architecture is a partnership: the authoritative system continues to own the core domain, while Dataverse owns the intake, governance, approvals, exceptions, coordination, reporting, and automation that make the work manageable across the organization.

That is the measure of a healthy architecture: each platform has a clear job, each important record has a clear owner, and the organization can explain why the work lives where it lives.

Work Dataverse Owns Directly

As I mentioned earlier, Dataverse can be the foundation, or it can be an extension.

One example I see often in Dataverse is intake processes. This work may not live anywhere else. It may not belong in an ERP, CRM, IT service-management platform, or another specialized product.

It may be unique to how the organization operates: how it receives an idea, request, opportunity, concern, exception, or assessment; how it decides what matters; who needs to review it; what evidence is required; and what happens next.

That is where Dataverse can become the foundation. It gives the organization a governed place to create the record, assign ownership, move it through a lifecycle, apply its rules, capture decisions, and understand the current state of the work.

Change Requests

Consider an organizational change request.

A team may identify a policy that no longer works, a handoff that creates delay, a control that creates unnecessary friction, a role that is unclear, or a customer-facing process that needs to change.

That is not necessarily an IT service request. It is not automatically a project task. And it may not belong in an ERP, CRM, or another specialist product.

It is a request to change how the organization operates.

The request needs to be understood and assessed. What is changing? Why does it matter? Who is affected? What processes, systems, controls, roles, or teams will be impacted? What risks does the change introduce? Who has the authority to approve it? What needs to happen before the change can take effect?

Dataverse can own that record from submission through impact assessment, review, decision, implementation, and outcome. It gives the organization one governed place to see the proposed change, accountable owner, affected stakeholders, supporting evidence, approval history, actions, and final result.

That is not a shadow ITSM process. It is the organization governing changes to the way it operates.

Work Dataverse Can Own Within a Larger Process

So what does that kind of work look like in practice?

It is usually not a single task, a static document, or a piece of information someone wants to keep nearby.

It is shared operational work. It has records that relate to one another, people with different responsibilities, and a lifecycle the business needs to trust. It includes decisions, actions, exceptions, and outcomes that matter beyond one person or one team.

Dataverse is often a strong fit when that work needs a durable, governed home and does not already belong to a product designed to run the domain.

That distinction matters.

The goal is not to move work into Dataverse because we can. The goal is to put operational work where the organization can secure it, automate it, reuse it, report on it, and maintain it over time.

Invoice Preprocessing

One example I have worked with is invoice preprocessing.

I would not advocate rebuilding accounts payable in Dataverse. The ERP should own the vendor invoice, the financial transaction, the accounting controls, and the eventual payment. That is what ERPs are built to do.

But there may be work that needs to happen before an invoice enters the ERP.

Dataverse is well positioned to handle that work. The invoice may need to be reviewed. Information may need to be validated. An exception may need to be resolved. More than one person may need to examine it, and it may need to move through a series of approvals before finance is ready to accept it.

That is not a replacement for the ERP. It is the governed operational process around it.

If we look back at the signals, this is where they become easier to see:

Signal	How your invoice process demonstrates it
Meaningful relationships	An invoice relates to a supplier, requester, cost center, purchase order or business context, approval requests, approvers, and eventually an ERP record
Lifecycle	Received → reviewed → routed → pending approval → approved or rejected → submitted to ERP → processed or exception
Different permissions	An AP processor, budget owner, approver, finance reviewer, and platform administrator do not need identical access
Dependable automation	The process needs routing, approval notifications, reminders, outcome handling, ERP submission, and error notification
Auditability	Finance needs to understand what was submitted, who approved it, when approval occurred, and why it was rejected or escalated
Data reuse	The invoice may appear in a model-driven app, approval experience, flow, finance report, exception queue, and ERP integration
Operational decisions	A person decides whether the invoice is valid, whether an exception needs attention, and whether funds or payment should be approved

That is the pattern when Dataverse owns the work. The harder discipline is knowing when it should not.

Work That Should Stay Elsewhere

My desire to make Dataverse the backend technology for the system of all systems began with some naivete.

Trust me, it was humbling to learn the limitations of Dataverse. But those limitations are worth noting.

Not because they make Dataverse less valuable, but because they force us to be more deliberate about what it should own and what should stay elsewhere.

Dataverse can store relational data. It can secure records. It can power applications, automation, reporting, integrations, and increasingly AI-enabled experiences.

But it is not a replacement for every system, every workload, or every collaboration pattern. It is not an ERP. It is not a document-management system. It is not an IT service-management platform. It is not a warehouse or lakehouse. It is not the best place for every note, task, file, transaction, or historical record.

The mistake is not using Dataverse. The mistake is treating capability as a reason for ownership. Just because Dataverse can store a record does not mean Dataverse should become the system that owns it.

Core Business Transactions

ERP has its place at the system of record for a reason.

An ERP is not simply a database with forms and approvals layered on top. It is built to run the organization’s core business transactions.

The general ledger. Purchase orders. Vendor invoices. Payments. Inventory movements. Customer orders. Billing. Fixed assets.

These are not just records with fields and statuses. They are transactions governed by accounting rules, financial controls, procurement policy, tax treatment, inventory costing, budget commitments, period close, audit requirements, and years of embedded business logic.

Rebuilding that behavior in Dataverse because Dataverse can model tables, relationships, workflows, and approvals is not innovation. It is taking responsibility for a domain the ERP was built to run.

Dataverse can still create real value around those transactions. It can own intake, preprocessing, exception handling, business-specific review, cross-functional approvals, tailored experiences, and automation. But the ERP should remain authoritative for the transaction itself.

Dataverse can coordinate and extend the work around the transaction. The ERP runs the transaction.

Specialized Operational Domains

The next category is specialized operational work.

Some work is not generic enough to rebuild from tables, forms, and flows without giving up the capabilities that make the specialist product valuable.

A service-management platform is not simply a ticket table. A project-management platform is not simply a task table. A contract-lifecycle-management system is not simply a document plus approval. A field-service platform is not simply appointments, work orders, and assets.

These platforms embody years of domain knowledge: service-level management, queues, change control, configuration relationships, resource scheduling, project dependencies, contract clauses, dispatch, maintenance plans, inspections, and controls specific to each industry.

Dataverse can integrate with these systems. It can create a governed process around them. But it should not become a shadow replacement just because a team wants one more app.

Work that should remain in a specialized platform	Why it belongs there	Appropriate Dataverse role
IT incidents, changes, problems, service requests, CMDB	ITSM platforms manage service levels, ticket lifecycles, change control, configuration items, and operational support	Business-demand intake, governance review, executive reporting, or cross-functional exception process
Detailed project schedules, task execution, resource capacity, dependencies	Project tools optimize planning, execution, scheduling, and resource management	Portfolio decisions, business approvals, governance, risks, and cross-system coordination
Contract authoring, clause management, negotiation, signatures, obligation extraction	CLM products specialize in contract language, workflows, redlining, signing, and legal records	Intake, related initiative or vendor context, downstream operational obligations
Field dispatch, route optimization, maintenance scheduling, technician mobility	Field-service and asset-management products handle work orders, dispatch, service history, inventory, and maintenance	Supplemental inspection, custom governance, exception workflows, and business reporting
Security operations, alerts, investigation, and incident response	Security platforms are designed for telemetry, detection, correlation, response, and evidentiary investigation	Risk or compliance reporting around the security process, where appropriate

Large Scale Analytics and History

Dataverse should not become the organization’s default data lake, warehouse, or analytical archive.

A current operational record may belong in Dataverse. But years of transaction history, telemetry, application logs, clickstream behavior, IoT data, machine data, event streams, and enterprise-wide reporting workloads are different kinds of work.

They need ingestion pipelines, transformation, partitioning, broad historical retention, analytical engines, scalable compute, data science tools, and access patterns built for questions across millions or billions of records.

That is where Fabric, a lakehouse, a data warehouse, Azure Data Explorer, Databricks, or another analytical architecture belongs. Dataverse can remain the place where a user acts on a current operational issue. The analytical platform can be the place where the organization detects the pattern that revealed the issue.

High Scale Digital Products and Event Workloads

Finally, Dataverse is not automatically the backend for a high-scale digital product.

A public consumer application, marketplace, high traffic website, mobile product, telemetry platform, or real time event processing system may need global distribution, high throughput, low latency APIs, custom caching, event streaming, specialized search, independent deployment, and direct control over the application stack.

Those needs may point to Azure SQL, Cosmos DB, PostgreSQL, Redis, Azure Functions, Event Hubs, Service Bus, API Management, or a custom cloud architecture.

Dataverse may still participate. It may hold governed business records, customer-service context, internal operational workflows, or application-administration processes. But it should not be selected simply because it is the Microsoft data platform most familiar to the team.

A Power Pages site can absolutely serve a serious external audience. High traffic alone does not disqualify Dataverse or Power Pages.

The question is what kind of work the site is doing. Power Pages is a strong fit when the website is the front door to a governed business process: a partner request, application, case, inspection, onboarding process, or other Dataverse-owned operational record.

But when the digital product itself becomes the workload – when it depends on extreme transaction volume, real-time interaction, high-frequency events, specialized search, global-scale performance, or deep control over the application stack – a custom cloud architecture may be the better foundation.

Dataverse may still play a role. It may hold governed records, internal administration, exceptions, or human-review workflows. But it does not need to carry every request, event, click, or transaction just because the application is built on Microsoft technology.

Lightweight Work

And then there is work that should stay lightweight.

Not every early idea, personal task, team note, workshop output, or draft document needs lifecycle controls, security roles, relationships, integration, or audit history. Those tools are still valuable. They simply solve a different problem.

Dataverse Can Own, Extend, or Participate

By now, the question should not be, “Should this live in Dataverse?”

The better question is, “What role should Dataverse play in this process?”

There are three useful answers. Dataverse can own the work. It can extend the work. Or it can participate without becoming the system of record.

Dataverse role	What it means	Example
Own	Dataverse is the authoritative operational record from intake through decision, action, outcome, and closure	An organization-specific improvement request, policy exception, solution-readiness review, compliance attestation, or custom inspection
Extend	Another system remains authoritative for its core domain; Dataverse owns a distinct workflow around, before, or across that system	Invoice preprocessing and approvals before ERP payment; ERP exception management; cross-functional approval and review
Participate	Another platform owns the record; Dataverse contributes selected records, workflows, apps, reporting, or integrations without creating a duplicate source of truth	A Power App reads ERP data; Dataverse tracks a related business decision; an integration surfaces approved information elsewhere

The unhealthy answer is duplication.

If the ERP owns the invoice, do not create another competing invoice record in Dataverse. If the project-management product owns the schedule, do not create a shadow schedule in Dataverse. If SharePoint owns the document, do not create a second document repository. If an ITSM platform owns the incident, do not create another ticket queue.

The architecture becomes durable when each platform has a clear job, each critical record has a clear owner, and the organization can explain the boundary in one sentence.

A useful architecture test is this: Can we explain, in one sentence, what each system owns?

If we cannot, we are likely creating duplicate records, conflicting processes, unclear accountability, and a future debate about which system is the source of truth.

In the invoice example, the explanation is simple: Dataverse owns the review, exception, and approval workflow before the ERP transaction; the ERP owns the vendor invoice, financial posting, and payment.

That is a healthy boundary.

Dataverse does not need to be the database for every application or the backend for every system.

It is most valuable when it gives governed operational work a durable home: work with shared ownership, relationships, lifecycle, security, automation, accountability, and a need to connect people and systems.

Sometimes it owns that work directly. Sometimes it extends the system that owns the core transaction. Sometimes it participates without owning the record at all.

The point is not to maximize the amount of data stored in Dataverse. The point is to create an architecture in which important work has a clear owner, a clear lifecycle, and a trusted source of truth.

Bridge to Part 4

We will close out this Dataverse series in Part 4.

By then, we will have established that Dataverse does not need to own every kind of work. But when Dataverse does own the governed operational record, another question remains: where should people experience and collaborate around that information?

A source of truth is not defined by where data is visible. It is defined by where the organization governs, maintains, and trusts that data.

In the final part of this series, I will explore what it looks like to keep Dataverse as that governed source of truth while surfacing selected, approved information in Notion…giving people a more flexible work experience without turning Notion into an uncontrolled replacement for the system of record.

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.

There’s a version of leadership that gets repeated so often it’s become wallpaper: don’t bring me problems, bring me solutions. Most people nod at it and move on. Fewer people apply it to how they consume information.

Open any feed on a given morning and you’ll find the AI and tech space running on a different rule entirely. A headline warns that a model will replace an entire profession. A thread declares that some new capability spells the end of privacy, or trust, or human judgment. The alarm is loud. The proposed remedy is almost never there. You finish reading and you know what to fear, not what to do about it.

That gap is the problem. Not the technology. The commentary.

The Pattern

Fear travels faster than nuance, and hot takes are built for speed. A prediction of collapse gets shared. A measured breakdown of trade-offs gets skimmed and forgotten. The incentive rewards the loudest framing, not the most useful one, and over time the discourse trains people to expect alarm as the default posture toward anything new.

Watch closely and the pattern repeats across almost every wave. New capability arrives. A chorus declares the sky is falling. A smaller, quieter group asks what changes for the people who have to work with this tomorrow morning. The second group rarely gets the same reach, but it does the actual work.

I’ve sat across the table from clients who read the alarm and absorbed it as fact. They arrived at the discovery call convinced a tool would either replace their team or fail spectacularly, with no room for the middle ground where most real outcomes live. Untangling that fear took longer than it should have. Someone upstream chose the take that traveled instead of the one that helped.

I’ve heard death pronounced so many times, for so many platforms, and still find myself across from customers asking how to implement the dearly departed. The thing most fear mongers fail to take into account is adoption, and the rate at which organizations can feasibly absorb the latest and greatest. Another item that goes uncounted, especially in AI, is the actual use case. Daily I sit with customers looking for viable use cases that fit their organization. Daily, I have to walk customers back from the ledge, because they heard, and didn’t quite see.

I’ve heard AGI declared, and apps promised to build themselves from nothing but a prompt, only to watch some of the biggest vendors quietly walk it back once the bill came due. The claim shrinks into a footnote a few announcements later, while the original headline keeps circulating as though it still holds. It would be a mistake on my part to repeat that headline to customers big and small just because it read well. They deserve an honest read of what a platform can do this quarter, not what a keynote implied it might do someday.

The Standard

Bring me problems, bring me solutions isn’t a rejection of concern. Concern is often correct. A new capability can shift power, displace work, introduce risk that didn’t exist before. None of that should be waved away.

The standard is what comes after naming it. If a piece raises an alarm, it owes the reader a next step: a mitigation, a framework for thinking it through, a boundary worth drawing, a question worth asking before adoption. Absent that, the piece isn’t analysis. It’s noise wearing the costume of insight.

This is the filter worth applying before you share, and before you let something reshape how you think about your own work. Ask what the piece is asking you to do differently. If the answer is nothing except to feel worse, that’s the tell.

The Takeaway

The next time a hot take crosses your feed, don’t ask whether it’s alarming. Ask whether it’s useful. Fear without a path forward is just weather. Anyone can report on it. The people worth listening to are the ones still standing there after the storm, pointing at the door.

The Difference Between Holding Data And Owning It

In college, we learned about MySQL. My first website ran on it.

The more I worked with data, the more I noticed that every database has its own character. Some are built for transaction speed. Some for scale. Some are relational. Others are document stores, or analytical warehouses built to answer a different kind of question entirely.

Then there’s Excel. A spreadsheet holds data, shapes it, answers the question in front of you. But holding data and serving as the truth are not the same job.

In my early ERP days, accounting teams asked for database extracts constantly. We pulled records from SQL Server. They turned the rows into a model they could report from. That spreadsheet served its purpose for exactly as long as it took someone to open it. The moment it closed, it was already out of date. The ERP behind it held the truth that mattered.

So when a client asks what Dataverse is, telling them it’s a Microsoft database misses the point entirely. The real question isn’t what it is. It’s what business outcome it was built to enable.

Data With A Lifecycle

There’s a fundamental difference between a website capturing records and an enterprise process managing customer requests, approvals, risk, and cross functional delivery.

In that second scenario, data doesn’t sit still. It has a lifecycle. It requires normalization, security boundaries, defined relationships, event automation — structure a spreadsheet was never designed to hold.

Dataverse was built for that standard. It gives applications, reporting, and AI a foundation reliable enough to act on.

The Common Data Model

Every Dataverse environment ships with the Common Data Model already in place.

The Common Data Model is not Dataverse. It’s the blueprint underneath it — standard business entities like accounts, contacts, activities, and opportunities, along with the relationships that connect them.

Most organizations don’t actually struggle with storing data. They struggle with agreeing on what it means. One department tracks a customer. Another manages an account. A third bills a client. Every integration, every board report, every AI deployment stalls at the same point: reconciling whether those three records describe the same thing.

The Common Data Model settles that question on day one. Teams build on proven definitions instead of untangling conflicting systems after the damage is done. Dataverse is simply where that shared language becomes operational.

It also saves teams from a mistake I’ve made myself: overbuilding. Instead of designing a schema from nothing, you extend standard entities to fit what’s actually unique about your business. The core stays disciplined. Predictable. Ready to scale without a rewrite.

The word “common” suggests every business has the same problem. It doesn’t, and they don’t. It’s a starting point, not a universal answer. I wish I’d understood that when I was architecting on what was briefly called Dataflex — I’d have leaned on the CDM from day one instead of boiling the ocean, which I’m fairly sure I did more than once.

What Dataverse Is — And What It Isn’t

What it is

So what’s the differentiator? Why does a business actually need it? Simply put — it doesn’t. SQL Server, PostgreSQL, Salesforce, ServiceNow, Oracle, custom architecture — all of them can do a version of what Dataverse does.

The difference is packaging. Dataverse arrives opinionated: a preferred way to model business data, manage access and identity, build apps, automate work, package solutions, and deploy them across environments. And because it’s Dataverse, you’re not just getting a database. You’re getting the door into the Microsoft ecosystem — Graph, first party and third party connectors, all of it.

What it isn’t

Dataverse is not the default for every workstream, and I’d be lying if I told a client otherwise. I would never tell a customer to replace their ERP with Dataverse. I would tell them how to run Dataverse alongside it.

The job of an ERP is to run the business: procurement, inventory, accounts receivable, accounts payable, general ledger, manufacturing, order fulfillment. Let it do that job.

Dataverse’s job is different. It’s the secure layer that connects those transactions to the people and processes surrounding them. It doesn’t need to be authoritative. It needs to be adjacent.

What I like about Dataverse, professionally, is that it can be a bolt on. Architect it correctly, and you can turn it off tomorrow without touching the system of record underneath it.

The Proceeding To The Preceding

Consider this the prelude. Next, we talk governance. If Dataverse is going to hold data that matters, it has to be managed like it matters — not treated as an unmanaged pile of entities and apps.

We’ll talk about how to empower makers and business units without losing control of the environment. Then we’ll get practical: which workstreams belong in Dataverse, and which ones don’t. Last, I’ll show you how Dataverse stays secure even as that data surfaces in the places people actually want to work.

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.

Introduction

When thinking about your Power Platform environment, it’s important to shift your mindset. Whether you’re a small business or a large enterprise, investing time upfront to secure your environment and follow best practices is crucial. One of the biggest reasons? Scalability.

In my opinion, some platform deployment failures stem from a lack of strategic planning for business growth. As your company scales, new challenges will emerge. While we can’t predict every obstacle, there are common patterns in how businesses and applications evolve. And if you believe AI agents will make business applications obsolete, let’s clarify something—policy applies to both.

At its core, policy isn’t about what you implement; it’s about how you implement it. It’s a strategic framework, not just a tactical checklist.

What are Data Loss Prevention (DLP) Policies?

According to this nice shiny definition found on Microsoft Learn:

Data Loss Prevention (DLP) is a critical aspect of maintaining data security and compliance within the Microsoft Power Platform ecosystem.

My definition is much shorter and it simply is: “You can’t do that because the organization said so!”

Connectors

DLP policies play a critical role in keeping company data from unintentionally ending up on platforms like LinkedIn. One of the Power Platform’s biggest strengths is its access to over 1,000 connectors—and if one doesn’t exist, you can build it. But realistically, do users need access to every connector? Do they need to create custom ones? The short answer is no.

Because anyone with an M365 license has access to the Power Platform, technically, anyone can be a maker. While Microsoft encourages citizen development by providing open access to the default environment, the responsibility of enforcing policies doesn’t fall on Microsoft—it falls on the organization. That means preventing data leaks and securing Power Platform solutions isn’t optional; it’s a core responsibility for license owners.

Strategic Thinking

The more I engage in governance projects, the more I notice a common trend—and it’s not the lack of policy that concerns me. What worries me most are the gaps in strategic thinking when it comes to the Power Platform. Too often, organizations approach it as just another tool rather than a foundational part of their technology strategy.

Like any enterprise software, the Power Platform needs a well-thought-out deployment strategy. It’s not just about setting up policies; it’s about ensuring long-term scalability, maintaining clean and reliable data, and prioritizing security. Without a strategic approach, organizations risk inefficiencies, data sprawl, and security vulnerabilities that could have been prevented.

Over time, little by little, I’ve been encouraged to see companies shifting their perspective. What was once seen as a “neat little toy” bundled with E3 licensing is now starting to be recognized as a critical piece of the technology roadmap—powering mission-critical applications and driving real business outcomes. I hope this trend continues. I hope implementation include a more sound approach.

The Consultants Responsibility.

It’s also up to the consultant. As we engage with clients and deploy the Power Platform, we have a responsibility to take real-world use cases—including the horror stories—and use them to shape better strategies moving forward. Experience is one of the best teachers, and it’s our job to ensure that lessons learned don’t go to waste.

I’ve worked with combative clients who initially saw no need for a strategic approach to Power Platform implementation—until I helped them see the bigger picture. Often, resistance comes from a lack of understanding, not a lack of willingness. Once decision-makers recognize the risks and long-term implications, they begin to appreciate the value of governance.

We also can’t assume that users and citizen developers will fully grasp the security risks tied to the connectors they use—that’s not their responsibility. It’s on us to establish the right policies, provide guidance, and build a framework that protects both the organization and its data. In governance, being proactive isn’t just a best practice—it’s a necessity.

Informing Governance as a Whole

In my experience, the more we discussed governance within the Power Platform, the more it prompted decision-makers to rethink governance across their entire IT landscape. These conversations often led to deeper questions: What hidden risks exist? Where are the data silos? Who has access to sensitive information that they probably shouldn’t?

The real value in these discussions is that while I’m advocating for a strategic approach to the Power Platform, I’m also making the case for stronger governance overall. It’s not just about one tool—it’s about creating a cohesive, well-managed IT environment that serves the entire organization. When governance becomes a priority, it enhances security, improves data integrity, and ultimately drives better business outcomes across all systems.

Some might argue otherwise, but let’s take a step back—where does the data powering the Power Platform actually come from? In many cases, especially when integrating with REST services to connect to a non-Dynamics ERP or even when working within Dynamics, the data originates from silos. These are the same silos feeding into ERPs, business processes, and, more concerningly, systems that IT may not even be aware of.

This is why governance isn’t just about securing the Power Platform—it’s about understanding and managing the entire data ecosystem. Without proper oversight, organizations risk building solutions on fragmented, uncontrolled, or even unauthorized data sources. Make governance a crucial part of not just platform strategy, but overall IT strategy.

Call to Action

If you’re struggling with governance, take action today:

• Engage Your Partner – If you have a trusted partner, reach out for an assessment to identify gaps and improve your strategy.

• Tap Into the Community – If you have general questions, the Power Platform community (myself included) is here to help. Don’t hesitate to ask.

• Leverage Microsoft Tools – Install the CoE Starter Kit to gain insights and control over your environment.

• Educate Yourself – Explore Microsoft Learn for governance best practices and guidance.

Governance isn’t just a checkbox—it’s an ongoing effort. Take the next step today!

1. Introduction
2. Governance
3. The reasons that we’re here
   1. Lack of Version Control
   2. Deployment Instability
   3. Difficult to troubleshoot issues
4. Deploy managed solutions
5. Call to Action

Introduction

I don’t want to be the bearer of bad news—well, maybe just a little. My goal is to save you from yourself, so let me be clear: WE DO NOT CREATE UNMANAGED LAYERS IN PRODUCTION!

If you’re serious about maturing on the Power Platform, there are a few fundamental principles you need to grasp. I get it—the way Power Platform is set up, with everyone having a default environment, can feel like the wild west. But there are some non-negotiables. At the very least, you should be working with two environments—ideally, three: one for development, one for testing, and one for production-ready solutions. You know, a proper application lifecycle management (ALM) process—the same concept they drilled into us in college.

In theory—and in practice, based on what I’ve seen over the years (including my own mistakes)—you can do whatever you want. But at some point, you need to stop, take a step back, and ask yourself: Is a “hot fix” in production really worth the risk?

My answer? Absolutely not. And here’s why.

Governance

Yes, the G word—governance. Autonomy is great—until there’s a data breach. Then suddenly, we’re all asking how our favorite retailer leaked our PII (Personally Identifiable Information), and I’m staring at an email telling me to cancel my credit card, pack up, and start a new life.

Okay, maybe this article isn’t that dramatic—but it could be. Governance isn’t just a Power Platform concern; it applies everywhere. And while we champion secure backends like Dataverse, security only works if we take governance seriously. So, do yourself a favor—treat it like it matters. Because it does.

I have the privilege of working alongside some of the world’s premier experts in governance and compliance, partnering with some of the biggest names in business. And time and time again, we find organizations falling into one of two categories:

The Gentleman’s Approach

These organizations recognize the power of Power Platform but haven’t fully deployed it across their enterprise. They want to get ahead of the chaos by implementing governance before things spiral out of control.

Please Save Us

On the other hand, some organizations have already deployed Power Platform—without guardrails. Now, it’s out of hand, and they’re desperately looking for a way to regain control before things get worse.

If you’ve taken the Gentleman’s Approach, thank you. It makes life so much easier when we can focus on methodology and toolkits to set you up for long-term success.

If you’re in the Please Save Us camp, thank you as well. Acknowledging the problem and committing to steering your organization in the right direction is a crucial step.

The Problem with Poor Implementations

Here’s the thing—lack of governance in Power Platform leads to poor adoption. We have this powerful platform at our fingertips, but if security gaps, broken processes, or unchecked risks get in the way, no one wants to use it—or worse, no one can use it safely.

CIOs and the Tough Questions

Do CIOs make my job harder when it comes to governance? Yes. And they should. The tough questions need to be asked. Don’t just take my word for it—press me, challenge me, ask for sources. This is your organization, your investment, your future.

As a consultant, I care deeply about the services I provide, but at the end of the day, I will roll off your project at some point. My goal? To leave your organization better than I found it. And that is part of the reason we don’t create unmanaged layers in production!

The reasons that we’re here

Lack of Version Control

It’s right there, staring you in the face. You can do it. Just pop that flow open, add that missing action, and everything is right with the world—until it’s not.

Whatever the reason, you must operate with the mindset that tweaking production directly is not acceptable. You cannot predict unexpected behavior, and doing so completely undermines your version control and environment strategy.

If you have a production environment (and please don’t tell me it’s the default environment—that’s a conversation for another day) and some form of environment strategy, respect it.

Make your changes in the lower environments, test them, get sign-off, and deploy to production—the way it should be done.

Deployment Instability

In production, or at least in managed solutions within production, we have what are called solution layers. (I even included a nice, shiny image above to illustrate this—you’re welcome.)

When you create unmanaged layers, you introduce the possibility of deployment failures down the line. The artifacts and components in future deployments weren’t designed to handle the unexpected behaviors you introduced by manipulating a solution directly in production.

Save your deployments. Do it the right way.

Stick to the process—develop, test, get approval, deploy. Your future self (and your team) will thank you.

Difficult to troubleshoot issues

The degree of difficulty in troubleshooting can vary—but it becomes exponentially harder when you don’t even know what you’re looking for.

The unpredictability of removing a single component, a line of code, or an action in a flow can drive even the most rational person up a wall. One small tweak can have ripple effects you didn’t anticipate, turning a simple fix into a time-consuming nightmare.

Let’s avoid unnecessary cleanup, frustration, and sweat-inducing emergencies. Follow best practices, respect your environments, and don’t create an unmanaged layer in production.

Regardless of which camp you fall into, governance matters—whether you’re planning ahead or trying to clean up the mess.

Deploy managed solutions

This should go without saying—but I’ve seen it all. I’ve been on engagements where entire production environments were packed with unmanaged solutions, and it took months to convert everything to managed.

I want my clients to be set up for success, even if it means being a thorn in someone’s side. I get that introducing complexity, governance, and strategy might seem like extra overhead for IT. But trust me—it’s worth it.

Now, think about the alternative: years of unmanaged layers, uncontrolled deployments, and an unrestricted environment that you still call production. The overhead and nightmares that come with that far outweigh the effort of doing things the right way from the start.

If your goal is to build a mature Power Platform model, then you need a strategy in place. Create the necessary environments, security groups, and pipelines to establish a structured, secure, and scalable framework.

Call to Action

It All Starts with Education

Educate your business units, educate IT, heck—educate your dog if you have to. A mature Power Platform adoption is an organizational effort, not just an IT initiative. Do it the right way.

Use the Right Tools

You have plenty of tools at your disposal:

✅ The CoE Starter Kit – Provides a holistic view of your environment.

✅ Power Platform Admin Center – If you’re not ready for the CoE, at least establish a management strategy here.

✅ Security Groups (M365 or Entra ID) – Set them up early to enforce governance and access control.

One Rule Above All

Whatever you do, do NOT create unmanaged layers in production.

1. Introduction
2. The Logic Engine Behind Power Apps
3. Solution
   1. Canvas App
      1. Project Proposal Main Grid
      2. Project Proposal Entry Form
   2. Power Automate
      1. Handling Scope Logic

Introduction

One would think that by now, we’d all be settled on what Power Automate can do. But surprisingly, that’s not the case. It feels strange to still use the word “potential” when talking about Power Automate, especially since I’ve seen it achieve some pretty amazing feats. It has served as an integration point between the Power Platform and external systems, connected Azure and the Power Platform, and even acted as the logic layer for Power Apps. Yet, I still find myself in conversations with customers, exploring the true depth of its power and capabilities.

Over the next few weeks, I’ll be sharing more about what Power Automate can do. This week we’ll be talking about Power Automate as the logic layer for Power Apps. Follow along to learn more!

---

The Logic Engine Behind Power Apps

Power Apps is very capable. The problem is that the more complex your logic gets, the more complicated your formulas become. In my experience as a Power Platform developer, it’s rare to build a solution without involving at least one Power Automate flow. These flows are usually triggered by something happening in Power Apps—either directly when the app triggers an automation or once a record that was changed in the app meets certain conditions (like a CRUD operation in Dataverse, SQL Server, or SharePoint).

---

Solution

Below is a refined version of your text, maintaining a casual style and clear flow:

---

Our solution will include two components: Power Apps and Power Automate. We’ll be working on a “Project Proposal” process, where every proposal requires approval. Depending on factors like scope or budget, the proposal may need multiple approvers or just one. I won’t walk through the entire build here since this post is purely informational, but I will share screenshots and add details to illustrate each step.

---

Canvas App

Project Proposal Main Grid

When you first open the app, you’ll see a main grid listing all project proposals. Each row shows basic details like project name, budget, primary approver, and scope. This screen lets you quickly scan and select any proposal for more information.

---

Project Proposal Entry Form

This is where you enter all the core information for a new project proposal. It includes fields for basic details like project name, estimated budget, and scope. Once you fill out the form and submit, the proposal is added to Dataverse and triggers the Power Automate flow to handle scope logic.

---

Power Automate

Handling Scope Logic

The crux of this solution is how we’re handling our logic. Sure, I could have written an expression with multiple If statements—maybe even nested ones—to get the result I wanted. But instead, I’m passing the necessary parameters to the Flow and letting Power Automate handle the conditional logic. If I ever want to add more conditions, I can do it in a visual way without diving into Power Fx.

Power Automate also offers other logic controls beyond simple If conditions, such as switch statements and parallel branches. This gives you a drag-and-drop interface to manage complex pathways—like sending notifications to different groups or looping through multiple records—without having to manually write or manage code. It’s all about making your logic more transparent and maintainable, so you can expand on it as requirements evolve.

Thank you for reading!!