My first leader in IT told me something early on: have a checklist. It sounded simple then. It matters more now.

Today an agent can write the code, run the build, and move on before you’ve finished your coffee. That speed is useful. It also makes it easy to lose track of what actually got done.

So I kept the checklist, and I gave it to the agent. Here is the loop.

How it works

1. The plan builds the checklist. My first prompt produces the plan, and the plan produces the checklist in Notion. One row per build step, in order.
2. The agent does the work. Each build prompt runs and the code gets written.
3. The checklist gets updated. The last step in my prompt template says: when you finish, take the summary of what you did and check off the matching rows in Notion. Claude, through an MCP server connected to Notion, does exactly that.

Here is what that looks like partway through a build:

What I get back:

• A running record of where the build stands, without rereading prompt history.
• A place to pick up after a break, a meeting, or a long weekend.
• A way to review what was completed, not what I assume was completed.
• Visibility from my phone, because Notion lives in the cloud and the checklist goes where I go.

The agent does the work. The checklist tells me the truth about it.

Tools change. The discipline doesn’t. Thank you, Dave.

If you build with agents, add one line to your prompt template: when finished, update the checklist.

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

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.

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

The problem

Some books arrive without a reason. Someone tells you to read it, you take their word, and a few chapters in you are turning pages while nothing lands. You never learned what you were looking for.

Understanding a book starts with understanding why you are reading it. Without that, you finish with a few highlights and a vague sense of having been in the room. With it, every chapter has a job to do.

I ran into this with Capitalism and Freedom by Milton Friedman. It was recommended to me, and I opened it with no clear sense of why it mattered. I could have read on and hoped the reason would surface. Instead I decided to build the reason first.

The workbook

The workbook is a PDF that AI builds for me before I read the first page. Every book gets the same structure.

The first page is an abstract: what the book is, when it was published, who wrote it, the themes that keep returning, and how to read it. For Friedman, the instruction is to read it as an argument. That one line changed my approach. I stopped collecting facts and started tracking claims and the evidence behind them.

Each chapter then gets its own page. At the top is a single line: why am I reading this? Below it are three questions to carry into the chapter and answer as I go. At the bottom is an open notes section for everything the questions did not anticipate.

The back of the workbook holds two tools. The first is a page of key terms, the concepts the book depends on. The second is a vocabulary log with three columns: the word, the page where I found it, and what I think it means in my own words.

Why the pen

Writing by hand slows me down in the right places. I upload the PDF to my reMarkable Paper Pro and write directly on the pages.

Typing is fast, and fast is a problem when the goal is understanding. A keyboard lets me transcribe a thought without ever holding it. The pen forces a decision about what is worth the effort of writing. An answer to a chapter question has to pass through my mind and my hand before it reaches the page, and that is where the learning happens.

I think of it as a touch point. The book is in front of me, the pen is moving, and the two stay connected. The device keeps the feel of paper, and the PDF keeps everything for one book in a single file I can carry anywhere.

The division of labor

AI builds the structure, and I do the thinking.

The model was trained on a great deal of written literature, so it is well placed to say what a book argues, where it sits, and what a careful reader should watch for. That is scaffolding. It tells me where to look.

It cannot do the looking. The answers on the page are mine. The definitions in the vocabulary log are in my own words, written before I check anything. If the same tool that built the workbook also filled it in, I would own a tidy document and no understanding.

There is one limit worth stating plainly. The model builds from what it knows about a book, not from the pages in my hands. When I asked for vocabulary from each chapter, it could not pull words from my edition. So the key terms page covers the core concepts of the book, and the vocabulary log stays blank for me to fill as I read. I would rather have an honest blank than a confident guess.

Build your own

You can set this up for any book in a few minutes. Start with this prompt and replace the brackets.

I am reading [title] by [author]. Build me a printable reading workbook as a PDF.
Page 1: an abstract covering what the book is, when it was published, who wrote it, its recurring themes, and how I should read it.
For each chapter, one page with a line at the top asking why I am reading this chapter, three questions to answer while I read, and an open notes section.
At the end: a page of key terms to know, with the chapter where each appears, and a blank vocabulary log with columns for the word, the page I found it on, and what I think it means in my own words.
Leave plenty of room to write by hand. If you cannot source something from the book itself, say so and leave it blank.

The tool matters less than the sequence. Decide why you are reading, write it down, then let the book answer.

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.

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.