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.

My wife doesn’t use Claude. She doesn’t use ChatGPT either, not directly, not by name. What she says, almost every time a question needs more than her own head can give it, is some version of the same line: “Let’s see what Copilot says.”

Not Claude. Not ChatGPT. Copilot. Every time.

I’ve built a career around Microsoft’s ecosystem. I know the gap between these tools is thinner than the marketing around them suggests, and I could make an argument for why one might suit a given task better than another. But that isn’t what struck me about her sentence. What struck me is that she never asks which AI to use. She has one. It’s the one she has. The question of alternatives never enters the room.

And I think that’s the healthier instinct.

Somewhere in the last two years, picking an AI tool turned into a small identity decision. People defend their choice the way they’d defend a phone or a browser or a car. Claude people talk about writing quality. ChatGPT people talk about breadth. Copilot people talk about what’s already sitting inside the software they use all day. Every camp has a reason, and every reason is a little bit true, and none of them matter nearly as much as the conversations happening around them suggest.

Here’s the part worth sitting with: my wife gets useful answers. Reliably. Without ever wondering if she picked the right poison. She picked one, and then she moved on to the actual problem she was trying to solve.

That’s the piece a lot of us lose once we know enough to have opinions. Knowing the differences between these tools is genuinely useful when you’re the one deciding what to build on, what to integrate, what to put in front of a client. That’s my job, and I won’t pretend the choice never matters. But for most people, most days, the tool isn’t the bottleneck. The question they’re asking is.

I’ve watched people stall out entirely because they’re not sure they’re using the “right” one. They’ll wait, or ask around, or read another comparison post, before they’ll just open whichever tool is already sitting on their desktop and ask their question. That hesitation costs more than any gap between the tools ever could.

So pick your poison. Whichever one is already in reach, already familiar, already one click away. Use it until you have an actual reason to switch, not a vague sense that somewhere out there is a better answer to a question you haven’t asked yet.

My wife never wonders. She just asks Copilot.

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.

For years, organizations have been trapped in product silos. You sign an enterprise agreement, you standardize on one product, and you swear by it. There is nothing wrong with that. I used to believe the same thing, until I matured.

I’m not going to climb out on a limb and say that everyone who thinks differently is immature. But I will say this: choosing a single product and dying on that hill is a thing of the past. You have to choose the right tools, and for a consultant, that toolbox is always shifting.

Outcomes over products

In my experience, I’ve implemented many of the same processes across customers in very different verticals. I’ve been fortunate to accomplish a lot with their ERP and the Power Platform. But I’ve also come to understand, especially in the age of AI, that we have to be outcome focused.

If a point solution already handles a specific function, and it has an API, an MCP server, or writes to a SQL database, use it. Then let’s put our energy into the parts that Power Automate, a Logic App, or Copilot can handle.

And what if the answer isn’t Power Automate or any of those tools? Then ask the real question. What is your outcome? What are you driving toward, and what is the best vehicle to get you there? The destination is the same: profitability, efficiency, and fewer nights burning the midnight oil. The terrain just changes depending on the sector you’re in.

Trust me, when I realized I couldn’t Power Automate my way out of every problem, and I was introduced to outcome driven concepts like “jobs to be done”, it bothered me.

Be product agnostic

The best way to serve an outcome is to be product agnostic. That doesn’t mean abandoning my foundation. It means I’m willing to work toward the conclusion, and I don’t care how we get there, as long as we get there.

Pick the harness, not the hype

Throughout this AI race, the rhetoric has been about figuring out which “Bear is best.” For me, even though I’m deeply entrenched in Microsoft technologies, my workflow includes Anthropic. Microsoft, Notion, and Perplexity have all understood the same thing: they need to be a harness where these models can live and actually help the customer.

I use Notion every day to manage my tasks, projects, and everything in between. When they introduced Notion AI, and more recently Agents, I didn’t feel the need to switch between models, because my tasks don’t call for it. When I want a daily digest, or want to build my weekly status report from my various databases, I jump into Claude Cowork and use the Notion MCP server.

I stopped using ChatGPT, not because it’s a bad product, but because it no longer fit my workflow. I still have colleagues who hold the licensing and get plenty out of it.

Look, the point is this. Don’t bring a hammer to a job site that only needs a screwdriver. Every job is different. Select the best tools and deliver outcomes.

---

Stop Guessing: How Prompt Coach Trains You to Actually Talk to Copilot

I’ll start with a confession. After spending some serious time with Microsoft 365 Copilot’s Prompt Coach agent, I came to a humbling realization: for thirteen years, I have been giving my wife improper instructions. Maybe my ambiguity has resulted in some strange lover’s quarrels and to that end, I must also apologize to my spouse…its partially my fault.

“Can you grab something for dinner?” is a prompt with no goal, no context, no constraints, and no format. It is the marital equivalent of typing “help me with the project” into Copilot and being mildly offended when the output is useless. My wife, bless her, has been doing the work of an LLM for over a decade. Inferring intent. Filling in gaps. Producing a reasonable response from input that, frankly, did not deserve one.

Next time I’ll ask Q if she’d just stop at our favorite Jamaican restaurant and get me some curry goat, rice and peas, and cabbage.

Most people who try Microsoft 365 Copilot for the first time have the same experience. They type something vague, get back a generic, soulless response, and quietly conclude the hype was overblown. The hype isn’t overblown. The prompt is. The gap between a mediocre output and a genuinely useful one almost always comes down to how you structured the request.

The good news is that Microsoft has baked an answer to this directly into the platform. It’s an agent called Prompt Coach, and it teaches you the fundamentals of effective prompting while you work, not in some separate training module you’ll never finish. The better news is that the skills transfer. Once you internalize how to talk to Copilot, you’ll find yourself accidentally becoming a better communicator with humans, too. Over time, your spouse will thank you.

This article walks through Microsoft’s GCSE framework for strong prompts: Goal, Context, Source, and Expectations. And it shows how Prompt Coach reinforces each one until clean prompting becomes muscle memory.

What Prompt Coach Actually Is

Prompt Coach is a pre-built agent template available in Microsoft 365 Copilot. You can install it from the Agent Store and run it inside the Copilot app, where it acts less like a tool and more like a patient teacher sitting next to you, gently judging your life choices.

It does four things: helps you generate well-structured prompts, analyzes prompts you’ve already written, fixes the broken ones, and walks through worked examples that explain why a given prompt is effective. It works through an iterative feedback loop. You give it a rough idea, it asks clarifying questions, and you end up with something far sharper than what you started with.

Prompt Coach is my go to. As a Power Platform developer I use it to refine prompts I embed into Power Automate flows, and to help me generate instructions for agents in Copilot Studio. The point is this: use it as long as you need to. Over time, it will become second nature to write prompts that net you the outcomes you actually want, instead of whatever Copilot guessed you wanted while you weren’t looking.

The Four Pillars: Goal, Context, Source, Expectations

Microsoft’s own internal framework for prompting is referred to as GCSE: Goal, Context, Source, Expectations. Every strong prompt answers four questions before Copilot ever sees it. Whichever vocabulary you prefer, the mental model is identical.

1. Goal: What do you actually want?

The goal is the non-negotiable piece. If your prompt has nothing else, it needs this. A goal is the specific outcome you want Copilot to produce. A draft email. A summary. An analysis. An outline. A comparison.

The mistake most people make here is confusing context with a goal. “I am a consultant who regularly requests access to my clients’ environments. Rewrite this email to ask IT for environment access” gets you part of the way there, but it’s mostly background, not an objective. “Rewrite a professional email requesting IT environment access” is a goal.

Where Prompt Coach helps: when you feed it a vague goal, it pushes back. It asks what kind of output you want, what success looks like, and whether you’re trying to inform, persuade, decide, or summarize. That nudge alone fixes maybe half of all bad prompts.

2. Context: Why does it matter, and who’s involved?

Context is the background information that lets Copilot tailor its response to your actual situation. This is where you tell it who the audience is, what the project is about, what’s already been decided, what tone is appropriate, and any history that affects how the response should land.

A status update for your skip-level executive reads very differently from one for your peer engineering team. Copilot can’t infer that from “draft a status update,” and honestly, neither could I. But it absolutely can deliver if you say “the audience is our CFO, who hasn’t been close to this project and cares mostly about budget impact and timeline risk.”

Where Prompt Coach helps: it consistently asks the “who is this for and why” question. Over time, you start front-loading that information without being prompted, which is the whole point.

3. Source: What should Copilot ground itself in?

Source is where you specify which information Copilot should draw from. A specific SharePoint folder. A Teams channel. A particular file. Emails from a date range. Standard corporate language from a given domain. Grounding your prompt in the right sources is what separates a generic output from one that’s actually accurate and relevant to your situation.

Where Prompt Coach helps: it flags when you’ve referenced something without being specific about it. If you mention “the project document” without naming it, Prompt Coach will ask which one. That habit alone prevents a surprising number of hallucinated details.

4. Expectations: What are the boundaries and format?

Expectations cover both your constraints and the shape of the output. Word counts. Tone restrictions. Things to avoid. Scope limits. And the format itself: bullet list, table, paragraph, email, slide outline, JSON, executive summary, FAQ.

Specifying expectations isn’t a nice-to-have. The same content delivered as a wall of prose versus a clean three-column table is, for most business purposes, an entirely different deliverable. Expectations are what stop Copilot from producing a 2,000-word essay when you needed three bullet points.

Where Prompt Coach helps: it routinely suggests format improvements you wouldn’t have thought of. Asking for “an analysis” might prompt it to suggest a table comparing options against criteria, with a short narrative recommendation underneath. That’s a better answer than what you would’ve asked for, which is a mildly insulting thing to admit but here we are.

Prompt Coach in Action: A Worked Example

Here’s what this looks like in practice. A consultant submits a reasonable but under-specified prompt to Prompt Coach: “I am a consultant that needs that regularly requests access to my clients environments. Rewrite this email to ask IT for environment access.” Prompt Coach recognizes the instinct to improve the prompt is right, and responds with a plan to do three things in one pass.

First, it analyzes the original prompt. The prompt does have some things going for it: it states the role, identifies the task, and names the audience. But Prompt Coach calls out exactly where it falls short.

The prompt is under-specified. Goal clarity, context, tone expectation, constraints, and output expectations are all missing or vague. Copilot will guess at each of these and guessing is what leads to weak or unusable drafts.

Next, Prompt Coach rewrites the prompt with all four pillars in place: a clear goal, full context, grounded source material, and explicit expectations for tone and output format.

That improved prompt then produces a clean, professional email ready to send not a template that needs another hour of editing.

The quality of Copilot’s output is directly tied to how complete your prompt is. By clearly defining Goal, Context, Source, and Expectations, you turn Copilot from a “rewriter” into a reliable drafting assistant.

Why Prompt Coach Beats Reading a Cheat Sheet

Cheat sheets and one-off training sessions don’t move the needle on Copilot adoption because prompting isn’t an information problem. It’s a habit problem. People know they should add context. They forget in the moment because they’re busy and the blank prompt box doesn’t ask for anything specific. It just sits there, mocking you with its emptiness.

Prompt Coach changes that by interrupting the bad habit at the exact moment it’s happening. You write a weak prompt, the agent flags it, asks the missing questions, and you end up with a strong prompt and a small lesson about why it’s stronger. Repeat that loop fifty times across a couple of weeks and the structure stops feeling like a checklist and starts feeling like the only sensible way to ask for anything.

That’s the real value here. Not that Prompt Coach writes your prompts for you, but that it trains you to write them yourself. And once you’ve internalized Goal, Context, Source, and Expectations, every other Copilot experience in Microsoft 365 gets dramatically more useful overnight.

Getting Started

Prompt Coach is available as an installable agent from the Microsoft 365 Copilot Agent Store. Install it once, pin it in your Copilot app, and use it as your sparring partner for any prompt you’re not sure about. Especially the high-stakes ones, where a generic output would actually cost you time.

The first week will feel slow. By the third week, you’ll be writing prompts that include all four pillars without thinking about it, and the people on your team who skipped this step will be wondering why your Copilot outputs are so much better than theirs.

It’s because you stopped guessing.

And, if you’re lucky, your spouse stopped guessing too.

Introduction

The era of open-ended AI ideation is ending. What’s replacing it is disciplined product work. Sessions are no longer judged by how inspiring they sound, but by what they actually enable. Teams aren’t tired of AI. They’re tired of pilots that never ship, noise without signal, and dashboards that can’t prove value.

Brainstorming still matters. But after an expensive huddle, the question that lingers is simple. What did we build that someone can actually use?

You hear it a lot lately. SaaS is dead. ERP is dead. That’s overstated. Deals are still being signed. Platforms are still being bought. What’s really dying is patience. Organizations are reacting to years of bold promises followed by uneven delivery. Capabilities sold as transformative end up incremental. Timelines stretch. Value becomes harder to explain.

Disappointment comes first. Then fatigue. Then frustration. Eventually it shows up where it always does. Tighter budgets. Slower buying cycles. Less trust in the partners brought in to help. Not because the models don’t work, but because the outcomes haven’t matched the rhetoric.

That tension is reshaping how leaders think about AI and transformation. Ideas alone aren’t enough anymore. Activity isn’t progress. What matters is whether the work leads to something shippable, measurable, and owned. If it doesn’t, it blends into the growing pile of initiatives that sounded promising and changed very little.

That shift in expectation is the real story.

Fear of Being Left Behind

A major driver behind many of these costly sessions is fear. Fear of being left behind. AI is everywhere and it’s moving fast. Organizations don’t have to wonder if their competitors, suppliers, or customers are investing in it. They are. That creates pressure to act. Invest now. Build now. Ship something now. And that pressure isn’t imagined. It’s justified.

The problem is what happens next.

Too many teams stop at awareness. We know the market expects AI. We know our competitors are using it. So motion becomes the goal. More tools. More pilots. More demos. Less clarity. The focus turns outward when it should be turning inward.

The harder questions get skipped. Is AI creating business value? Are operations actually better, or just different? Are employees more effective, or simply surrounded by tools they didn’t ask for? When those answers are unclear, the issue isn’t speed. It’s intent.

Knowing others are “doing AI” doesn’t make an organization stronger. Improvement does. That requires stepping back from the noise and being honest about what’s working, what isn’t, and why. AI has to earn its place like any other serious capability. Through outcomes, not excitement.

This is where many strategies start to wobble.

Educate

I recently participated in a hackathon, and the problem showed up almost immediately. The group didn’t have a baseline. Not on the tools. Not on the environments. Not on how anything connected. We could have pushed through and checked the box. That would have been easy. It also would have been meaningless.

The issue wasn’t effort or intelligence. It was context. Basic concepts like environments and connectors became blockers, not because they were complex, but because they were unfamiliar. That raised an uncomfortable question. Who owns that gap? The organization? The facilitator? Me? The goal was to move fast and show what the tools could do. Without shared understanding, speed just amplified confusion.

What helped wasn’t more features. It was grounding. A short deck. High-level. No hype. What each tool does. Where it fits. How the pieces connect. That alone changed the room. Once everyone had a shared mental model, we could build. No-code and low-code tools did the rest. The work improved. The conversation shifted.

That’s when the real lesson landed.

We didn’t need better tools. We needed more time to educate before execution. AI is still intimidating for a lot of people. The anxiety is real, especially for those who fear displacement. That fear doesn’t come from the technology itself. It comes from not understanding how humans stay in the loop and where judgment still matters.

Education isn’t optional. It’s the prerequisite. Organizations either invest in it deliberately or pay for it later through rework, confusion, and missed value. Tools don’t fail on their own. They fail when people are asked to use them without context.

Move with Intent

Once education is in place, the next step is execution. Not rushed execution. Intentional execution.

A colleague shared something that stuck with me. The best hacks start with use cases people already recognize. Real work. Familiar pain. Problems the room doesn’t need explained. When everyone can rally around the same use case, momentum follows. When they can’t, even strong builds struggle to land.

For this hack, I came in top-heavy. Too much solution. Not enough grounding. Combined with the earlier education gap, it could have gone sideways fast. We started with the tech when we should have started with the work.

If you want value from a hackathon, poll the group first. Ask simple questions. What task eats up your time every week? What work do you dread because it’s manual? What would make your day easier if it disappeared? Those answers matter more than any roadmap or demo.

What came out of this hack wasn’t flashy. It didn’t need to be. We used a SharePoint list, built a Copilot Studio agent, and added two flows to review vendor documents for compliance. Work that was previously manual became automated. No tab switching. No new windows. The value was immediate because it showed up where the work already happens.

That’s the difference intent makes. If we had identified that use case upfront, we could have scoped tighter and built cleaner. What took eight hours might have been much closer to production-ready. Not because we worked harder, but because we worked on the right thing from the start.

Don’t Take My Word for It

Collaboration between consultants and organizations matters more than most people admit. Real collaboration means challenge. You’re writing the check. We need you for references and repeat work. The incentives are aligned. So push us.

If an explanation doesn’t make sense, say so. If the value isn’t clear, ask why. That tension is healthy. It leads to better thinking, better designs, and better outcomes. It keeps everyone honest.

This work is expensive. AI credits cost money. Implementations cost money. Time costs money. And something will get implemented whether you’re in the loop or not. Staying silent doesn’t reduce risk. It just shifts it.

A lot of fatigue doesn’t come from bad intent. It comes from disengagement. Being too hands-off. Not asking why a solution is framed a certain way. Sometimes the answer isn’t an agent. It’s an automation. Sometimes that automation just needs a prompt. Other times it needs semantic search, OCR, or better data upstream.

The effort might be small. It might be significant. It might stretch the budget. That’s part of the work. What causes problems is assuming the first idea is the right one and letting it move forward unchecked.

The road to poor implementations is paved with good intentions. The antidote is simple. Stay involved. Ask questions. Challenge assumptions. That’s how AI stops being noise and starts delivering value.

Conclusion

AI isn’t failing organizations. Undisciplined execution is.

The shift happening right now isn’t about tools, platforms, or models. It’s about expectations. Leaders are no longer impressed by ambition alone. They want evidence. They want things that work. They want outcomes they can point to and defend. That’s not resistance to AI. That’s maturity.

Fear will keep driving investment. That won’t change. Education will keep determining whether those investments pay off. That shouldn’t be optional. And execution, when it’s grounded in real use cases and challenged at every step, is what separates progress from noise.

Hackathons, pilots, and workshops can still be powerful. But only when they’re anchored in shared understanding, familiar work, and clear intent. Otherwise, they become expensive rehearsals for things that never ship.

The same goes for partnerships. Consultants don’t need blind trust. They need engaged counterparts who ask hard questions, demand clarity, and stay involved. That pressure doesn’t slow things down. It prevents waste. It makes the work better.

AI will continue to move fast. Budgets will continue to tighten. Patience will continue to thin. The organizations that succeed won’t be the ones doing the most. They’ll be the ones doing the right things, in the right order, for the right reasons.

Educate first. Execute with intent. Stay involved. Challenge everything that doesn’t clearly deliver value.

That’s how AI stops being a distraction and starts becoming a capability.

For years I built automations wrong. It wasn’t that I didn’t know the technology. I was asking the wrong questions. A mentor taught me something that changed how I work: focus on the outcome. Transparent moment here — there were times I didn’t serve my customers as well as I could have because my thinking was too tactical, too event-driven, and not anchored to the goal.

Most automation workflows follow the same pattern: a trigger fires, actions run, decisions branch, and then the workflow stops until it fires again. Those steps matter. But when you step back and ask what all of those steps are actually trying to accomplish, you land on a more important question. What is your goal?

I meet clients constantly and they almost always lead with the same question: “can this tool meet my needs”? That’s fair. But here’s what I’ve learned. Every tool requires some concessions. If it can’t get you to your goal, it’s not the right tool regardless of how many features it has.

I want your business. That’s honest. But more than that, I want to earn the kind of relationship where you come back whether we sign this SOW or not, whether it’s next week or two years from now. That only happens if I actually help you get somewhere.

That question applies to how I run my own day too. I started asking myself what success actually looks like before I sit down to work, and the answer shaped everything. I want one place that reflects my entire day. Meetings, tasks, notes, all current, all in one spot. That goal is what drove me to build the morning process I now run every day with Claude Cowork as the orchestrator.

The Technology

The stack is intentionally minimal. Claude Cowork acts as the orchestrator, the intelligence that decides what needs to happen and in what order. It connects to Notion via the Notion MCP server, which gives it the ability to read and write directly to my Notion workspace. An AI orchestrator, a communication protocol, and a single workspace destination.

Each morning, the process kicks off by pulling my meetings for the day and placing them into a Notion database. From there it creates a daily digest, a dedicated entry that surfaces those meetings alongside the tasks I need to complete. It also creates a daily notes page and links it directly into the digest so everything is connected before I’ve touched a single thing manually.

Why the Goal-Driven Aspect Matters

Here’s where most automation falls short. It runs a checklist. Step one, step two, step three, regardless of what’s already been done, what’s changed, or what’s actually needed. That’s not intelligent orchestration. That’s a script with better branding.

What I wanted instead was a system oriented around a goal: my day workspace is current and usable. That’s it. Everything else, syncing meetings, creating the digest, linking notes, refreshing tasks, is in service of that goal. The orchestrator doesn’t ask what did I do yesterday. It asks what does today’s workspace need right now.

That distinction matters because my day doesn’t stop at 8am. Meetings get added, priorities shift, and sometimes I need the digest to reflect something that happened after the morning run. A goal-driven system handles that naturally. A midday refresh doesn’t restart the workflow from scratch. It checks what’s stale and updates only what needs updating. The digest gets updated, not recreated. The notes page preserves what I’ve written. Meetings that changed get synced and the ones that didn’t are left alone.

The Real Goal

What I’m ultimately working toward is managing my entire day from one place. Not a dashboard, not a report. A living workspace I can trust to be accurate whenever I look at it. The morning process gets it ready. The daytime refresh keeps it honest. Claude Cowork stops being an automation tool and starts being something closer to a daily operating system.

The goal isn’t to run a workflow. The goal is to always know where things stand.