The Workbench

Copilot Studio | The Skill That Isn't There

2026-10-19T08:00:00.000-04:00

Put an unquoted colon in the description of a Copilot Studio skill and nothing will tell you. Copilot Studio skips the skill, loads the rest of the agent, and the agent carries on as though the skill had never been installed. That isn't a bug report, by the way: it is documented behavior, spelled out in a troubleshooting table that lists eight reasons a skill gets skipped.

For most of the feature's life, that was a problem for whoever uploaded the file. The October 8, 2026 revision of the skills documentation changed the audience. Skills can now be shared through a marketplace (preview), and once a skill is something other people add to their own agents, a failure that makes no noise deserves a check that makes plenty.

Background

A skill, in Copilot Studio's sense, is a set of instructions written in a Markdown file named SKILL.md. At the top of that file sits a small block of YAML front matter, which is simply a few key: value lines fenced between two --- lines, carrying the skill's name and description. A skill can be a single SKILL.md, or a ZIP package that bundles it with scripts, templates and reference documents. The agent's orchestrator reads every skill's description and activates a skill when a user's request matches it, which is why the description matters as much as the instructions. Skills follow the open Agent Skills specification, which the Copilot Studio skills overview links directly, and they are available to agents powered by the GitHub Copilot harness, which bill in Copilot Credits.

The change is in Manage and delete skills in an agent (GitHub Copilot), which gained two preview sections:

Share a skill through the marketplace (preview). You can keep a skill private or share it with specific people or groups in your organization, for use "across Copilot Studio agents and other supported experiences". If you change a skill you already shared, you share it again to publish the new version.
Browse and consume marketplace skills (preview). You add a shared skill to your agent from a browse list. The agent gets a snapshot of the skill while keeping a reference to the original, and when a newer version exists you get an update notification the next time you open the agent, with an update button to take it.

The same page notes that general plugin support in Copilot Studio isn't available yet, so this is skills only. And the same page already carried the table I opened with. A skill is skipped for invalid YAML front matter, a missing name, a missing description, a description that is too long, a duplicate skill name, a SKILL.md that isn't UTF-8 without a byte-order mark, a supporting file that couldn't be written, or a package that fails structural validation.

Why it matters

For makers. A skill you write once can now reach every agent in your team without anyone passing files around, and the snapshot model is a considerate design. Your update never changes somebody else's agent behind their back; they see the notification and decide when to take it. The flip side is worth knowing on day one: a fix you publish doesn't reach anyone until they accept it, so "I already fixed that" and "their agent has the fix" are two different statements.

For professional developers. A skill is a file, and a file belongs in source control with a check in front of it. That troubleshooting table reads like a linter specification, and every row on it except two can be verified on disk before the skill ever reaches Copilot Studio. The duplicate-name row deserves particular attention now. With one author, two skills sharing a name is a typo. With a marketplace, it is a naming collision between teams who have never met. The docs don't describe how the marketplace handles two shared skills with the same name landing in one agent, but the loader's documented answer to a duplicate is to skip one, so I would settle on a naming convention, such as a team prefix, before the first share rather than after.

The demo

The demo is a preflight check: run every documented load-time rule against a skill on disk, package it, upload it, share it, then ship an update. Here is the checker against a folder of ten skills, each carrying one planted defect (output trimmed to four of its twelve findings):

PS> ./Test-SkillPackage.ps1 -Path ./samples/bad
[FAIL] colon-in-description  FM-YAML  Key 'description': unquoted value contains a colon followed by a space, which is not valid YAML. Quote it, for example description: "...".
[WARN] hash-in-description  FM-COMMENT  Key 'description': unquoted ' #' starts a YAML comment, so everything after it is dropped from the value. Quote it if the # is meant to be text.
[FAIL] long-description  DESC-LENGTH  description is 1100 characters. Copilot Studio skips a skill whose description is too long but doesn't state the number; the open specification's maximum is 1024.
[FAIL] lowercase-filename  PKG-SKILLMD  No SKILL.md in the folder. Found 'skill.md'; the file name is SKILL.md in capitals.
10 skill(s) checked: 8 FAIL, 4 WARN

Every finding carries a check ID, and the split between FAIL and WARN is deliberate. FAIL means the Copilot Studio docs say the skill will not load. WARN means something else disagrees with the skill (the open specification, or plain YAML) but Copilot Studio's own docs don't say it will be skipped. The hash-in-description case is my favorite of the lot: a description like Looks up a ticket by its number, for example #4521 is perfectly valid YAML, and YAML silently throws away everything from the # onward because it treats that as a comment. Since the file is valid, nothing stops the skill from loading; it just has half a description, and the orchestrator is matching requests against the half that survived. The script exits with code 1 on any FAIL, which is what lets it gate a pipeline.

And here is the front matter of the skill that passes, showing the fix for the most common failure:

---
name: expense-policy-check
description: "Checks an expense against company policy: spending limits, receipt rules and approvals. Use when someone asks whether an expense is allowed or what they need to submit it."
---

The description contains a colon, so it is wrapped in double quotes, which is exactly the remedy the troubleshooting table gives. The name uses only lowercase letters, numbers and hyphens, and it matches the folder the skill lives in, which the open specification requires and which keeps the duplicate check meaningful. Notice also that the description says both what the skill does and when to use it. That second half is what the orchestrator matches against, so write it with the words a user would actually type. Change the policy text to your own, keep the shape.

Steps to recreate

The Copilot Studio paths below come from Add an existing skill to an agent and the manage article above. You will need an agent powered by the GitHub Copilot harness, and PowerShell 7 for the scripts.

1) Clone skill-preflight-lab and run ./tests/Invoke-Tests.ps1. All 25 tests should pass, which proves the checker behaves on your machine before you trust it with your own skills.

2) Run ./Test-SkillPackage.ps1 -Path ./samples/good/expense-policy-check, then point it at your own skill folder. Point it at a folder of skills to catch duplicate names across them.

3) Package with ./New-SkillPackage.ps1 -SkillPath ./samples/good/expense-policy-check -OutDir ./out. It refuses to package a skill with any FAIL, puts SKILL.md at the root of the ZIP, and re-checks the finished package.

4) In Copilot Studio, open your agent, select the Build tab, select Skills in the components panel, then in Add skill select Upload a skill. Drag the ZIP onto the upload box.

5) On the Preview tab, ask "Is a 180 USD hotel night within policy?". The sample policy sets lodging at 250 USD per night, so the answer should lead with "within policy" and then list what to attach, including the hotel folio.

6) To share it, select the skill to open its configuration panel, select the three dots (...) and then Share. On the details page, select Share in the upper-right corner, choose Specific users or groups in your organization, add a colleague or a group, and select Apply.

7) As that colleague, open an agent on the Build tab, select the + icon next to Skills, then Browse skills (preview). Select the skill, and on its details page select Add. If Browse skills (preview) isn't there, the docs don't describe a setting that turns it on, so treat it as not yet available to you.

8) Now ship an update. Change the lodging limit in references/policy-limits.md, rerun steps 2 and 3, then in your agent select the skill, the three dots (...), and Replace, and pick the new ZIP. Share the skill again, because a changed skill doesn't republish itself. The next time your colleague opens their agent, they get the update notification. Until they accept it, they are still on the old limit!

Companion repo

Everything above is in skill-preflight-lab on GitHub: the checker, the packager, two skills that pass, ten that each fail in one documented way, and a 25-test suite that asserts the good ones pass and every planted defect is reported by its ID. The README maps each check ID to its source. Credit where it's due: the open specification ships its own reference validator, skills-ref, and if you work in Python you should use it. This checker adds the parts specific to Copilot Studio's loader, such as encoding, package shape and duplicates across an agent.

Final Notes

I like the marketplace design a great deal, the opt-in update most of all. But a sharing model raises the price of a quiet failure, and Copilot Studio's loader is quiet on purpose: skipping one bad skill so the rest of the agent keeps working is the right call for the person chatting, and the wrong signal for the person who wrote it. The fix is the same one we have always used for that kind of gap. The documentation already tells you the rules, so put them in a script, put the script in front of the share button, and let it be the thing that makes noise.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Copilot Studio | The Workflow That Runs Every Time

2026-10-16T08:00:00.000-04:00

Copilot Studio agents built on the GitHub Copilot harness can now run one of your workflows before every tool call, and that workflow is allowed to say no. The feature is called hooks, it arrived in preview at the end of September, and it answers the question a governance reviewer eventually asks about any generative agent: "how do I make sure the agent always does X, instead of only when it decides X is relevant?"

Until now the honest answer was that you couldn't, not completely. You could write better instructions, you could give a tool a sharper description, and you could hope. Hooks replace the hope with a mechanism.

Background

The new article is Hooks (GitHub Copilot) (preview), last updated September 29, 2026, and it is a brand new page in the agents experience documentation rather than an edit to an existing one. Like everything in that section, it applies to agents powered by the GitHub Copilot harness, which I wrote about on September 21st in The Agent Your Flow Can't Call, and it consumes Copilot Credits under usage-based billing.

A hook has two parts: an event, which is a point in the agent's lifecycle, and an action, which today is always a workflow. When the event fires, Copilot Studio calls your workflow, passes it the details of what just happened, and reads the workflow's response back into the conversation. The page puts the difference from a tool in one line that is worth memorizing: a tool runs when the agent judges it relevant, a hook runs every time its event occurs.

There are six events:

Start (pre-loop): a new conversation begins. Can return additionalContext, background text for the whole session.
User prompt submitted: before each user message is processed. Can return a modifiedPrompt.
Error: an error outside a tool call. Can return retry, skip or abort, plus the message the user sees.
Pre tool use: before a tool call. Can deny it, rewrite its arguments, or add context.
Post tool use: after a tool succeeds. Can replace the result the model sees.
After tool failure: a tool returned an error. Can add guidance for the model.

Every event also sends three common inputs: event, timestamp, and a metadata object carrying the conversation ID, the user's channel ID, their Entra object ID and display name, the channel, and the agent's ID, name and schema name. The three tool events can be scoped to specific tools, or left empty to apply to all of them.

Why it matters

For makers. This is the first time a maker can attach a deterministic rule to a generative agent without restructuring it into topics. A Start hook that looks up the user's region and open cases gives the agent the same context on every conversation, no matter how the user opens. A Post tool use hook that writes an audit row runs on every call, so "did the agent actually log that?" stops being a question. And you build all of it in the workflow designer you already use for tools.

For professional developers. If you have worked with lifecycle hooks in coding agents, the shape will be familiar, and the details deserve a careful read. Two in particular. First, Pre tool use is the only event that can block anything; every other event can add context or change values, but it cannot stop the agent. Second, and more important, hooks fail open. The page is explicit that if the workflow fails, times out, or returns something the agent cannot read, the agent continues as though the hook returned nothing, and it advises against relying on a hook as your only safeguard for a business-critical rule. I think that is the right default for a conversational product, and it is also the sentence your security reviewer needs to see before anyone calls a hook a control. Pair it with whatever the connector or the downstream system enforces on its own.

Something else to keep in mind is that the inputs are untrusted. The prompt, tool result and error values can carry content the agent did not produce, and the docs say so on each of them. A Pre tool use workflow that pattern-matches the agent's arguments is evaluating text a user may have shaped on purpose.

The demo

Take an agent with one sensitive tool, say the Office 365 Outlook Send an email connector action, and attach two hooks. A Pre tool use hook scoped to that tool only denies the call when any recipient is outside your own domain, and tells the model why. A Post tool use hook scoped to all tools writes one audit row per successful call, using the metadata object to record who asked and which agent acted. Then try to talk the agent into emailing an external address.

The deny branch of the Pre tool use workflow ends in a Respond to the agent node that returns these values:

{
  "permissionDecision": "deny",
  "permissionDecisionReason": "External recipients are not allowed from this agent. Offer to draft the message so the user can send it from Outlook."
}

Every output on every event is optional, and leaving one empty means "carry on with the default", so the allow branch can simply return nothing at all. The reason text is not a log message: it goes back to the model, which uses it to decide what to tell the user, so write it as an instruction the agent can act on. That is the difference between a refusal that dead-ends the conversation and one that offers the user a way forward.

The audit workflow needs nothing back. Its interesting part is the mapping into the row it writes:

Audit row column   <-  hook input
-----------------      ----------------------------
Timestamp          <-  timestamp
Agent              <-  metadata.agentName
User (Entra ID)    <-  metadata.userAadObjectId
Channel            <-  metadata.channel
Conversation       <-  metadata.conversationId
Tool               <-  toolName
Arguments          <-  parameters

Use userAadObjectId rather than userId to identify the person: userId is the user's ID in the channel they are chatting on, such as Teams, while the object ID is their Entra identity. The docs also warn that every metadata field can be empty, and the user fields always are when nobody is signed in, so give the audit row a fallback value instead of letting the write fail. A failed audit hook does not stop the agent, which is exactly the situation you don't want to discover from a gap in the table.

Steps to recreate

The paths below come from the hooks article and from Add a workflow to your agent as a tool (GitHub Copilot) (preview). You will need an agent created in the new agents experience and powered by the GitHub Copilot harness.

1) Open your agent in Copilot Studio. On the Build tab, in the components panel, select Tools and add the Office 365 Outlook Send an email action, so the agent has a tool to guard.

2) On the top menu bar, select the three dots (...), and then select Hooks. Hooks live on the agent's command bar, not on the Build tab, which is the first thing you'll go looking for.

3) In the Hooks dialog, select Create. On the Add hook page, set Event type to Pre tool use, accept or change the suggested Name, and in Tools select only the email action.

4) Select New workflow. The designer opens with a starter workflow that already has a When an agent calls the flow node carrying the event's inputs and a Respond to the agent node carrying its outputs. Do not rename those fields: Copilot Studio uses the names to decide whether a workflow fits the event, and a renamed field drops the workflow from the list.

5) Add a condition between the two nodes that inspects parameters for the recipients, and set the two outputs shown above on the deny branch. The article does not document the internal shape of parameters for a given tool, so run the agent once against an internal address first and read the workflow's run to see exactly what arrives before you write the condition.

6) Select the Save icon, then Publish. A saved but unpublished workflow does not run. You return to Add hook with the new workflow selected; select Done.

7) Repeat steps 2 to 6 for a Post tool use hook with Tools left empty (all tools), whose workflow writes the audit row to a Dataverse table or a SharePoint list.

8) Select the Save icon on the agent's top menu bar. Selecting Done only adds the hook to the draft; it is not stored until the agent is saved, and it does not run for users until you publish the agent.

9) Test with three prompts (the exact wording and expected outcomes are in the repo's test plan): an email to a colleague (allowed, audited), an email to an external address (denied, with the agent offering an alternative), and an attempt to argue the agent out of the refusal. The third one is the real test of whether your reason text was written for the model.

Keep the workflows quick. The hooks article says a hook that times out is treated as though it returned nothing, but it doesn't give the timeout itself; the documented limit for a workflow used as an agent tool is 100 seconds, so design well under that. A hook that times out is a hook that silently didn't run.

Companion repo

Workflows themselves live in the environment, so agent-hooks-lab on GitHub is the specification and test harness around them. The README.md condenses the event reference into one table, the contracts folder holds the input and output field names for each of the six events as JSON (the single most useful thing to have open while building), the payloads folder has the deny response and the audit mapping from above, and tests/test-plan.md has the three prompts with their expected outcomes and what each kind of failure tells you.

What it does not have yet is an exported solution with the agent and both workflows. That goes in once it has been built and run in a real environment, not before.

Final Notes

What I find most encouraging about hooks is that they move a category of requirement out of the prompt and into something you can point at. "Always log", "never email outside the company", "always know the user's region before answering" were, until the end of September, instructions you asked a model to follow. Now they are workflows bound to events, visible in a list, editable, and testable.

Just don't let "runs every time" turn into "cannot be bypassed" in anybody's slide deck. A hook is a strong, consistent nudge on the agent's path, and it fails open by design. Treat it as the layer that makes the agent behave well, keep the hard controls where they have always been, and you'll get the best of both!

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Power Apps | The Page That Reports Itself

2026-10-13T08:00:00.000-04:00

A generative page is React code that an agent wrote on your behalf. Which means that the first time one fails in front of a user, somebody is going to be debugging code they did not write, from a bug report that says "the page is blank", with no telemetry of any kind to go on. That was the situation until the end of September, when the generative pages documentation picked up a new section that changes it: published generative pages now send their own page loads, crashes and data calls to Azure Application Insights, and neither you nor the agent has to write a single line of telemetry code to make that happen.

That's right! No SDK, no connection string, no trackException() sprinkled through generated code that the next prompt will happily rewrite anyway.

Background

The change landed on September 28, 2026 in two articles at once: Generate a page using natural language, which covers the in-browser experience, and Create and edit generative pages with AI code generation tools, which covers building pages from GitHub Copilot CLI and similar tools. Both gained a section titled Monitor a generative page with Application Insights (preview), and the second one is explicit that it works the same whether the page came out of the maker portal or out of a coding agent on your laptop.

For those new to the term, a generative page is a model-driven app page you describe in plain English and an agent produces as React and TypeScript, talking to Dataverse through an object called dataApi. Application Insights is the Azure Monitor service that stores telemetry in fixed tables you query with Kusto Query Language (KQL).

The new telemetry maps onto those standard tables as follows:

pageViews: completed page loads, with the page ID, page name, app, host type, load duration and navigation origin. Navigation started from a generative page also lands here, with source and target page information.
exceptions: unhandled page-rendering errors and unhandled promise rejections attributed to the page.
dependencies: the duration and result of supported dataApi operations, meaning create, update, delete, retrieve and query.

This is the third time I have written about Application Insights on this blog, and the three posts make a neat little timeline. Back in August 2021 I covered monitoring canvas apps with Application Insights, where the maker pastes an instrumentation key into the app and calls Trace() by hand. On August 24th of this year I covered cloud flow telemetry down to the action level, which is a platform export configured by an administrator. Generative pages take the second road, not the first. That's always a good thing, and here is why.

Why it matters

For makers. You get a straight answer to "is my page working for people?" without learning anything about instrumentation. The catch is that you probably cannot turn it on yourself: the export is configured in the Power Platform admin center by an administrator, and it is supported for Managed Environments only. In a plain developer environment there is nothing to switch on, and you'll need a conversation with whoever runs your tenant.

For professional developers. The interesting part is the dependencies table. Every dataApi call the agent generated is timed and recorded with its result, so "which query is slow" stops being a guess. And because the platform does the instrumenting rather than the page, it survives regeneration. If you have ever added logging to generated code and watched the next prompt remove it, you'll appreciate that more than anything else here.

NOTE: this is a preview, and the docs say availability might vary by environment while it rolls out. The platform's delivery commitment for exported telemetry is 24 hours, so an empty table on the first afternoon is not a failure.

The demo

The demo is small on purpose: one generative page, one Application Insights resource, one deliberately broken button, and four queries. The broken button is what makes it convincing, because a page that works only proves that page loads are recorded. To prove crashes are, you have to crash it.

Once the page is generated, open the Code tab, select Edit, and add a button whose click handler throws inside an async function:

<button
  type="button"
  onClick={async () => {
    // Deliberate failure for the telemetry demo. Remove before sharing the page.
    throw new Error("Telemetry smoke test: unhandled promise rejection");
  }}
>
  Break me
</button>

Because the handler is async, the thrown error does not surface as an ordinary exception: it becomes a rejected promise that nothing catches, which is precisely one of the two error classes the docs say are recorded. I used a plain HTML button rather than whatever component library the agent picked so it pastes cleanly into any generated page. Change the message text to something you can search for, and select Save to commit the edit as a new iteration.

Steps to recreate

The admin center path below comes straight from Export data to Application Insights, and the page steps from the generative pages article. Be sure to read the prerequisites first, because each one can stop you cold:

1) In the Azure portal, create an Application Insights resource dedicated to this environment. The docs warn that the out-of-the-box reports misbehave if one resource receives data from several environments, and that the integration requires local authentication to remain enabled on the resource. Make sure you hold Contributor or Owner on it.

2) Confirm that the Power Platform environment is a Managed Environment, and that you hold Power Platform administrator or Dynamics 365 administrator at the tenant level and System Administrator in the environment itself. Both are required.

3) Go to the Power Platform admin center > Manage > Data export > App Insights tab > New data export.

4) Enter a friendly name and pick the data type. Here is a gap worth knowing about: the generative pages articles do not say which data type carries their telemetry. The documented choices include Dataverse diagnostics and performance, Power Automate and Copilot Studio, and model-driven app telemetry is documented under the Dataverse diagnostics feed, so that is the one I would select. Treat that as my inference until the docs say so.

5) Choose your filters and the source environment, select Next, choose the subscription, resource group and Application Insights resource, select Next, then Create.

6) Go to make.powerapps.com, open a model-driven app for editing, and in the app designer select Add page > Generative page > Describe a page. The in-browser experience requires an environment in the United States, Great Britain, Australia or Singapore; elsewhere, use the AI code generation tools route instead.

7) Describe the page (the companion repo has an example prompt if you would rather not write one), select Add data > Add table to link a Dataverse table (Account is fine), then select Generate page. Add the broken button from the previous section on the Code tab.

8) Select Save and Publish. Only published pages send telemetry, so a page you have only previewed in the designer will stay silent.

9) Open the app as a normal user, load the page several times, page through some records, and click Break me twice. Then wait, up to a day the first time.

The queries

Start by looking at what actually arrives, before writing anything clever. The documentation names the information each row carries but not the column or customDimensions key each value lives in, so the first query is reconnaissance:

union pageViews, exceptions, dependencies
| where timestamp > ago(2d)
| where cloud_RoleInstance == "CDS Data Export"
| project timestamp, itemType, name, duration, success, operation_Id, session_Id, customDimensions
| order by timestamp desc
| take 50

The cloud_RoleInstance filter is the documented marker for rows written by the Power Platform export, which keeps anything else your resource collects out of the picture. Read the customDimensions column carefully on a few pageViews rows: that is where you will learn the actual key names for page ID and page name, and you will need them for anything you build on top. If the filter returns nothing while the unfiltered version returns your page, drop it and note the value you see instead.

Next, page load performance per page:

pageViews
| where timestamp > ago(7d)
| where cloud_RoleInstance == "CDS Data Export"
| summarize loads = count(), p50 = percentile(duration, 50), p95 = percentile(duration, 95) by name
| order by p95 desc

This groups by the standard name column. If the reconnaissance query showed the page name living in customDimensions instead, replace by name with by pageName = tostring(customDimensions["<key you found>"]). The 95th percentile is the number to watch, since an average hides the users who are having the worst time.

Then, the crash you caused on purpose:

exceptions
| where timestamp > ago(7d)
| where cloud_RoleInstance == "CDS Data Export"
| summarize occurrences = count(), users = dcount(user_Id), lastSeen = max(timestamp) by problemId, outerMessage
| order by occurrences desc

Your "Telemetry smoke test" message should show up in outerMessage with two occurrences. The users column is the one that turns a crash list into a priority list: one user hitting something forty times is a very different conversation from forty users hitting it once. Wire this query to an Azure Monitor alert rule and you have crash notification for code nobody on your team wrote.

Finally, the data calls:

dependencies
| where timestamp > ago(7d)
| where cloud_RoleInstance == "CDS Data Export"
| summarize calls = count(), failed = countif(tobool(success) == false), p95 = percentile(duration, 95) by type, name
| order by p95 desc

Run this before filtering on type. The docs do not list the type value used for dataApi operations, and Dataverse's own server-side calls also land in dependencies, so let the first run tell you which value belongs to your page, then add a where type == "..." line. The tobool() is not decoration: the classic dependencies table documents success as a string, and only the workspace version of the table (AppDependencies) makes it a true bool, so a bare success == false would compare two different types. A retrieve that is consistently slow at the 95th percentile is usually a query asking for every column of a large table, which is something you can fix with one more sentence in your next prompt.

Companion repo

Everything in this post is packaged in genpage-telemetry-lab on GitHub. The README.md carries the prerequisites and the admin center path from above, the queries folder holds the four KQL files numbered in the order you should run them (reconnaissance first), and the page folder holds an example generation prompt and the broken-button snippet, ready to paste.

One thing the README covers that is worth repeating here: these queries use the classic Application Insights table names, so run them from Logs on the Application Insights resource itself. Query the underlying Log Analytics workspace instead and the same data lives in AppPageViews, AppExceptions and AppDependencies, under different column names. An Azure Monitor workbook charting the three tables side by side is the natural next addition, and it goes into the repo once the real column names are confirmed against live data, not before.

Final Notes

What I like most about this change is where it put the responsibility. When an agent writes the code, any telemetry inside that code is only as durable as the next prompt. Instrumentation in the platform, configured once and applied to every published page, is the only arrangement that holds up when the page is regenerated every week, and in my humble view it is the right precedent for whatever else gets generated on this platform.

It is a preview with honest gaps in the documentation, chiefly which export data type to pick and which column holds the page name. The reconnaissance query is there so you close those gaps with your own data rather than with assumptions. Then go break a button on purpose. It is the cheapest proof you'll get that the crash reporting works!

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Power Automate | Flows Without the Designer

2026-10-08T07:00:00.000-04:00

Back on September 4th I wrote about the model app builder, the Power Platform plugin that stands up a model-driven app from a description instead of from four hours of clicking. I said at the time that the interesting thing was not the app builder itself but the delivery mechanism sitting underneath it, and that there were other plugins in the same marketplace worth looking at. Well, here we are.

The article is Get started with the Power Automate plugin for GitHub Copilot CLI and Claude Code, dated 2026-09-16 in the Power Automate documentation. Same marketplace, different plugin, and this one goes after cloud flows: create, edit, run, debug and manage, all from a terminal.

Which is where I owe you a pointer, because this is not my first look at it. Back on August 13 I wrote about building flows with Claude Code and FlowAgent, and FlowAgent is the MCP server that ships inside this very plugin. I wrote about it under the server's name rather than the plugin's, which is partly why the two do not obviously look like the same thing.

That piece ended on a list of rough edges, and one of them is now closed: the resubmit and diagnose tools both threw type errors at the time, and I worked around them by calling the Power Automate REST API directly. That fix shipped in v3.0.4 on August 25. So if you read that article and have been resubmitting runs the long way ever since, you can stop. The plugin is several releases on from the one in that post, and what follows is what changed and what I still could not make work.

Now, I did not want to write this one from the page. Anybody can summarize a doc. So I installed it, pointed it at a throwaway Developer environment, and tried to build something. What follows is what actually happened, which turned out to be considerably more interesting than the happy path.

Background

First, a distinction the documentation assumes you already have. Power Platform Skills is a marketplace, not a plugin. It lives at microsoft/power-platform-skills and it currently carries eight of them: power-pages, model-apps, mcp-apps, canvas-apps, code-apps-preview, mobile-app, power-apps-mobile-extension and power-automate. The marketplace is the delivery channel. The plugin is the thing delivered, which is why the install line reads power-automate@power-platform-skills.

I covered the installer and the Azure CLI sign-in in that earlier post, so I am not going to repeat any of it here. What is new is the surface: ten skills, each available as a slash command or just described conversationally.

/setup checks Node, the Azure CLI, Power Automate access and connectivity
/browse-flows browses environments and flows, and helps you pick one
/create-flow and /build-flow create a flow, guided or from a description
/debug-flow and /diagnose-flow inspect a failed run and chase root causes
/manage-flows handles publishing, testing, batch operations and inventory reports
/manage-desktop-flows lists and runs desktop flows and machine groups
/route-environments explains how your default environment is resolved
/report-issue collects the details and files a public GitHub issue

The plugin ships its own Power Automate MCP server, so there is no separate npm package and no remote MCP host to configure. It also bundles the Microsoft Learn MCP server as a companion knowledge source, which means the agent can go and read the official guidance on child flows or expressions while it is working on yours. That second detail is easy to skim past and it is genuinely clever.

Why It Matters

If you are a maker, the honest answer is: not yet, and that is fine. This is a terminal tool that assumes an Azure CLI session and a comfort with JSON flow definitions. The designer is not going anywhere.

If you are a professional developer, this is the piece that has been missing. Flows have always been the part of a solution you could not sensibly review, diff or automate, because the authoring surface was a canvas in a browser. A tool that reads and writes flow definitions from a terminal, under your own identity and your tenant's policies, is a different proposition entirely. Be sure to notice that last part: the plugin calls Power Automate as you, so your licensing, your connector policies and your DLP rules all still apply. Nothing here is a way around governance.

Before You Build

Start with /setup, or the underlying doctor check, and actually read the output. Here is mine, lightly redacted, after I signed in to a different tenant:

az-login          pass  Signed in as me@example.com (tenant 1111....)
token             pass  Acquired a token for https://service.flow.microsoft.com (tenant 2222....)
identity-match    FAIL  Identity mismatch: az is signed in to tenant 1111....
                        but the token FlowAgent would send belongs to tenant 2222....
                        This is what surfaces as EnvironmentAccessDenied.
                  fix   Call the reconnect tool (clears the token cache and re-acquires).
environment-access pass  Listed 36 environments.

This one nearly caught me out. The Azure CLI was signed in to the new tenant and the plugin was still holding a cached token for the old one, and notice that environment-access still reported pass: it cheerfully listed 36 environments belonging to the tenant I thought I had left. Had I skipped the check, I would have been operating against the wrong tenant entirely while believing otherwise. The reconnect tool clears the cache and re-acquires, and after that the same call listed two environments, which was the correct answer. Running that check first is not ceremony. It is the difference between working where you think you are and working somewhere else.

NOTE: there is a second, sharper edge in the same area. The plugin keeps a current working environment, and passing a one-off env argument to any call silently makes that the new session default, overriding what you set deliberately. Worse, the remembered display name does not follow, so afterwards the tool reported displayName: Workbench against a completely different environment's id. I reproduced it on purpose to be sure. The practical defence is simple: pass the environment explicitly on anything that writes, and never trust the session default for a create or an update.

Building It

My test case was deliberately dull: a button-triggered flow that takes an order id and an amount, compares the amount against an approval threshold, and composes one of two decisions. No connectors at all, so nothing needed an interactive consent.

The sequence that matters is validate, then preflight, then create:

validate_flow   -> valid: false
  premium-trigger-warning: HTTP Request triggers require a Premium license.
  Use "Button" kind for free/seeded plans.       [triggers.manual.kind]

validate_flow   -> valid: true                   (after switching to Button)

preflight_flow  -> overall: ready
  validation: valid, 0 errors, 0 warnings
  connectionRefs: []
  solutionWrap: not detected
  summary: "Ready to save + publish"

create_flow     -> name: 8b4caf55-....  state: Stopped  created: 03:30:53Z

The first thing here is a genuine win. My original definition used an HTTP Request trigger, and validate_flow rejected it before anything existed, on licensing grounds, naming the exact property at fault. That is a class of problem that normally surfaces much later and much more expensively. Then preflight_flow goes further: it checks connection references and whether a solution wrap is going to block publishing, which are the two things that most often turn a save into a bad afternoon. And when I read the created flow back, the stored definition matched what I sent exactly, with only the key order rearranged. Nothing was silently rewritten, which is precisely what you want from a tool that edits your work.

When It Breaks

Now, the part I did not expect. The flow was created in a Stopped state, which is by design and sensible. Starting it from the terminal did not work:

publish_flow -> success: false, alreadyStarted: true, actualState: "Stopped"
   warning: "It may have an unauthenticated or missing connection. Check
             list_connections and ensure all connection references are in
             Connected status before publishing."

run_flow     -> 404 tokenexchange
   "The connection (.../logicflows/8b4caf55-....) is not found. Please create
    new connection and change your application to use the new connection."

A few things to note. That first response contradicts itself: success: false alongside alreadyStarted: true alongside an actual state of Stopped. And the warning sends you to check connection references on a flow that has none, which preflight_flow had confirmed minutes earlier with connectionRefs: []. The token exchange failure downstream is the honest signal: it is looking for a trigger registration that was never provisioned, because the flow never actually started. I turned the flow on by hand in the maker portal, which worked immediately, and that is worth knowing too: the flow came back with a different id. Any script holding the id that create_flow handed you is now pointing at nothing.

With the flow running, it ran. And failed. Here is where the tooling earns its keep:

run_flow         -> status: Failed, errorCode: ActionFailed
   Approval_threshold  Succeeded   1ms
   Check_amount        Failed      3ms   InvalidTemplate
   Needs_review        Skipped           ActionDependencyFailed
   Auto_approved       Skipped           ActionDependencyFailed

get_run_actions  -> Check_amount
   "Unable to process template language expressions for action 'Check_amount':
    The template language expression 'triggerBody()['number']' cannot be
    evaluated because property 'number' cannot be selected."

This is the strongest part of the whole plugin. It did not tell me the flow failed. It told me which action failed, which expression inside that action could not be evaluated, and which property could not be selected, with the two downstream actions correctly marked as skipped rather than failed. Then get_past_trigger_inputs, the same primitive the designer uses for "test with previous run data", showed me the trigger envelope carried the schema but not my values. So the body I passed never reached triggerBody() at all. Chasing that to the end: switching the trigger to the Power Apps V2 kind and retrying produced a refusal that I want to quote, because it is an unusually good error message.

It explained that trigger inputs for that kind are delivered through the Logic Flows connector runtime, that the refusal is a per-flow authorization condition rather than a limit of the trigger kind, that the same kind runs fine on a flow you own, and that I could either run it from the app that owns it or resubmit a past run that already carried inputs. That is a message written by somebody who has actually watched people get stuck on this. Slick.

What Worked and What Did Not

Being concrete, because a post that says "it is promising" helps nobody:

Worked well: the connectivity and identity checks, the pre-creation validation, the preflight, creating the flow, updating it in place, stopping it, and above all the run-level diagnosis, which is more precise than what I get from the portal.
Did not work: starting a freshly created flow from the terminal, and passing trigger inputs into a run headlessly.
Worth knowing: the session environment default can be changed out from under you, and turning an API-created flow on by hand can change its id.

So the shape of it is this. Building a flow from the terminal works. Getting data into one from the terminal is where the seam still shows. That is a preview finding, not a verdict, and the limitations section of the article is upfront that features change as the marketplace updates. If you hit these too, /report-issue is right there and it files against the public repository, which is a considerably better feedback loop than most preview tooling offers.

The companion repo

Sketching it out, a flows-from-the-terminal-lab would carry the flow definition JSON for both the working and the deliberately broken version, a small script that validates a definition before you ever call create, and a README recording which operations need the portal today. The flow definition is the artifact here, and the fact that it is now a file you can diff and review is most of the point.

Final Notes

Two closing thoughts.

The first is that the failures above are the reason I bothered. Had everything worked, this would have been a nicer read and a much less useful one. The tool is in preview, it says so, and the things that broke are exactly the things you would want a colleague to warn you about before you spent an afternoon on them.

The second is the one I keep coming back to. Eight plugins in that marketplace and I have now looked at two. Flows, model-driven apps, canvas apps, code apps, Power Pages, and an MCP one I am particularly curious about. Whatever you make of any individual plugin, the pattern underneath is the story: the Power Platform is growing a terminal-shaped surface, under your own identity, governed by your own tenant's rules. For those of us who have spent years explaining why the good stuff was locked behind a canvas, that is a genuinely interesting direction.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Copilot Studio | Your MCP Server Now Needs a Key Vault

2026-10-05T07:00:00.000-04:00

If you have an MCP server manifest sitting on your disk right now, there is a good chance it is already out of date. And you have until October 31, 2026 to do something about it.

On September 26 the Microsoft MCP server certification overview (preview) grew by a few hundred characters. Carried in that small diff: a schema version bump off the preview schema, a hard close date on the submission path you already know, and a new requirement that obliges you to stand up Azure infrastructure before you can submit anything at all. Quite a lot of consequence for a small diff!

Background

First, the vocabulary. The Model Context Protocol, almost always written MCP, is an open protocol for exposing tools and actions to an AI agent, so the agent can call your service without anyone hand building a one-off integration. An MCP server is the thing on your side that speaks it, and certification is the review Microsoft runs before yours becomes broadly discoverable.

Now, the core of the process did not change, and the article is careful to say so: verified publishers submit a package, Microsoft validates it and gets issues remediated before approval, and publishers remain responsible for the certified experience afterward. What changed is nearly everything around that core:

The manifest example moved off the preview schema. It was vDevPreview with "manifestVersion": "devPreview". It is now the v1.30 Teams schema with a plain "version": "1.30".
Submissions go through the Partner Center offer type Apps and Agents for M365 and Copilot, and the legacy path stays open only through October 31, 2026. The article blames high submission volume during preview, and warns the new path might be slower.
Every submission now requires a manifest file, a tool file, an intro file and an Azure Key Vault authentication configuration. That last one is the requirement with real setup work behind it.
The list of publishing surfaces grew from Azure Foundry and Copilot Studio to Azure Foundry, Cowork, Copilot chat and Copilot Studio.
A new FAQ entry states plainly that Dynamic Client Registration is not supported today.
If you already ship an M365 Agent containing an MCP server, you do not submit it separately. Those become standalone MCP servers automatically later this year.

NOTE: most of the byte count in that edit is prose being reflowed into bullet lists, which is exactly why a change like this is easy to skim past. The schema version and the Key Vault requirement were sitting in the middle of what looked like a formatting pass.

The Problem

Two problems, really, on different clocks. The first is the manifest on your disk right now: if you built against the preview schema, it declares manifestVersion and points at a vDevPreview URL, and the documented example no longer resembles it. The second is the Key Vault requirement, which is not a field you fill in. It is an Azure resource, precisely named secrets, a Microsoft service principal and a role assignment, all of which must exist before validation can retrieve your OAuth configuration.

Here is the manifest skeleton as the article now documents it, trimmed to the parts that carry the change:

{
  "$schema": "https://developer.microsoft.com/json-schemas/teams/v1.30/MicrosoftTeams.schema.json",
  "version": "1.30",
  "id": "<APP_ID>",
  "agentConnectors": [
    {
      "id": "<CONNECTOR_ID>",
      "displayName": "<CONNECTOR_DISPLAY_NAME>",
      "toolSource": {
        "remoteMcpServer": {
          "mcpServerUrl": "<MCP_SERVER_URL>",
          "mcpToolDescription": { "file": "mcptools.json" },
          "authorization": {
            "type": "AzureKeyVault",
            "referenceId": "https://contoso-mcp-kv.vault.azure.net/"
          }
        }
      }
    }
  ],
  "icons": { "outline": "Outline.png", "color": "Color.png" }
}

The server is declared under agentConnectors, with toolSource.remoteMcpServer holding the endpoint, so a certified MCP server is modeled as a connector rather than its own top level object. Your tool schemas sit in the separate file named by mcpToolDescription.file, here mcptools.json. And look closely at referenceId: the article says twice that this must be the Key Vault URI and not a secret URI, which tells you how often it arrives wrong. One more that bites quietly, Microsoft supports ASCII header names and values only in the manifest and tool files.

Why It Matters

If you are a maker, the effect is about what you can expect to find and trust. Certification decides which MCP servers appear as vetted options, and the surface list growing to include Cowork and Copilot chat means a server certified once becomes discoverable in more places without further work by its publisher. You are not submitting anything, but you are the beneficiary of the review.

If you are a professional developer, this is a work item with a date attached. The new path is the one to target, October 31 is when the old one closes, and the Key Vault configuration touches your Azure subscription and somebody else's change process. Read the eligibility rules first: you must be a verified publisher whose Partner Center account has completed business verification, be enrolled in the Microsoft 365 and Copilot program, and own or control the endpoint you submit.

Implementation

The article documents the Key Vault setup as a portal exercise. It is also the part most likely to go wrong, so I am going to give you the whole Azure side as a script first, and then walk the steps behind it:

1) Create an Azure Key Vault in your Azure tenant. The documentation specifies the Azure portal, so what follows is my Az PowerShell equivalent of steps 1 through 3, which you can run end to end:

# Install-Module Az -Scope CurrentUser   # if you do not already have it
Connect-AzAccount

$subscription = '<SUBSCRIPTION_ID>'
$resourceGroup = 'rg-mcp-cert'
$location = 'eastus'
$vaultName = 'contoso-mcp-kv'                             # must be globally unique
$certServiceAppId = '8e91e74f-afe9-41cd-8c3f-17a9562a74ea'  # Microsoft's certification service

Set-AzContext -Subscription $subscription | Out-Null

# Step 1: the vault itself. On Az 12.0.0 and later, RBAC authorization is the default
New-AzResourceGroup -Name $resourceGroup -Location $location -Force | Out-Null
$vault = New-AzKeyVault -Name $vaultName `
                        -ResourceGroupName $resourceGroup `
                        -Location $location

# Step 2: the secrets. These names are case sensitive and must match exactly
$secrets = [ordered]@{
    ClientId     = '<CLIENT_ID>'
    ClientSecret = '<CLIENT_SECRET>'
    TokenUrl     = 'https://login.example.com/oauth2/token'
    # AuthorizationUrl               = '...'   # required for an OAuth2 provider
    # RefreshUrl                     = '...'   # when you issue refresh tokens
    # Scopes                         = '...'   # when your provider needs scopes
    # AzureActiveDirectoryResourceId = '...'   # required for an Azure AD provider
}

foreach ($name in $secrets.Keys) {
    $secure = ConvertTo-SecureString $secrets[$name] -AsPlainText -Force
    Set-AzKeyVaultSecret -VaultName $vaultName -Name $name -SecretValue $secure | Out-Null
    Write-Host "stored $name"
}

# Step 3: Microsoft's service principal, then read access to the vault
$sp = Get-AzADServicePrincipal -ApplicationId $certServiceAppId -ErrorAction SilentlyContinue
if (-not $sp) { $sp = New-AzADServicePrincipal -ApplicationId $certServiceAppId }

New-AzRoleAssignment -ObjectId $sp.Id `
                     -RoleDefinitionName 'Key Vault Secrets User' `
                     -Scope $vault.ResourceId

# Step 4: this is the value that goes into the manifest
Write-Host "authorization.referenceId = $($vault.VaultUri)"

Two of these will cost you a submission cycle. The first is what is not in that New-AzKeyVault call. The article grants access with an RBAC role, and an RBAC role assignment does nothing on a vault running legacy access policies, so you may reach for -EnableRbacAuthorization. Do not: it was removed in Az 12.0.0, replaced by -DisableRbacAuthorization, and RBAC is now the default, which is why the call omits it. See the Az 12.0.0 migration guide. The trap that survives is reusing an existing vault built the old way, where the role assignment looks like it succeeded and grants nothing. Fix that with Update-AzKeyVault -DisableRbacAuthorization $false.

The second is that those secret names are the literal keys of the hash table on purpose: the article devotes a whole FAQ entry to confirming secret names are case sensitive and should match exactly, and ClientId is not clientid. Note too that New-AzADServicePrincipal is not creating an application of yours, it is instantiating Microsoft's in your tenant so the role assignment has something to bind to. And the last line prints $vault.VaultUri, exactly what the manifest wants for referenceId.

2) Store the required secrets in the vault: ClientId, ClientSecret and TokenUrl. Then add the optional ones your identity provider needs. AuthorizationUrl is required for an OAuth2 provider, AzureActiveDirectoryResourceId is required for an Azure AD provider, and RefreshUrl and Scopes come into play for refresh tokens and scoped access respectively.

3) Create a service principal for the Microsoft application 8e91e74f-afe9-41cd-8c3f-17a9562a74ea, and grant it Key Vault Secrets User, or an equivalent RBAC read role, on the vault. This is what lets the certification service retrieve your OAuth configuration during validation.

4) Add the vault URI to the manifest as authorization.referenceId, exactly as shown above.

5) Go to Partner Center and proceed to create a new offer, selecting the offer type Apps and Agents for M365 and Copilot. Upload the package and supply the required commercial, legal, support and publisher information.

6) Let automated validation run against package structure, required fields, schema correctness and metadata completeness. Blocking issues must be fixed before the functional and safety review continues. Including evaluation evidence, meaning representative functional and safety test results, can help accelerate that review.

The demo, and a companion repo

So I built one, and you can clone it: github.com/dgpblogster/mcp-cert-lab. Very nearly every requirement on that page is mechanically verifiable before you ever open Partner Center, which makes a readiness checker the obvious companion piece: one PowerShell script that takes a package folder, and optionally looks at the vault behind it.

Laying it out the way I laid out project-orion-lab, the hands-on companion to my Same Agent, Two Architectures: When MCP Wins (And When It Doesn't) session at Community Summit NA 2026, which is to say a README that carries the prerequisites and one folder per moving part:

mcp-cert-lab/
  README.md                     what each check maps to in the article
  Test-McpCertReadiness.ps1     the checker
  samples/
    good-package/               passes cleanly
      manifest.json             v1.30, vault URI, every field populated
      mcptools.json             three tools, JSON Schema inputs
      intro.md                  with a Known issues and limitations section
      Color.png  Outline.png    192x192 and 32x32
    bad-package/                eight planted defects in one file
      manifest.json             devPreview schema, secret URI, a smart quote
  tests/
    Invoke-Tests.ps1            asserts good passes AND bad is caught, by name

On the shape of that. The checker runs with no Azure connection at all unless you pass -CheckVault, which is deliberate: most of what fails a submission fails on disk. It exits 0 when nothing failed and 1 when anything did, so it works as a pipeline gate. And bad-package is not filler, it is the instrument that proves the checker still works.

Pointed at the deliberately broken package, it reports:

FAIL   Schema     $schema points at v1.30  (still on the retired vDevPreview schema)
FAIL   Schema     manifestVersion removed  (replaced by version in the v1.30 shape)
FAIL   Schema     version is 1.30  (found: 1.0.0)
FAIL   Metadata   developer.termsOfUseUrl  (placeholder left in: <TERMS_OF_USE_URL>)
FAIL   Icons      color icon on disk  (Color.png not found)
FAIL   Connector  [contoso-shopfloor] tool file on disk  (mcptools.json not found)
FAIL   Connector  [contoso-shopfloor] referenceId is a vault URI  (this is a SECRET URI, use the vault URI)
FAIL   Ascii      manifest.json ASCII only  (U+2019 at line 18 col 55)

16 passed, 9 failed, 1 warnings
Not ready to submit.

That last line is the one I care about most. U+2019 at line 18 col 55 is a curly apostrophe, the kind that arrives when somebody pastes a company name out of an email, and the article is explicit that non-ASCII characters might cause validation failures. It is invisible in every editor you are likely to be using. Finding it by line and column in half a second, rather than by elimination after a rejected submission, is the whole argument for writing the thing.

Two places where I deliberately stopped short, because a checker that overreaches is one people turn off. Icon dimensions are reported, not asserted, since the exact sizes live in Teams guidance outside this article. And the intro file is a warning rather than a failure, for the reason in the Final Notes below. Everything else is a hard pass or fail, including the vault checks, where secret names are compared case sensitively.

Final Notes

Three closing thoughts.

First, this is preview documentation and says so at the top, so the schema version, the package requirements and the surface list are all fair game to change again before general availability. The one item with a fixed date is the October 31, 2026 close of the legacy path, and that is what I would plan around.

Second, a small inconsistency worth knowing about rather than tripping over. The What's changing table states that all submissions require a manifest file, tool file, intro.md file and Key Vault configuration, while a section further down the same page is headed Intro file (Optional). The two disagree. The safe course is to include the intro file, which you want anyway, with a Known issues and limitations section in it.

Finally, the observation I keep coming back to. Read that list of publishing surfaces once more: Azure Foundry, Cowork, Copilot chat, Copilot Studio. One certification, four destinations, with Microsoft 365 admin governance applying across them where relevant. That is the real story hiding inside a small diff. Certifying an MCP server is drifting away from being a Copilot Studio errand and toward being how a tool gets admitted to the Microsoft agent ecosystem generally, and the entry fee is a manifest, a vault and a review.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Power Apps | Rows Without an Owner

2026-10-02T07:00:00.000-04:00

If you have spent any real time modeling security in Dataverse, you have had this conversation. A customer wants "this group of people should only see the rows for their region", and you reach for the tools you have: business units, teams, hierarchy security, sharing, maybe an owning team per region and a great deal of patient explaining about why the org chart and the data model now have to agree with each other forever. It works. It has worked for the better part of two decades. But you have also had the other half of that conversation, the one where the customer says "but the region is just a column on the record", and you have to explain why a column cannot grant access, and why the answer involves restructuring their business units.

Well, in late September a new article appeared in the Power Apps developer documentation, dated September 23, 2026, and it describes a genuinely new answer to that conversation. It is called filtered record ownership, and the short version is this: a table whose rows have no owner at all, where access is decided by a FetchXML predicate evaluated against the row's own column values.

That is a new ownership type in Dataverse. Those do not come along very often.

Background

The new page is Filtered record ownership by using code (preview), roughly 400 lines covering the SDK for .NET and the Web API. It is the developer half of a pair. The maker half, Filtered record ownership, covers the same ground through the Power Apps portal, and the developer article is careful to point you there first. Its opening is refreshingly blunt about it: you do not need to write code to use this feature.

NOTE: everything below is preview. The record ownership dropdown in the maker portal literally reads Filtered (preview), and the developer article carries the preview banner.

The model, in three objects

The design is clean once you see the pieces, and it is worth laying out before any code.

First, the table. You create it with its OwnershipType set to a new member, Filtered, which has the value 32. Rows in such a table have no owner. They cannot be assigned and they cannot be shared. And you cannot change the ownership type after the table is created, so this is a decision you make once, at design time, and live with.

Second, the record filter, stored in a new recordfilter table. It holds a display name, a unique name, and a FetchXML query that defines which rows it selects. The FetchXML root entity must match the table you eventually associate it with.

Third, the entity record filter, stored in a new entityrecordfilter table, which associates a record filter with a Dataverse table. A table can have several, so "City equals Redmond" and "City in Kirkland or Sammamish" can coexist as separate, independently activated predicates against the same table.

A security role then grants a filter for one or more of the Create, Read, Write, Delete, Append and Append to privileges, and you assign the role to users or teams. So, the whole chain in one sentence: a FetchXML predicate becomes a named filter, the filter is attached to a table, and a security role hands that filter to people for specific operations.

Access is cumulative. The documentation puts it precisely: access is the union of the filters granted through all security roles assigned to the user or their teams. Grant somebody the Redmond filter through one role and the Kirkland filter through another, and they see both cities. Nobody is subtracting anything, so when a user sees more than you expected, the answer is almost always a second role you forgot about.

Creating the table in code

Here is the table creation, the piece that makes it a filtered table at all:

var createTableRequest = new CreateEntityRequest
{
    SolutionUniqueName = "<Solution Unique Name>",
    Entity = new EntityMetadata
    {
        SchemaName = "new_Store",
        DisplayName = new Label("Store", 1033),
        DisplayCollectionName = new Label("Stores", 1033),
        Description = new Label("Stores organized by city.", 1033),
        OwnershipType = OwnershipTypes.Filtered,
        IsActivity = false
    },
    PrimaryAttribute = new StringAttributeMetadata
    {
        SchemaName = "new_Name",
        DisplayName = new Label("Name", 1033),
        RequiredLevel = new AttributeRequiredLevelManagedProperty(
            AttributeRequiredLevel.None),
        MaxLength = 100,
        FormatName = StringFormatName.Text
    }
};

service.Execute(createTableRequest);

A few things to note. The one line that matters is OwnershipType = OwnershipTypes.Filtered. Everything else is an ordinary custom table. The SolutionUniqueName is the optional parameter that associates the new component with an unmanaged solution as it is created, which you want, because every object in this feature is a solution component and you would rather not go hunting for them later. If you prefer the Web API, the same thing is a POST to EntityDefinitions with "OwnershipType": "Filtered" in the body and the solution carried in an MSCRM.SolutionUniqueName header.

Creating the filter

Next, the predicate itself, as a row in the new recordfilter table:

string fetchXml = """
    <fetch>
      <entity name="new_store">
        <filter type="and">
          <condition attribute="new_city" operator="eq" value="Redmond" />
        </filter>
      </entity>
    </fetch>
    """;

Entity recordFilter = new("recordfilter")
{
    ["displayname"] = "Stores in Redmond",
    ["uniquename"] = "new_storesinredmond",
    ["fetchxml"] = fetchXml
};

CreateRequest createRecordFilterRequest = new() { Target = recordFilter };
createRecordFilterRequest["SolutionUniqueName"] = "<Solution Unique Name>";

CreateResponse createRecordFilterResponse =
    (CreateResponse)service.Execute(createRecordFilterRequest);
Guid recordFilterId = createRecordFilterResponse.id;

Two things in there are deliberate. The FetchXML is stored as plain text on the row, and its root <entity> name must match the table this filter will be associated with. Notice also that this uses CreateRequest rather than the more convenient service.Create(entity), and that is deliberate: CreateRequest is what lets you set the SolutionUniqueName optional parameter. Give the filter a unique name with your publisher prefix, the same as any other component.

Then you associate the filter with the table:

Entity entityRecordFilter = new("entityrecordfilter")
{
    ["name"] = "Stores in Redmond",
    ["objecttypecode"] = "new_store",
    ["recordfilterid"] = new EntityReference("recordfilter", recordFilterId)
};

CreateRequest createEntityRecordFilterRequest = new() { Target = entityRecordFilter };
createEntityRecordFilterRequest["SolutionUniqueName"] = "<Solution Unique Name>";

service.Execute(createEntityRecordFilterRequest);

objecttypecode takes the table's logical name as a string, and recordfilterid is a lookup back to the filter you just created. In the Web API the same association is made with the RecordFilterId@odata.bind navigation property. This row is what activates the predicate for that table, which is why the maker documentation describes creating one as the step that turns a filter on.

Why it matters, for makers

The headline for a maker is that row-level security is now expressible as a condition on a column, in a dialog you already know how to use, and it never touches your business unit structure.

Better still, the maker path has a genuinely nice touch: you do not have to hand-write FetchXML. You open a model-driven app, open the table, use the Filters pane to build the condition visually, and then select Download FetchXML to get exactly the XML you need to paste into the record filter. Building the predicate with the same filter builder your users already use, then shipping it as a security rule, is a good piece of design and whoever thought of it deserves the credit.

The thing to be careful about is the one the documentation flags twice, and I will flag it a third time: test with a nonadministrator account. The system administrator role carries a system-provided All records filter, so an administrator sees everything and will never experience the restriction. Demo this as an admin and you will demo nothing at all.

Why it matters, for professional developers

Three things I would want on the table before recommending this to anyone.

The first is that the ownership type is immutable. Filtered is chosen at CreateEntityRequest time and cannot be changed afterward, which means this is not something you retrofit onto an existing table. It is a modeling decision, made up front, and the migration path from a user-owned or organization-owned table to a filtered one is "create a new table and move the data". Plan accordingly.

The second is that a surprising amount of the platform assumes an owner exists. Anything in your codebase or your process that reaches for ownerid, or calls AssignRequest, or grants access with GrantAccessRequest, simply has no counterpart here. That is the point of the design rather than a criticism, but it turns up during testing rather than during design if nobody says it out loud early.

The third is that this is now application lifecycle management surface area. Record filters and entity record filters are solution components, and the security roles that grant them are solution components too. Which means the predicate that decides who sees what is a versioned, deployable artifact that moves between environments with your solution. That is the part I find genuinely exciting, and I would even venture to say it is the more important half of this feature: your row-level security rules stop being environment configuration that somebody clicked together in production and start being something you can review in a pull request.

One operational note for your runbook: deleting a record filter also deletes its associated entity record filters. Review every role that grants a filter before you change or remove it, because pulling a predicate out from under a role is not a change you want to hear about from a user who suddenly cannot see anything.

The demo I would build

The demo writes itself, and it is the two-screenshot kind that makes a point in about four seconds.

Build a Store table with a City column and populate it with a dozen rows across Redmond, Kirkland and Sammamish. Create two record filters, one per city, and two security roles, each granting Read on one filter. Then sign in as two nonadministrator users with one role each, open the same view of the same table, and put the two screens side by side. Same app, same table, same view definition, two different sets of rows, no business unit involved anywhere.

Then, for the finale, assign the second role to the first user as well and refresh. The rows union together in front of the audience. That is the cumulative-access rule made visible, and it is the single behavior most likely to confuse somebody later, so it is worth burning into people's memory while you have their attention.

The companion repo

Which is no longer a sketch: it is at github.com/dgpblogster/filtered-ownership-lab, MIT, clone it or download the zip. The Web API calls are the part to trust first, since there is nothing between the request and the service. Laying it out:

filtered-ownership-lab/
  README.md                    what preview means here, and the admin-blindness warning
  solution/
    src/                       unpacked unmanaged solution: table, filters, roles
  src/
    FilteredOwnership.Setup/
      Program.cs               verbs: create-table | create-filter | associate | teardown
      TableBuilder.cs          CreateEntityRequest with OwnershipTypes.Filtered
      FilterBuilder.cs         recordfilter + entityrecordfilter, both via CreateRequest
  http/
    01-create-table.http       Web API equivalents, one file per step
    02-create-recordfilter.http
    03-associate.http
    04-inspect-filters.http    the $expand query that shows the live configuration
  data/
    stores.csv                 sample rows across three cities
  docs/
    cumulative-access.md       the union rule, with the two-role walkthrough

The http/ folder is there because seeing the raw request makes this model click in a way an SDK wrapper hides: "OwnershipType": "Filtered" in a JSON body is more memorable than an enum. 04-inspect-filters.http is the one people will reuse, because it answers "what filters are live on this table right now":

GET [Organization URI]/api/data/v9.2/entityrecordfilters?$select=name,objecttypecode,statecode&$filter=objecttypecode eq 'new_store' and statecode eq 0&$expand=RecordFilterId($select=displayname,uniquename,fetchxml) HTTP/1.1
Accept: application/json
OData-MaxVersion: 4.0
OData-Version: 4.0

The statecode eq 0 condition restricts the result to active associations, and the $expand on RecordFilterId pulls the actual FetchXML of each filter into the same response, so one call gives you the complete picture of what predicates are in force on a table. That is your first stop when a user reports seeing the wrong rows.

Steps to recreate

The maker path is the one to start with, and the maker article has the full click path. These are the steps that carry a decision:

1) Create the table inside a solution, and set Record ownership to Filtered (preview). This is the one you cannot take back later.

2) Build the predicate without writing XML. Open your model-driven app for editing, open the table, use the Filters pane to add a condition such as City equals Redmond, then select Download FetchXML.

3) Create a Record Filter in the solution and paste that FetchXML into it, with a unique name carrying your prefix.

4) Create an EntityRecordFilter pointing at that filter, with the table's logical name as the related entity. This is the row that turns the predicate on.

5) Grant the filter on a security role, Read being the one to start with, and assign the role to a user or team.

6) Sign in as a real nonadministrator account. Not your own: the system administrator role carries an All records filter, so you will see everything and prove nothing.

You need the system administrator role yourself to configure any of it.

Final Notes

What I keep coming back to with this one is how much it changes the shape of a conversation I have had dozens of times. For years, "who can see this row" in Dataverse has been a question about structure: which business unit, which team, which position in the hierarchy, who owns it. Filtered record ownership makes it a question about the data. The row's own values decide, and the rule that reads them is a versioned artifact that ships in a solution.

It does not replace the ownership model we have. Nothing here helps you with a table where the answer really is "the person who owns it and their manager", and for that, user and team ownership remains exactly the right tool. But for the very large category of requirements that were always secretly about a column, this is a much more direct road, and it means you stop having to reorganize a company's business units to express a rule about a city name.

It is preview, so build a lab, not a production rollout. But build the lab. This one is worth your Saturday.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Power Apps | Ask in English, Get Rows Back

2026-09-30T07:00:00.000-04:00

Every so often a question comes back around wearing a different costume. The version I have fielded most often, in one form or another, from just about every organization that has ever put a serious amount of data into Dataverse, goes something like this: "can we let people type a question in plain English and get an answer out of the system, without first teaching them what a logical name is?" It is a perfectly reasonable thing to want. And for a long time the honest answer was that yes, you could build it yourself, with a language model out front, a retrieval layer in the middle, and a great deal of careful plumbing to make sure the thing never returned a row the person asking was not entitled to see. That last part is the part that keeps you up at night.

Well, a set of four new articles landed in the Power Apps developer documentation, all of them dated September 25, 2026, and together they describe a first-party answer to that question. Microsoft calls it the Dataverse Ask APIs. Let us take a look.

Background

Four brand new pages, all in preview, all under a new ask folder in the Dataverse developer documentation:

Use the Dataverse Ask APIs (preview), the overview and the operation list.
Get started with the Dataverse Ask APIs (preview), covering the environment prerequisite, authentication, privileges, error handling and retry rules.
Manage Dataverse semantic models (preview), the list, create and delete operations.
Ask questions by using a Dataverse semantic model (preview), the operation that does the actual work.

Now, the concept first, because there are exactly two nouns here and everything else follows from them.

A semantic model is a named scope over one or more Dataverse tables. That is the entire definition. You give it a unique name and a list of table logical names, and Dataverse indexes those tables so that questions can be answered from them. An Ask request submits a natural-language question against one of those named models and gets back rows, plus a written summary, plus links to the source records.

So the shape of the thing is: define the scope once, ask against it many times. Makes sense.

Where this lives, and where it does not

Here is the first detail worth slowing down for, because it will surprise anyone who has spent years in the Web API. The Dataverse Ask APIs are not part of the OData service. They live at their own base address:

https://<environment-url>/api/iq/v1.0/

A few things to note. That is /api/iq/, not the /api/data/ you have been typing since roughly forever. There is no service document and no metadata document. None of the OData query options work, so $select, $filter and $expand are all off the table. And there are no SDK for .NET or SDK for Python client classes for these operations at all: you bring an HttpClient, you bring a Microsoft Entra ID access token for the environment, and you talk JSON over HTTPS like it is 2012 again. The documentation is quite direct about the division of labor, and I think it gets it right: use the Web API when your application knows precisely which rows it wants, and use the Ask APIs when the input is a question and you want the service to work out how to answer it.

Authentication is the same Microsoft Entra ID OAuth you already use for Dataverse. Request the <environment-url>/user_impersonation scope for a delegated, interactive application, or <environment-url>/.default for a confidential client running as an application user.

The part that actually matters: whose privileges answer the question

I want to pull one sentence out of the get-started article and put it under a spotlight, because it is the sentence that decides whether this feature is usable in a regulated shop or not:

"The service only uses data that the caller is authorized to read."

Record ownership, business unit access, sharing and column-level security all still apply. The answer you get is trimmed to the identity that asked. That is exactly the property that is so expensive to build correctly yourself, and it is the reason a first-party implementation is worth paying attention to even if you already have a working retrieval stack of your own.

NOTE: an application using server-to-server authentication runs with the privileges of its Dataverse application user, which means a lazily over-privileged application user quietly turns your carefully trimmed question endpoint into a firehose. Grant that application user only what it actually needs. This is not new advice, but the blast radius is larger than usual here, because the caller is no longer writing the query.

Creating a semantic model

Creating the scope is a single POST. The following creates a model named "Sales pipeline" over the account and opportunity tables:

POST [Organization URI]/api/iq/v1.0/semanticmodel HTTP/1.1
Authorization: Bearer <access token>
Accept: application/json
Content-Type: application/json

{
  "uniqueName": "Sales pipeline",
  "tables": [
    "account",
    "opportunity"
  ]
}

A few things to note. The tables array takes table logical names, so account and opportunity, and the documentation goes out of its way to say not to use display names, entity set names or collection names. A successful call returns 201 Created with the new model's id and uniqueName. Hold on to both: the uniqueName is what you pass when you ask a question, and the id is what you pass when you delete the model. They are not interchangeable, and the delete operation specifically wants the identifier.

Something else to keep in mind is that semantic model names must be unique within an environment, which makes create the one operation in this API that is not safe to blindly retry. The documentation handles this properly and tells you to list the models first to find out whether your uncertain first attempt actually succeeded before you send it again. That is the kind of small, unglamorous guidance that tells you a real engineer wrote the article.

Asking the question

And here is the payoff:

POST [Organization URI]/api/iq/v1.0/ask HTTP/1.1
Authorization: Bearer <access token>
Accept: application/json
Content-Type: application/json

{
  "query": "Which open opportunities have the highest estimated revenue?",
  "semanticModelName": "Sales pipeline",
  "searchMode": "Auto",
  "count": 100
}

A few things to note. The semanticModelName must be the exact uniqueName of a model you created. count caps the rows in this page and defaults to 100. And searchMode is the interesting knob: Auto lets the service choose, QuickResponse favors a faster answer, and ThinkDeeper favors a more considered one when the question warrants it. The documentation notes plainly that search mode affects response time and that you should set a sensible client timeout and show the user some progress. Good. An interactive control that sits there doing nothing for eight seconds is a support ticket waiting to happen.

The response comes back looking like this:

{
  "rawResult": [
    {
      "opportunity": "Contoso renewal",
      "account": "Contoso",
      "estimatedRevenue": 125000
    }
  ],
  "citationLinks": [
    "[Organization URI]/main.aspx?pagetype=entityrecord&etn=opportunity&id=00000000-0000-0000-0000-000000000002"
  ],
  "summary": "The Contoso renewal has the highest estimated revenue.",
  "totalResultCount": 1,
  "pagingToken": null
}

A few things to note, and this is where I would spend my design time. The shape of each object inside rawResult depends on the question and on the query the service generated to answer it. It is not a fixed row type, and the documentation explicitly warns you not to deserialize every Ask response into one. Treat those items as dynamic JSON objects. Nearly every property in the response is nullable too, summary and citationLinks and pagingToken among them, so display the summary when it is there and do not build a user interface that falls over when it is not.

Paging works by echoing the token back. When pagingToken comes back non-null, you send the same question, the same model, the same search mode and the same count, with the token added, and you keep going until the token comes back null or empty. Copy it exactly. Do not decode it, do not modify it, and do not try to construct one.

Why it matters, for makers

The thing a maker should take away is that a semantic model is not a black box you have to accept as-is. Once it exists, you can fine-tune it on the Semantic model page in Power Apps, and there are three levers:

Signals: turn system-inferred signal types such as table summaries and form summaries on or off across tables, exclude tables holding sensitive or irrelevant data, and switch off individual views or relationships that are outdated or misleading.
Glossary: add the business vocabulary the system cannot infer. Acronyms, internal product names, the words your organization uses that nobody else does. This is the lever that decides whether the thing understands your people when they ask about "an RFA" or "the Q3 book".
Refresh: the semantic model regenerates automatically every 12 hours, and you can trigger a manual regeneration when you need a change to land now rather than tonight.

That 12-hour cadence is worth writing on the whiteboard before anybody demos this to a business sponsor. Add a glossary term at nine in the morning, and without a manual regeneration you are potentially explaining all day why the agent still does not know what an RFA is.

Why it matters, for professional developers

Three things, in the order I would worry about them.

First, storage. When you create a semantic model, Dataverse indexes the tables you selected, and that indexing consumes Dataverse database storage. You can see the consumption in the DataverseSearch table, formerly called RelevanceSearch, and it counts toward database storage on the Summary and Dataverse tabs in the admin center. So a semantic model is not a free logical view. Scoping a model to "every table we have, just in case" has a bill attached, which is a good reason to do what the documentation suggests and select only the tables relevant to the questions you actually need answered.

Second, throttling. The Ask API sets its own limit, deliberately lower than the general Dataverse service protection limits: 30 requests per user, per organization, per minute. Go past it and you get a 429 with a Retry-After header carrying the number of seconds to wait. Thirty a minute is generous for a human typing questions and very tight indeed for anything resembling a batch job, which tells you plainly what this API was built for.

Third, dependencies. Before you change or remove a model, you can ask which applications and agents are using it by adding a query parameter:

GET [Organization URI]/api/iq/v1.0/semanticmodel?include=botinfo HTTP/1.1
Authorization: Bearer <access token>
Accept: application/json

A few things to note. With include=botinfo, each model in the response carries the model-driven apps that reference it and a bots collection naming the bot components and agents that use it. The value is not case-sensitive and include accepts a comma-separated list, which suggests more values are coming. Run this before you delete anything. And keep in mind that the delete operation only removes models you created through the create operation: models associated with an app module, a bot or an agent cannot be deleted through this API at all.

The demo I would build

The demo concept I like here is a small, boring command-line tool, because a boring tool makes the interesting part visible. Call it dvask. It does four things: creates a semantic model from a list of table logical names, lists the models in the environment, asks a question and prints both the summary and the rows, and deletes a model by identifier.

The demo that lands, though, is not the happy path. It is running the exact same question twice, from two identities: once as a system administrator, and once as a salesperson whose security role only reaches their own business unit. Same question, same semantic model, two different answers, both correct. That is the whole value proposition of a first-party implementation in one side-by-side screenshot, and it is the thing that is genuinely hard to build yourself.

The second demo, for the developers in the room, is the paging loop, because it is the one piece of the protocol where it is easy to write a bug that only shows up on the third page in production.

The companion repo

Sketching this the way I would lay it out, in the project-orion-lab style:

dataverse-ask-lab/
  README.md                 prerequisites, the Work IQ toggle, role requirements
  src/
    DvAsk/
      Program.cs            verb dispatch: create | list | ask | delete
      AskClient.cs          HttpClient wrapper over /api/iq/v1.0/
      TokenProvider.cs      MSAL: delegated and client-credentials flows
      Models.cs             request types; responses stay JsonDocument
  samples/
    sales-pipeline.json     semantic model definition: account, opportunity
    questions.txt           the question set used in the demo
  scripts/
    compare-identities.ps1  same question, two identities, side by side
  docs/
    throttling.md           the 30/minute limit and the backoff implementation

A few things to note about that layout. Models.cs deliberately holds request types only: the responses stay as JsonDocument, because as we established, rawResult has no fixed shape and pretending otherwise is how you ship something that works beautifully against your demo data and falls apart on the customer's. compare-identities.ps1 is the star of the repo even though it is the smallest file in it. And throttling.md earns its place because the retry guidance in the documentation is unusually specific, and specific guidance deserves a reference implementation: honor Retry-After first, fall back to exponential backoff with jitter, cap the attempts and the total elapsed time, do not fire retries in parallel, and never retry a 400.

Steps to recreate

1) Go to the Power Platform admin center, select your environment, and turn on Business Applications in Work IQ for this environment. Nothing in this API works until that is on, and a request against an environment without it comes back as a 400 Bad Request rather than anything more helpful.

2) Register an application in Microsoft Entra ID. For an interactive tool, configure delegated access and request the <environment-url>/user_impersonation scope. For a service, create a Dataverse application user and request <environment-url>/.default.

3) In the Power Platform admin center, give the calling identity a security role that can create and delete semantic models. The documentation names four that already include the privileges: Dataverse Search Role, Environment Maker, System Administrator and System Customizer.

4) Make sure the identity that will ask questions has Read access to every table and column in the model. This is a separate concern from step 3: managing models and querying through them are different privileges.

5) POST to /api/iq/v1.0/semanticmodel with a uniqueName and a tables array of logical names. Save the id and the uniqueName from the 201 Created response.

6) POST to /api/iq/v1.0/ask with your query and the semanticModelName. Read summary for the prose and rawResult for the rows.

7) To tune it, go to make.powerapps.com and open the Semantic model page, then work through Signals and Glossary. Trigger a manual regeneration when you want your changes to take effect before the next automatic 12-hour refresh.

8) Before deleting anything, GET /api/iq/v1.0/semanticmodel?include=botinfo and read the bots collection to see what depends on the model.

NOTE: the documentation does not give a click path for creating a semantic model from the Power Apps maker portal, only for fine-tuning one that already exists. The create, list and delete operations are documented as API operations. So for now, treat the API as the way models get created and the maker portal as the way they get tuned. If a maker-portal creation path exists, these four articles do not describe it, and I would rather tell you that than guess at a menu.

Final Notes

Two closing thoughts.

The first is that this is preview documentation, with everything that implies. Property names, the searchMode values and the shape of the response are all fair game for change before this reaches general availability, and the articles are marked accordingly. Build the client, do not build the company on it. Not yet.

The second is more of an observation. Look at where these articles were filed. Not under a copilot or an AI heading, but in the Dataverse developer documentation, alongside the Web API, with an error-code table, a retry policy, service protection limits and operation-safety guidance for every verb. Natural-language querying, in other words, is being documented as an ordinary data access API that happens to take a sentence as input. That is a quiet shift in framing, and it is a very healthy one. It is a good deal easier to reason about something when it arrives with a 429 and a Retry-After header attached.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Copilot Studio | The Agent Your Flow Can't Call

2026-09-21T07:00:00.000-04:00

There is a particular kind of bad afternoon in this business. You have built the thing, it works, you demo it, everyone is happy. Then somebody asks the obvious follow-up question, the one that was always coming: "great, now can the nightly flow call it?" And you go to wire it up and discover that the answer is no, not because you did anything wrong, but because of a choice you made on day one without knowing it was a choice.

Microsoft published a short new article in mid-August that will save somebody that afternoon. It is worth reading before you build your next agent rather than after.

Background

The article is Call Microsoft Copilot Studio agents from Power Automate, new in the Power Automate documentation and last updated August 18, 2026. It opens with a two-row table, and that table is the whole post:

Standard harness: Call the agent from a Power Automate cloud flow by using the Microsoft Copilot Studio connector.

GitHub Copilot harness: Use the agent node in a Copilot Studio workflow. You can't call this type of agent from a Power Automate cloud flow by using the Microsoft Copilot Studio connector.

Now, a harness needs defining, because the word is new enough that plenty of people building agents right now have never seen it. Per the harnesses overview, you design the agent and the model supplies the reasoning, and the harness is the runtime sitting between the two: it decides when to call the model, what to send it, how to interpret what comes back, and which tools to call. Everything you build in Copilot Studio runs on one.

There are three. The GitHub Copilot harness powers agents and workflows built for reasoning-heavy, multistep work, and bills through Copilot Credits on usage. The standard harness powers rule-based agents and agent flows, where you define the topics and paths and get predictable behavior. The Copilot chat harness is for extending Microsoft 365 Copilot.

So the harness is not a setting you flip later. It determines how your agent reasons, how you are billed, and, as of this article, what can call it.

This was not one article

Here is the part that makes me confident this is a real platform move rather than a documentation footnote. That new Power Automate page did not arrive alone. Across the same week, roughly a hundred Copilot Studio articles were touched, and the substantive edits among them all point the same direction: Microsoft is retiring the informal vocabulary and replacing it with harness names everywhere.

Pages that used to say "the classic experience" and "the new agent experience" now say "the standard harness" and "agents powered by the GitHub Copilot harness." The telemetry articles were split along the same line: agent-level telemetry is now documented as available only with the standard harness, while environment-level telemetry works with both. The article on adding tools to an agent was amended to say that coding-agent skills can only be added to agents powered by the GitHub Copilot harness. Even the old skills article was reworded to name both harnesses explicitly.

One renamed page is housekeeping. A hundred pages renamed in one week, with capability boundaries drawn along the new names, is a platform telling you that this distinction is now load-bearing.

Why it matters

For makers, the practical consequence is a question you now have to ask at the start: does anything else need to call this agent? If a scheduled flow, an approval process, or an existing automation has to invoke it, you want the standard harness, because that is the one the Power Automate connector can reach. If the agent is going to be talked to by humans and needs to reason its way through messy multistep work, the GitHub Copilot harness is the more capable runtime, and you accept that your integration path runs through Copilot Studio workflows instead.

You may be asking whether that is a real constraint or just a temporary gap. The documentation does not say, and I am not going to guess. What it does say is what works today, and today the connector supports one harness and not the other.

For professional developers, the sharper point is that this is an architectural decision wearing the costume of a product setting. It sits alongside two others made at the same moment: your billing model, since the GitHub Copilot harness runs on Copilot Credits and the standard harness runs on the licensing model, and your observability model, since agent-level telemetry export is standard-harness only. Three consequences, one choice, made in a dropdown before you have written anything.

NOTE: there is a workaround, and it is a legitimate one rather than a hack, but it does change your topology. You call a GitHub Copilot harness agent from an agent node inside a Copilot Studio workflow. That means the orchestration lives in Copilot Studio rather than in Power Automate. If your organization's automation estate, source control, and deployment pipeline are all built around cloud flows, that is not a small relocation.

The demo concept

Build the same trivial agent twice, once on each harness, and then try to call both from one cloud flow. The standard harness agent answers. The other one is not selectable, because it never appears in the connector's agent picker at all.

That is the demonstration worth recording, because it is a negative result and negative results are what documentation tends to bury. Then build the workflow-plus-agent-node path for the second agent and show it working. Two agents, two integration paths, one screen recording, and nobody on your team ever has that bad afternoon.

Steps to recreate

First, the supported path. These steps are quoted from the new article.

1) Sign in to Power Automate.

2) Create a cloud flow, or open an existing cloud flow and select Edit.

3) In the designer, select the plus sign (+) where you want to call the agent, and then select Add an action.

4) Search for Microsoft Copilot Studio, and then select Execute Agent and wait.

5) If prompted, sign in with Microsoft Entra ID to create a connection.

6) In Agent, select the published standard harness agent that you want to call.

7) In Message, enter the instructions for the agent. You can add dynamic content from earlier steps in the flow.

8) Configure the optional inputs your scenario needs: Locale (the language of the message, as a BCP-47 locale), Conversation ID (an existing conversation ID, to continue an agent conversation), and Environment ID (the environment that contains the agent).

9) Add any actions that should use the agent's response, then select Save and test the flow.

A few things to note about that sequence. The word published in step 6 is not filler: an unpublished agent will not be there to pick, and that is the first thing to check when the dropdown looks empty. Execute Agent and wait blocks the flow until the agent responds, which is what you want when the next action consumes the answer; the article notes that if you do not need to wait, the plain Execute Agent action sends the message and returns the conversation ID instead. And that conversation ID is the interesting output, because passing it back in on the next call is what turns a series of one-shot invocations into an actual conversation. The action surfaces the last response, a list of responses, and the conversation ID as dynamic content.

Now the other path, for a GitHub Copilot harness agent:

1) In Copilot Studio, go to Workflows and open an existing workflow, or create a new one.

2) On the Add panel, select the Agent icon.

3) Under Agent, select An existing agent, and then select the published GitHub Copilot harness agent you want to call.

4) In Message, enter the instructions for this run, adding dynamic content from earlier workflow steps as needed.

5) Add the later workflow steps that use the agent response, and test the workflow before you publish it.

Notice the symmetry. Both paths are an agent-invoking step with a message and a response, and both want the target published first. The difference is entirely which product hosts the orchestration, which is exactly why the constraint is easy to miss until it bites: the shape of the work is identical, only the address changes.

Companion repo sketch

A small comparison lab. Two exported solutions, agent-standard/ and agent-ghcopilot/, each holding the same deliberately boring agent so the harness is the only variable. A flow-caller/ solution with the cloud flow that calls the standard harness agent through Execute Agent and wait. A workflow-caller/ solution with the Copilot Studio workflow that reaches the other one through an agent node.

Then the file that makes the repository worth cloning: a MATRIX.md recording what each harness supports, with the observed result and the date beside every row. Connector callable, agent-level telemetry, coding-agent skills, billing model. Date every row, because this is a moving platform and an undated compatibility matrix is worse than none at all. It ages into confident misinformation.

Final Notes

The change itself is one table in one short article. What makes it worth your time is the timing: it landed in the same week that a hundred sibling pages were rewritten to make harness the organizing noun of the whole product. That is not a coincidence, and it is a reasonable bet that more capability boundaries get drawn along this line before the year is out.

So ask the integration question first. Before the topics, before the knowledge sources, before anybody sees a demo: what needs to be able to call this? The answer picks your harness, and the harness picks a great deal else.

What I learned from this exercise: the most expensive decisions on a platform are rarely the ones that look like decisions. They look like defaults.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Power Apps | Seven Skills, One Prompt: The Dataverse Plugin for Coding Agents

2026-09-17T07:00:00.000-04:00

Anyone who has built anything nontrivial on Microsoft Dataverse knows the tax. You want to stand up a small data model, load a few thousand rows into it, and move the whole thing to a test environment. That is one sentence to describe and four tools to execute: the SDK for Python for the bulk write, the Dataverse CLI for authentication, the Power Platform CLI for the solution export, and the Web API for whatever the other three do not cover. None of it is hard. All of it is friction, and the friction is mostly syntax you have to remember rather than decisions you have to make.

Well, in late August Microsoft published something that goes after exactly that friction, and it arrived quietly, as two new articles with no fanfare attached.

Background

Two new pages landed in the MicrosoftDocs/powerapps-docs repository, both dated 07/31/2026 and both published in the week ending August 24:

Microsoft Dataverse plugin for AI coding agents (preview), the overview and install article.
Microsoft Dataverse plugin for AI coding agents reference (preview), the per-skill reference.

Both are new files, not edits, and the developer table of contents was amended to carry them, which is the tell that this is a shipped surface rather than a stray draft. The source is open, in the microsoft/Dataverse-skills repository, so you can read every instruction the agent is given before you let it near an environment. I would encourage you to do exactly that.

Now, the term coding agent deserves a definition, because it is doing a lot of work in these articles. A coding agent is an AI assistant that runs inside your development environment, reads and writes files in your project, and executes commands on your behalf. GitHub Copilot, Claude Code, Cursor and Codex are the four named as supported. The distinction that matters: a coding agent runs commands, where a chat assistant only suggests them.

The Solution: a plugin is instructions, not code

Here is the part worth slowing down for, because it is easy to misread this as "Microsoft shipped another connector."

It did not. The documentation is precise: this is an open-source set of instructions that help a supported coding agent perform Dataverse development and administration tasks. It does not replace the Dataverse development tools. It tells the agent which one to reach for.

You may be asking why that is worth shipping at all. Very simple: tool selection is the hard part. An agent that knows the Web API exists will cheerfully use it to insert five hundred rows one HTTP call at a time, and it will be correct, and it will be terrible. The plugin's job is to know that five hundred rows means the Python SDK and CreateMultiple, that a schema question means MCP, and that a solution export means the Power Platform CLI. The routing rule is stated plainly: MCP for interactive queries and small record sets, the Python SDK for bulk operations, transformations, paging and analytics.

Seven skills ship with it. dv-overview loads first and carries the tool-selection guidance; every other skill sits behind it. dv-connect sets up the workspace. dv-query reads and analyzes, up to server-side aggregation and pandas DataFrames. dv-data handles creates, updates, upserts, CSV imports and sample data. dv-metadata builds tables, columns, relationships, alternate keys, forms and views. dv-solution runs the solution lifecycle. dv-admin and dv-security cover environment settings, retention, bulk delete, audit configuration and role assignment. A single request can pull several at once.

The two design decisions I would point at

The first is buried in dv-metadata, and every Dataverse developer will recognize it. The skill instructs the agent to follow an environment-first metadata workflow: make the change in Dataverse through a managed API, export and unpack the solution, then commit the generated files. And then:

The agent shouldn't create new Dataverse components by writing solution XML manually.

That is the correct instinct, written down. Hand-authored solution XML is how you get components that import cleanly and then behave strangely, and an agent left alone would absolutely write it, because from a language model's point of view XML is just text and text is easy. A small sentence carrying a lot of hard-won experience.

The second is the guardrail model, and it is more honest than I expected. The documentation states that Dataverse enforces the platform controls, that the agent-level guardrails guide how the agent plans and confirms, and that they "aren't a substitute for reviewing the proposed action." Then it names the boundary that actually protects you: the agent cannot exceed the permissions of the authenticated identity. Table privileges, field-level security, ownership and sharing, and administrator permissions are enforced on every request.

NOTE: the agent-level confirmations are still worth knowing. Before the first operation against an environment in a session, the agent must show the target environment URL and get confirmation. Before creating a publisher prefix it must show existing publishers, because a prefix is permanent. And an unfiltered bulk delete, which bypasses the recycle bin, requires an explicit acknowledgment naming the table logical name and stating that all records should be deleted. That is the right shape for a destructive operation: make the human type the dangerous part.

Why it matters

For makers, the honest answer is: not yet, and that is fine. This is a developer surface, needing a local toolchain, a terminal and a coding agent. If your Dataverse work happens entirely in make.powerapps.com, nothing here changes your Tuesday. What it does change is who can help you, and how fast.

For professional developers, there are two claims here and they are not the same size. The small one is convenience, real but unremarkable. The large one is that Microsoft has published, in the open, its own opinion about which Dataverse tool to use for which job, in a form a machine reads. That opinion has existed for years, scattered across documentation, conference sessions, and the accumulated instinct of people who have been burned enough times. Written down as executable guidance, it becomes reviewable, forkable, and arguable in a way instinct never is.

Two cautions, both from the documentation rather than invented by me. This is preview. And Dataverse MCP access carries an authorization chain no plugin can shortcut: the developer authenticates, a tenant administrator consents to the MCP client application, and an environment administrator allows that application in each target environment. The connection flow tells you what is needed; it does not bypass administrator approval. In a governed tenant, that is a ticket, not a command.

The demo concept

Not "watch the agent make a table," because that is a parlor trick that proves nothing you could not do faster by hand. The demonstration worth building is the four-tool problem from the top of this post, executed as one prompt, with the tool selection made visible. Build a small ticketing model, load a few hundred rows, package it, deploy it to a second environment. Then go back and look at which skill did what. If dv-data reached for CreateMultiple rather than five hundred single inserts, the routing did its job, and that is the whole point in one observation.

Steps to recreate

1) Install the plugin. The command differs by agent:

GitHub Copilot:  /plugin install dataverse@awesome-copilot
Claude Code:     /plugin install dataverse@claude-plugins-official
Cursor:          /add-plugin dataverse

A few things to note. These are slash commands typed into the agent's own chat, not shell commands. The part after the @ is the marketplace the plugin comes from, and it differs because each vendor runs its own. In GitHub Copilot you can also run /plugin, open Discover, and search for dataverse; in Cursor, go to Settings > Plugins, search for Dataverse, open Microsoft Dataverse, and select Add to Cursor. Codex is the odd one out, having no default marketplace carrying this plugin: open Plugins > Add marketplace, set Source to https://github.com/microsoft/Dataverse-skills.git, leave Git ref and Sparse paths empty, add the marketplace, then install the dataverse plugin from it.

2) Connect, then verify, in plain language:

Connect to my Dataverse environment.
List the tables in my Dataverse environment.

The first triggers dv-connect, which checks whether the workspace is already configured, verifies and installs the required tools, discovers your environments and asks you to select one, configures Dataverse CLI and Power Platform CLI authentication, creates the local workspace configuration while excluding credentials and generated artifacts from source control, registers the Dataverse MCP server, and verifies the connection. That is nine steps behind one sentence, and the one I would call out is the source-control exclusion, because it is the step a hurried human skips. Note also that some coding agents must be restarted after MCP registration before the MCP tools appear. If the second command comes back saying it has no tools, that is why.

3) Do real work. This prompt is drawn from tests in the repository, which is a useful signal: it is known to work rather than merely plausible.

Write a Python script that efficiently creates 500 ticket records in my
Dataverse new_ticket table. Each ticket should have a unique title and a
priority value. Optimize for the fewest HTTP calls.

A few things to note. "Optimize for the fewest HTTP calls" is the phrase doing the work, pushing the agent from a naive loop to CreateMultiple with batching. Change new_ticket to your own logical name, publisher prefix and all. And notice it asks for a script, so you get an artifact you can read, commit, and run again, rather than an action that already happened.

4) Package and move it:

Pack the CustomerService solution, import it into the test environment, and
verify that the ticket table, main form, and active tickets view are available.

The verification clause is not decoration. dv-solution supports post-deployment validation of tables, forms, views, role assignments and import errors, so asking for it is what turns "the import returned success" into "the components are actually there." Two different claims, and only one is worth trusting.

Companion repo sketch

A lab repository that is honest about being a lab. A prompts/ folder with the exact prompts in order, so someone else can reproduce the run. A transcripts/ folder with what the agent actually did, because the interesting artifact is the routing rather than the result: which skill was selected, which tool it chose, whether it batched. A solution/ folder holding the solution exactly as dv-solution unpacked it, so the environment-first workflow shows up in the diff instead of being asserted in a README. And a short FINDINGS.md recording where the agent chose well and where it did not, because a lab that records only successes is marketing.

Point the README at a developer environment from the Power Apps Developer Plan, which the documentation names as the appropriate nonproduction option, and say so loudly. Nobody should be learning this against production.

Final Notes

What I keep coming back to is not the convenience. It is that the routing table is public. Microsoft has written down, in a repository you can read, which Dataverse tool it thinks you should use for which job and why. Whether or not you install the plugin, that is worth twenty minutes of your time, because it is the closest thing we have had to an official answer to a question this platform has been quietly asking developers for a decade.

And it is preview, so it will change. Read the skills before you trust them, run against a developer environment first, and remember that the confirmations are guidance to the agent rather than enforcement by the platform. The enforcement is your identity's privileges, and that is the line that actually holds.

What I learned from this exercise: the valuable part of an agent integration is rarely the automation. It is the accumulated judgment somebody had to write down to make the automation behave.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Power Automate | Licensing the Flow Nobody Owns

2026-09-14T07:00:00.000-04:00

If you have done any serious application lifecycle management work in Power Platform, you know the pattern: you move flow ownership off a human being and onto a service principal, because people change roles, people leave, and a mission critical flow should not stop working because somebody's manager reassigned a license on a Tuesday. It is good practice, and I have watched it save projects.

It also had a sharp edge, and in mid-August Microsoft filed it down.

Background

Here is the edge. A service principal application user is a non-interactive user, which means you cannot assign it a license. So the moment your service principal owned flow used anything premium (a premium connector, a custom connector, an HTTP action), you had a compliance problem. Your options were a Power Automate Process license assigned to the flow itself, which requires the flow to be solution-aware, or a Process license on a flow group sharing that capacity. Both are real answers. Both cost money that, in a lot of cases, you had already spent on a perfectly good user license sitting right there.

And if you did neither, the flow got suspended, with a message that will be familiar to anyone who has been on the receiving end of it:

This flow was suspended because flows owned by service principals are not compliant.

Now, as of a new article published on August 15, 2026, there is a third option: designate a licensed user, and the flow runs under that user's Power Automate entitlement while the service principal remains the owner.

This is not a documentation-only change. The existing Support for service principal owned flows article was edited the same week, and where it listed two licensing routes it now lists three. Two independent pages moving the same direction in the same week is usually how you tell something actually shipped.

What you get, and what it costs you

Designating a user license means the flow runs under that user's entitlement, and that user's action limits apply. A Process license, by contrast, is capacity attached to the flow itself, entitling it to 250,000 actions per day independent of any user, and it can be shared across up to 25 flows in a flow group.

So the new option is cheaper and simpler, and you pay for it in headroom. A high-volume integration flow that would chew through 250,000 daily actions is not a good candidate for somebody's personal entitlement. A nightly reconciliation flow that fires forty times a day absolutely is.

The two prerequisites that will bite you

The first: the designated user must be a co-owner of the flow. Not merely a licensed user in the tenant. A co-owner. If they are not, share the flow with them first.

The second is the important one: the user's license must cover every premium feature the flow uses. The documentation names premium connectors, custom connectors and HTTP actions, says a Power Automate Premium license covers these, and then says something worth reading twice: a Microsoft 365 seeded license does not, and the flow stays noncompliant if you designate a user who only has one.

That is the failure mode. You designate a user, the save succeeds, the UI looks right, and the flow is still out of compliance because the person you picked has a seeded license. If you are troubleshooting a flow that stayed suspended after you "fixed" it, check that first.

Why it matters

For makers, the ALM-correct thing is no longer the expensive thing. Moving ownership to a service principal used to come with an invoice attached, and that invoice was enough to talk a lot of teams out of doing it properly. The workflow itself is short: open the flow's Details page, find User license in the licensing section, pick the user, save.

For professional developers, two things. It is cleanly scriptable, because the designation is stored in Dataverse as the Licensee column on the flow's row in the Process (workflow) table, a lookup to a User (systemuser) record. Setting it programmatically is, in the documentation's words, equivalent to using the Details page.

And then the one I would put on a wall: the designation points to a user record in a specific environment, so it is not carried in a solution. Deploying through a managed solution or a pipeline does not reapply it in the target. Think about what that means. You promote the flow to production, everything imports green, the flow turns on, and it is unlicensed there because the designation never travelled. Nothing failed. Nothing warned you. You find out when it gets suspended.

The demo concept

A post-deployment licensing step: one script, run after solution import, that resolves the identifiers, sets the designation, and reads it back to prove it landed. Here is the request that does the work, straight from the documentation:

PATCH [Organization URI]/api/data/v9.2/workflows(<workflowId>) HTTP/1.1
Content-Type: application/json

{
    "licensee_systemuserid@odata.bind": "/systemusers(<systemUserId>)"
}

The @odata.bind annotation is how the Web API sets a lookup: you are binding a reference to a row in another table, which is why the value is a path and not a bare GUID. This is a PATCH against the workflows entity set, which is the Process table, because cloud flows are rows there where Category is Modern Flow. You need two identifiers: the flow's workflowid, which also appears in its URL in the portal, and the user's systemuserid.

Wired together, and trimmed to the essentials:

$api = "$OrgUrl/api/data/v9.2"
$headers = @{ Authorization = "Bearer $token"; 'Content-Type' = 'application/json' }

# Category 5 is Modern Flow. Refuse to act unless exactly one row matches.
$flows = (Invoke-RestMethod -Headers $headers -Uri
    "$api/workflows?`$filter=category eq 5 and name eq '$FlowName'").value
if ($flows.Count -ne 1) { throw "Expected 1 flow, found $($flows.Count). Refusing to guess." }

$users = (Invoke-RestMethod -Headers $headers -Uri
    "$api/systemusers?`$filter=domainname eq '$UserUpn'").value
if ($users.Count -ne 1) { throw "Expected 1 user, found $($users.Count)." }

$body = @{ 'licensee_systemuserid@odata.bind' = "/systemusers($($users[0].systemuserid))" } |
    ConvertTo-Json
Invoke-RestMethod -Method Patch -Headers $headers -Body $body `
    -Uri "$api/workflows($($flows[0].workflowid))"

A few things to note, because there is more opinion here than code. Both lookups refuse to proceed unless they match exactly one row: a script that silently picks the first of three similarly named flows will license the wrong one and you will not find out for a month. The backticks before $filter are PowerShell escapes, because $ starts a variable in PowerShell and OData query options genuinely begin with a dollar sign; leave them out and you send a URL with the query options silently deleted. And $token is whatever your pipeline already uses to authenticate against the environment.

Then verify, because a PATCH returning 204 tells you the request was accepted, not that the designation is what you wanted:

GET [Organization URI]/api/data/v9.2/workflows(<workflowId>)?$select=name,_licensee_value HTTP/1.1
Prefer: odata.include-annotations="OData.Community.Display.V1.FormattedValue"

That Prefer header is the point. Without it you get a raw GUID in _licensee_value and you will spend ten minutes looking it up by hand. With it, Dataverse also returns the user's display name, and your pipeline log becomes evidence rather than a promise. The underscore-prefixed column name is the standard convention for reading a lookup's value, and it trips up everyone exactly once.

To remove a designation, DELETE the same path with /licensee_systemuserid/$ref appended. The article notes it succeeds even when no user is designated, which makes it safe in a teardown script.

Doing it from a flow instead

If your deployment process is itself a cloud flow, the documentation gives this path:

1) Add the Update a row action from the Microsoft Dataverse connector.

2) In Table name, select Processes.

3) In Row ID, enter the workflowid.

4) In Licensee (Users), enter /systemusers(<systemUserId>). If the field is not shown, select Show advanced options. Leave it empty to remove the designation.

NOTE: the documentation does not spell out the navigation to the flow's Details page for the manual route, it simply says to open it, so I am not going to invent a click path. It is the page you land on when you select the flow by name from My flows or from the solution.

Companion repo sketch

Three scripts and a pipeline step: Set-FlowLicensee.ps1 as above, Remove-FlowLicensee.ps1 for the $ref teardown, and the one that earns its keep long term, Get-FlowLicensee.ps1, which lists every Modern Flow owned by an application user and reports which have a designation and which do not. That is your compliance drift report in about thirty lines. The pipeline step exists purely because the designation does not travel in a solution, so it must be reapplied per environment by something that cannot forget.

Final Notes

I like this change more than its size suggests. It removes a real disincentive to doing ALM properly, and the disincentive was purely financial rather than technical, which is the most annoying kind.

If you carry away one thing: the designation is per environment and solutions do not move it. Everything else here is a five minute configuration change. That one is an architectural fact about your deployment pipeline.

What I learned from this exercise: "it deployed successfully" and "it is licensed" are two different claims, and only one of them shows up green in your pipeline.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Copilot Studio | Grounding a Copilot Studio Agent on Azure SQL

2026-09-10T07:00:00.000-04:00

Every Monday I read what moved in the Microsoft Learn documentation over the previous week, mostly because I got tired of finding out about a capability three months late, when a customer asks why we are not already using it. Most weeks the honest answer is "nothing worth your time". The week of August 13th was not one of those weeks.

A new article appeared in the Copilot Studio documentation, and it changes the answer to a question I have been asked more times than I can count: can my agent answer questions straight out of my database?

Now it can.

Background

Until now, grounding a Copilot Studio agent meant pointing it at content that was, broadly speaking, prose: SharePoint documents, websites, uploaded files, Dataverse tables. If your answer lived in a relational database in Azure, you either built a tool that queried it and shaped the result yourself, or you exported the data somewhere the agent could already read. Both work. Neither is what you would call delightful.

Dataverse is the one I have spent real time on, in an earlier article on adding those knowledge sources with the Web API instead of clicking them together in the maker portal. Worth keeping in mind as you read on, because Azure SQL is a different animal in one important respect: that Dataverse recipe works precisely because a Dataverse knowledge source is itself Dataverse rows, and here there is no intermediate copy of anything. Your data stays in your database.

The new article is Add Azure SQL tables as a knowledge source. In its own words, you ground your agent in the structured data stored in your Azure SQL database, and the agent answers by reading from the tables you select.

Select the tables. That is the whole configuration story. No tool authoring, no schema mapping, no intermediate copy of the data.

The part everybody will skip, and shouldn't

There is a security model here, and it is not the one most people will assume. Azure SQL knowledge uses the Power Platform SQL connection you create during setup, and then:

Users only receive answers based on data the maker can access through the maker's configured connection and database permissions.

Read that again. The ceiling is the maker's connection, not the end user's own database rights. If you wire up a connection that can read the whole Sales schema, then every user who can talk to that agent can get answers derived from the whole Sales schema. The agent is not brokering each user's individual SQL permissions row by row.

That is not a defect, it is how connection-based grounding works everywhere in Power Platform. But it does mean table selection is a security decision, not just a relevance one, and I would even venture to say it is the sentence in that article most likely to be skimmed past and later regretted. Select the tables the agent needs. Not the tables you happen to have.

What it means for you

If you are a maker, a whole category of question moves from "that needs a developer" to "that needs a good description". Order status, purchase history, revenue by customer or date: ground an agent on it in an afternoon. The catch is that quality now depends on your schema. The documentation asks for clear column names over cryptic abbreviations (CustomerName, not CustNm), primary keys on every table, and descriptive names such as OrderDate rather than Date1. It also warns that extra tables dilute grounding. So, your schema quality is now prompt quality, and every badly named column you inherited is now, quite literally, a worse answer.

If you are a professional developer, three things matter. The primary key requirement is not decorative: the agent uses primary keys to identify rows and return results, so heap tables will behave poorly. Network reachability is on you, and the prerequisites offer firewall rules allowing Azure services or private connectivity, the first of which will not survive most security reviews, so budget for that conversation early. And best of all, the documentation hands you a testability seam: create a diagnostic view returning a small, known dataset and confirm the connection before you point at production. That turns "the agent gave a weird answer" into something you can bisect in ten seconds.

NOTE: the documentation hedges its own UI labels, saying you pick Azure SQL or SQL Server "depending on the label shown in your environment". I am reproducing that hedge rather than guessing.

A demo worth building

Something small and controlled: a three-table order schema, a diagnostic view with a known answer, and an agent grounded on exactly those tables, so you can change one thing at a time and watch what it does to answer quality. Here is the schema, written the way the documentation asks:

CREATE TABLE dbo.Customers (
    CustomerId   INT           NOT NULL IDENTITY(1,1),
    CustomerName NVARCHAR(200) NOT NULL,
    CustomerCity NVARCHAR(100) NULL,
    CONSTRAINT PK_Customers PRIMARY KEY CLUSTERED (CustomerId)
);

CREATE TABLE dbo.Orders (
    OrderId     INT           NOT NULL IDENTITY(1,1),
    CustomerId  INT           NOT NULL,
    OrderDate   DATE          NOT NULL,
    OrderStatus NVARCHAR(40)  NOT NULL,
    OrderTotal  DECIMAL(18,2) NOT NULL,
    CONSTRAINT PK_Orders PRIMARY KEY CLUSTERED (OrderId),
    CONSTRAINT FK_Orders_Customers FOREIGN KEY (CustomerId)
        REFERENCES dbo.Customers (CustomerId)
);

CREATE TABLE dbo.OrderLines (
    OrderLineId INT           NOT NULL IDENTITY(1,1),
    OrderId     INT           NOT NULL,
    ProductName NVARCHAR(200) NOT NULL,
    Quantity    INT           NOT NULL,
    UnitPrice   DECIMAL(18,2) NOT NULL,
    LineTotal   DECIMAL(18,2) NOT NULL,
    CONSTRAINT PK_OrderLines PRIMARY KEY CLUSTERED (OrderLineId),
    CONSTRAINT FK_OrderLines_Orders FOREIGN KEY (OrderId)
        REFERENCES dbo.Orders (OrderId)
);

CREATE VIEW dbo.AgentGroundingCheck
AS
SELECT 'GROUNDING-OK' AS DiagnosticMarker, 42 AS DiagnosticNumber;

A few things to note. Every table carries an explicit primary key, because that is what the agent uses to identify rows. Every column name is a phrase a human would say out loud, and you should resist the urge to shorten them. The view at the bottom is the diagnostic seam: add it to the knowledge source, ask "what is the diagnostic marker?", and you learn whether the connection works at all, independent of whether your business data is right. Pick your own marker value, and drop the view from the knowledge source before real users arrive, because it is scaffolding, not a feature.

Now the description, which is not code but is configuration, and which the documentation treats as the highest-leverage text you will write:

Azure SQL knowledge for Contoso order management. Includes Customers,
Orders, and OrderLines tables. Use this source for questions about order
status, order history, customer purchases, and revenue by customer or
date. Don't use for inventory on-hand or shipping carrier tracking.

This is lifted from the article's own example, and the shape is what matters: domain, tables, what to use it for, and then what not to use it for. That last sentence does real work, because generative orchestration is choosing between your knowledge sources, and an exclusion is often a stronger signal than an inclusion.

The steps

The full click path is in the source, and given the label hedge above I would rather you read it there than trust my transcription. These are the steps that carry a decision:

1) Prepare the database. Primary keys defined, readable column names, and your Azure SQL server reachable from Power Platform.

2) Select the tables deliberately. This is the security decision from earlier, not a relevance one.

3) Write the description properly, in the shape above.

4) Publish the agent. The knowledge source is not available in the published experience until you do, and this is exactly the step that gets skipped and then generates a bug report.

5) Test with something that must come from those tables. The article's own example: "Show me the top five customers by total sales last month."

That is still a walk through a dialog, which raises the obvious question if you read the Dataverse piece: can this one be created from code instead? I have not checked, and I am not going to guess. The connection is a Power Platform connection and the knowledge source is a row somewhere, so there is a fair chance the same approach applies. But that is a hypothesis, and it belongs in a follow-up where I can show it working rather than in a paragraph where I speculate about it.

Companion repo sketch

Four folders is plenty: sql/ with schema, seed, diagnostic view and teardown; agent/ holding the knowledge description as its own version-controlled file, because it is configuration that changes behavior and deserves a diff history; a test-questions.md with three columns, the question, the expected answer, and the table the answer must come from; and docs/ for the network and security notes. Use fixed dates in the seed data, never dates relative to today, or "last month" will mean something different in March than in September and your tests will rot. That third column in the test file is the piece people leave out, and without it you cannot tell a grounding failure from a data failure.

Final Notes

This lands exactly where agents have been weakest: answering from the boring, structured, authoritative data that businesses actually run on. Slick.

One caution, the same one: the maker's connection defines what every user of that agent can reach. And since the article is four days old as I write this, labels may still be moving, so trust your screen over my transcription and go read the source.

What I learned from this exercise: the schema you were going to clean up "someday" is now on the critical path to answer quality, and that's always a good thing, because it finally gives you a business reason to do it.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Copilot Studio | Migrate the Agent, Keep the Client ID

2026-09-07T07:00:00.000-04:00

There is a question I have been asked in one form or another by every administrator who has ever inherited a tenant full of Copilot Studio agents, and it always arrives with the same slightly worried tone: "what are all these app registrations in Entra, and which agent does each one belong to?" It is a fair question. For years the answer was that Copilot Studio quietly provisioned an Azure app registration for every agent you created, those registrations piled up in Microsoft Entra ID looking exactly like every other application in the tenant, and telling them apart was an exercise in cross-referencing GUIDs. Not exactly a governance story.

Well, in late August three articles landed in the Copilot Studio documentation that finally close that loop, and one of them is the migration runbook administrators have been waiting for.

Background

Two brand new pages and one substantially rewritten page, all last updated on August 27, 2026:

Agent identities and authentication for Copilot Studio, new, a plain-language explainer written as a set of questions.
Migrate Copilot Studio agents to Microsoft Entra Agent ID, new, and the reason for this post.
Microsoft Entra Agent IDs for Copilot Studio agents, rewritten with the migration guidance and the transition-period rules.

Now, the model itself, because the terminology is new and worth pinning down before anything else. A Microsoft Entra Agent ID is a Microsoft Entra service principal with an "Agent" subtype. That is the whole definition. It is not a new protocol and not a new token type. The documentation is careful about this: the underlying OAuth-based authentication flow remains the same. What changes is that the agent is now a first-class object in Entra that an administrator can see, govern, and write policy against, rather than an anonymous app registration sitting in a list of four hundred others.

Copilot Studio has been creating these automatically for every new agent since May 2026. Agents created before that date still carry the legacy app registration, and here is the sentence that turns this from trivia into a project: existing agents will be migrated by Microsoft automatically in a future update. So the migration is happening either way. The only decision in front of you is whether it happens on your schedule or on Microsoft's.

NOTE: one other thing changed in the same rewrite and it is easy to miss. Previously you could opt out of Entra Agent ID at the environment level. That option is gone. All new agents get Microsoft Entra Agent IDs and you can no longer opt out of automatic agent identity creation. There is also now a tenant-level object called the Microsoft Copilot Studio agent identity blueprint, added the first time an agent is created after the rollout, with a corresponding blueprint principal.

The Solution: an in-place conversion with a rollback

Here is the design decision worth slowing down for, and it is the one that makes the whole thing usable in a real tenant.

Migration converts an agent's existing app-registration identity in place. The agent keeps its application (client) ID. Everything downstream that resolves against that identifier, channel registrations and connectors among them, continues to resolve to the same value. The agent additionally gains an Entra Agent ID that administrators can manage.

You may be asking why that detail deserves its own paragraph. Frankly, the answer is simple: the alternative would have been catastrophic. An identity migration that issued a new client ID would break every channel registration, every connector configuration, and every downstream system that had that GUID written into a config file somewhere, all at once, across an entire estate. Keeping the client ID is what turns "a migration nobody will ever run" into "a migration you can pilot on Tuesday."

And it is reversible. There is a documented rollback that reverts an agent to its legacy app-registration identity, which means you can validate an agent after migrating it and put it back if it does not pass. A migration path with a documented way back is a rarer thing than it should be, and whoever fought for it deserves the credit.

What you get in exchange for the trip: a first-class agent identity that administrators can view and govern in Microsoft Entra, Conditional Access and other access policies designed for agentic workloads and scoped to agents rather than inherited from app registrations, and a consistent identity model across the services that work with your agents. The Conditional Access point is the substantive one. Writing a policy that targets agents specifically, rather than catching them incidentally because they happen to be applications, is a capability that did not exist before.

Why it matters

For makers, the honest answer is that this is not your job, but it will land on your calendar anyway. The documented process explicitly requires the administrator to coordinate a validation window with the makers who own the agents being migrated, and to wait for those makers to test before the next batch goes. If you own an agent, expect to be asked to exercise it across every channel it publishes to, run its actions and connectors, and confirm its authentication still behaves. Say yes and block the time. The alternative is finding out during the automatic migration, with nobody watching.

For professional developers and administrators, there are two pieces of work here. The near one is the pilot: identify eligible agents, migrate a representative handful, validate, expand. The further one is Conditional Access, and it is the more interesting of the two. Once agents are first-class identities in Entra, "which policies apply to our agents" becomes a question with an actual answer, and the documentation tells you to review Microsoft Entra sign-in logs including Conditional Access results before you widen a batch. That is a sentence with real work behind it, and it is the part I would start reading up on now rather than during the migration.

Two cautions, both from the documentation rather than invented by me. The manual migration process is currently a preview feature. And the documentation states plainly that migrating agent identities affects live agents and can disrupt authentication, connectors, and integrations if you do not plan the migration carefully. This is not a maintenance-window-free operation dressed up as one.

The demo concept

Not "watch an agent get migrated," because the interesting part of a successful migration is that nothing visible happens. The demonstration worth building is the evidence trail, and it has three parts.

Take one noncritical agent. Before you touch it, capture its application (client) ID and its Entra sign-in log entries. Migrate it through the API so you get the response object rather than a screen full of green checkmarks. Then capture the same two things again and put them side by side: the client ID identical, the agent now present in Entra as a service principal with the Agent subtype, and a sign-in log you can point a Conditional Access policy at. That before-and-after pair is the artifact that gets a change advisory board to approve the rest of the estate, and it is far more persuasive than any amount of documentation quoting.

Steps to recreate

First, the prerequisites, because two of them will stop you cold. You must be a Power Platform Administrator, Dynamics 365 Administrator, or Global Administrator. Power Platform inventory must be enabled for your tenant, because that is how Advisor identifies eligible agents. And you must coordinate a validation window with the makers who own the agents. That third one is not a technical prerequisite, but the documentation lists it as one, and I would treat it exactly that way.

The administrator path, through the Power Platform admin center

1) Sign in to the Power Platform admin center.
2) In the left navigation pane, select Actions.
3) Under Actions, select Recommendations.
4) On the Recommendations tab, select Active.
5) Search for and select Migrate Copilot Studio agents to Microsoft Entra Agent ID for enhanced agent governance.
6) In the recommendation pane, expand Why is this important? and read the migration guidance.
7) Review the eligible agents. Use the Suggested migration order and Migration notes columns to pick your pilot, and note that the table also gives you environment, environment type, owner, recent activity, and authentication method.
8) Select the checkbox next to each agent you want to migrate. The Migrate button becomes available and the action bar shows how many agents you have selected.
9) Select Migrate, review the confirmation, and confirm.
10) Review the Action, Action state, and Action date columns for each agent. The Action history tab shows actions across all recommendations.

Power Platform Admin Center

Then stop. Do not queue the next batch. Validate first, and the documentation is specific about what validating means: confirm the agent responds correctly in every channel where it is published, that its actions, connectors, flows and integrations run, that it authenticates as expected including any custom authentication, and that it behaves correctly with applicable agent access policies and Conditional Access policies. Then go read the sign-in logs for those agents in the Microsoft Entra admin center. If an agent fails validation, stop the rollout and revert that agent before continuing.

Keep in mind that Advisor recommendations can remain visible for up to a week after you act on them while the recommendation data refreshes. Seeing the recommendation still sitting there does not mean your migration did not take.

The API path, for when you want your own automation

The admin center is the recommended manual method, but there are Power Platform API endpoints if you would rather script it, and the documentation supplies the samples. Everything needs an OAuth2 bearer token for the Power Platform API:

$token = (Get-AzAccessToken -ResourceUrl "https://api.powerplatform.com").Token

A few things to note. This uses the Az PowerShell module, and the token has to be associated with an account holding one of the three admin roles listed earlier. There is no service-principal shortcut documented here, so if multifactor authentication or Conditional Access requires interactive sign-in, expect a browser window and complete the prompts. This is also the single most common failure in the troubleshooting table, listed as expired credentials or a token error.

To migrate one agent:

$token = (Get-AzAccessToken -ResourceUrl "https://api.powerplatform.com").Token
$environmentId = "<EnvironmentId>"
$botId = "<BotId>"
$uri = "https://api.powerplatform.com/copilotstudio/environments/$environmentId/bots/$botId/api/agentidentitymigration/migrate?api-version=2024-10-01"
Invoke-RestMethod `
  -Method Post `
  -Uri $uri `
  -Headers @{
    Authorization = "Bearer $token"
  }

A few things to note. The request takes no body, which surprised me the first time I read it: the agent is fully identified by the two IDs in the path. You get those two values from the agent inventory in the Power Platform admin center under Manage > Copilot Studio. The API version is pinned at 2024-10-01, so keep it, and note that this endpoint lives on api.powerplatform.com rather than any Copilot Studio host. The response is an AgentIdentityMigrationResult with a status of either Migrated or AlreadyMigrated, which means the call is safely idempotent. Running it twice does not do the migration twice, and that matters a great deal if you are looping over a list of agents and something times out halfway through.

A successful response looks like this:

{
  "status": "Migrated",
  "cdsBotId": "<bot-id>",
  "environmentId": "<environment-id>",
  "tenantId": "<tenant-id>",
  "agentIdentityId": "<agent-identity-id>",
  "applicationId": "<application-client-id>",
  "servicePrincipalObjectId": "<service-principal-object-id>",
  "managedIdentityId": "<managed-identity-id>",
  "completedAtUtc": "2026-08-21T12:00:00Z"
}

A few things to note, and this payload is the reason I would use the API even if I ran the migration from the admin center. Look at what comes back: applicationId, the client ID you can compare against what you captured before, and servicePrincipalObjectId and agentIdentityId, the handles you need to find this agent in Entra afterward. Log the whole object. It is your evidence trail, produced for free, and reconstructing it later from the portal is tedious work you would rather not do.

And to put one back:

$uri = "https://api.powerplatform.com/copilotstudio/environments/$environmentId/bots/$botId/api/agentidentitymigration/rollback?api-version=2024-10-01"
Invoke-RestMethod `
  -Method Post `
  -Uri $uri `
  -Headers @{
    Authorization = "Bearer $token"
  }

A few things to note. Same shape, same authentication, same absence of a body, and the same idempotent design: the response status is RolledBack or NotMigrated. Write this script at the same time you write the migrate script, not after something has gone wrong. A rollback you have already tested on a throwaway agent is a rollback you can actually reach for at four in the afternoon with a maker on the phone.

Companion repo sketch

A small runbook repository, honest about being a runbook. A scripts/ folder with three files and no more: Get-AgentInventory.ps1 to pull the agents and their environment and bot IDs, Invoke-AgentMigration.ps1 that takes a CSV of the batch and writes every response object to disk, and Invoke-AgentRollback.ps1 written first and tested first. A batches/ folder with the CSV per batch, so the pilot, the second wave and the long tail are separate committed files rather than a spreadsheet somebody is editing in place. An evidence/ folder holding the before-and-after client IDs and the raw JSON responses, because that is the artifact that survives the project. And a VALIDATION.md with the checklist from the documentation turned into tick boxes per agent: channels, actions, connectors, flows, integrations, custom authentication, access policies, Conditional Access.

Point the README at a nonproduction tenant for the first run and say so in bold. And put the troubleshooting table in there too, because the four failure modes Microsoft documents are the four you will hit: inventory returning no agents when Power Platform inventory is not enabled or your role is wrong, token and reauthentication prompts, agents skipped because they are already migrated or you left out an ID, and single-agent failures from eligibility, access, or throttling, where the answer is to wait and rerun.

Final Notes

What I keep coming back to is not the identity model, welcome as it is. It is that Microsoft shipped the migration runbook and the rollback and a troubleshooting table with four named failure modes, for a migration it is eventually going to run for you anyway. It did not have to do any of that. It could have flipped the switch on a Tuesday and let us all find out.

So take the invitation. Enable Power Platform inventory, open the Advisor recommendation, pick three agents nobody will miss, and run the pilot while the stakes are zero and the makers are available. The version of this project where you go first is a much better project than the version where you go last.

What I learned from this exercise: the most valuable sentence in a migration document is rarely the one describing the migration. It is the one telling you how to undo it.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Power Apps | Describe the App, Approve the Plan

2026-09-04T07:00:00.000-04:00

Every one of us who has stood up a model-driven app from nothing has lived the same first afternoon. You know the business process cold, you could describe it to a colleague in ninety seconds, and yet the next four hours go to clicking: a table, then its columns, then the relationships, then a main form, then two views, then a chart nobody asked for, then the sitemap, then the security roles you will get wrong the first time and fix on Thursday. None of that is thinking. It is transcription, and it is the reason so many good internal apps never get built at all.

Well, in late August a new article appeared in the Power Apps documentation that goes after that first afternoon directly, and it did not arrive alone.

Background

A brand new page landed in the MicrosoftDocs/powerapps-docs repository, dated 08/27/2026, and it is live on Learn:

Build and edit model-driven apps with AI code generation tools (preview)

What tells you this is a real shipped surface rather than a stray draft is the company it keeps. In the same set of changes, Steps to building a model-driven app and the Overview of the model-driven app designer both gained a TIP block pointing at the new article, the existing generative pages article gained a NOTE telling you which of the two skills to reach for, and the maker landing page and table of contents were amended to carry it. Microsoft does not wire four existing articles into a page it is not serious about.

Now, the thing itself. It is called the model app builder skill, and it runs inside an AI code generation tool such as GitHub Copilot CLI or Claude Code. A skill, in this context, is a packaged set of instructions and commands that teaches one of those tools how to perform a specific job. It is not a connector, and it is not a service you call. It is guidance the tool loads, plus the command-line plumbing to act on it. The distinction matters, because it means everything the skill does, it does as you, through tools you already have authenticated on your own machine.

What the skill actually produces

This is the part that surprised me, so let me quote the capability list rather than paraphrase it into something vaguer. The documentation says the skill can:

Create a model-driven app from a description of a business scenario.
Plan the app around user personas and the jobs they need to accomplish.
Create supporting tables, columns, relationships, forms, views, charts, and sample data.
Create generative pages for experiences that go beyond standard forms and views.
Create a sitemap with custom icons for each table.
Add JavaScript validation rules to forms.
Add security roles based on the planned personas and data access needs.
Edit an existing model-driven app by describing the changes you want.
Verify the deployed app against the approved specification.

Read that list twice. Security roles derived from personas. Sitemap icons and form validation created as web resources and wired to the right components during implementation. That is not a scaffolder producing a table and a form and calling it an app. That is the boring 80 percent of the first afternoon, including the parts people skip.

The Solution: the dry run is the whole feature

Here is where I would slow down, because the interesting design decision is not the generation. It is the gate in front of the generation.

The skill runs an interactive, multistep process, and the documentation is explicit about the order. You describe the business scenario, and the skill asks follow-up questions about users, data, workflows and the experience you want. It then presents an app spec: personas, jobs to be done, tables, relationships, forms, views, charts, JavaScript validation rules, generative page intents, and the sitemap with a proposed icon for each table. You review and refine that specification. Only then does it validate the spec and present a dry-run build plan, grouped by build phase, in the conversation. And then the sentence that carries the whole design:

No app artifacts are created until you approve the plan.

You may be asking why a plan step deserves this much attention when every generator ever built has had a preview mode. Very simple: the failure mode of an AI that writes to Dataverse is not a bad form. It is thirty artifacts you did not ask for, scattered across a solution, with a publisher prefix on all of them and no obvious way to tell which ones matter. A plan you can read and argue with before anything is written is the difference between a tool you can use in a real environment and a tool you can only use in a sandbox you are willing to throw away.

After the build, there is an optional verification step that compares the deployed app with the approved app spec. That is worth noticing too. "The build reported success" and "the app matches what I approved" are two different claims, and only one of them is worth anything on Monday morning.

NOTE: the editing path is the same skill and it works in reverse. Point it at an existing app and it retrieves the deployed app, builds an editable app spec from it, and then proposes changes against that spec. Which means the spec is not just an input format. It is a two-way representation of the app, and that is the part of this design most likely to still be here in three years.

Why it matters

For makers, this is genuinely for you, and that is a change from most of what lands in the developer docs. The article is tagged for makers and developers both, and the entry point is a sentence about your business process rather than a table designer. But be honest with yourself about the toolchain: this needs Node.js, the Power Platform CLI, the Azure CLI, and a terminal-based AI coding tool on your machine. If you have never opened a command prompt on purpose, the skill is not the barrier. The prerequisites are. That is a fair trade to know about up front rather than discover forty minutes in.

For professional developers, the claim worth weighing is the app spec. We have spent years arguing about how to describe a model-driven app in a form that survives review, diffing and source control, and the answers have all been either solution XML, which nobody enjoys reading, or a wiki page that goes stale in a week. A reviewable specification that generates the app and can be regenerated from the app is a different proposition. Whether the schema holds up is an open question, and the documentation says plainly that it might change between releases, but the shape is right.

Two cautions, both taken from the documentation rather than invented by me. This is preview, and Microsoft states that the app spec schema and command-line options might change between releases. And the skill does not support every model-driven app artifact or concept, so some of your app will still be built in the designers. The related warning is the one I would put on a sticky note: changes you make outside the skill can affect later AI-assisted edits, so before you approve another build, read the plan to confirm it preserves your manual customizations. An agent that regenerates from a spec has no idea what you changed by hand unless the spec caught it.

The demo concept

Not "watch it build an app," because a video of artifacts appearing proves nothing about whether they were the right artifacts. The demonstration worth building is the round trip, and it takes three moves.

Build a small app from a prompt and keep the approved app spec. Then go into Power Apps and change something by hand that the spec never knew about, a business rule, a column on a form, a tweaked view. Then ask the skill for an unrelated change and read the new plan carefully to see whether your manual work survives. That single observation is more useful than any amount of generation footage, because it answers the only question a working developer actually has: can I use this on an app I care about, or only on one I am willing to lose?

Steps to recreate

1) Get the prerequisites in place first. The documentation lists a current long-term support version of Node.js, Power Platform CLI (PAC CLI) 2.7.0 or later, the latest Azure CLI, and GitHub Copilot CLI or Claude Code. You also need a Power Platform environment where you can create and modify Dataverse and model-driven app artifacts, an authenticated PAC CLI profile pointed at that environment, and an authenticated Azure CLI session.

2) Make sure both authentications are the same person. This is the one prerequisite that reads like a footnote and behaves like a blocker:

az login

A few things to note. The documentation is specific that you run az login with the same identity used by the active PAC CLI profile. Two different accounts across the two CLIs is the classic way to get a confusing permission error much later in the run, long after you have forgotten which account each tool holds. Check the active PAC profile with pac auth list before you start, and if the two do not match, fix it now rather than at step six.

3) Install the plugin. There is a one-line installer that sets up all of the Power Platform plugins at once, in PowerShell:

iwr https://raw.githubusercontent.com/microsoft/power-platform-skills/main/scripts/install.js -OutFile install.js; node install.js; del install.js

A few things to note. This downloads a JavaScript file, runs it with Node, and deletes it, which is exactly the kind of command you should read before you run. The installer detects which supported AI code generation tools you have, registers the Power Platform Skills marketplace, installs the plugins, and turns on automatic updates. The source lives in the public microsoft/power-platform-skills repository, so you can read scripts/install.js first, and I would encourage you to do exactly that. There is an equivalent for a Windows command window:

curl -fsSL https://raw.githubusercontent.com/microsoft/power-platform-skills/main/scripts/install.js | node

4) Or install just the one plugin, which is what I would do the first time. These are slash commands typed into the AI coding tool's own chat, not shell commands:

/plugin marketplace add microsoft/power-platform-skills
/plugin install model-apps@power-platform-skills

A few things to note. The first command registers the marketplace, the second installs the Power Apps plugin from it, and the part after the @ is the marketplace name. Restart the tool afterward if it does not pick up the plugin on its own. For Claude Code specifically, the documentation points out that plugins can be installed at global, local or user scope, and that depending on the scope you must be in the correct directory for the plugin to load. If the skill appears to be missing, check where you are standing before you reinstall anything.

5) Build something. Start a conversation with the tool and invoke the skill:

/app-builder

Build an equipment inspection app for field technicians and dispatchers.

A few things to note. That example prompt is quoted from the documentation, along with "Build an app to manage supplier onboarding and contract approvals" and "Create a model-driven app for tracking service requests across multiple teams." Notice the shape they all share: a business process and the people in it, not a list of tables. That is deliberate, because personas are a first-class part of the app spec and they are what the security roles get derived from. You can also skip /app-builder and simply describe the app you want.

6) Then work the review, which is the part that earns the whole exercise. Answer the skill's questions about the process, users, data and workflows. Read the app spec and check that the personas, jobs to be done, tables, relationships, forms, views, charts, validation rules, generative pages, navigation and sitemap icons actually support the business scenario, and ask for revisions until they do. Read the dry-run build plan and approve it only when its proposed changes match your intent. Let it build. Take the optional verification step. Then open the app at make.powerapps.com, run its primary scenarios, and inspect the generated artifacts with your own eyes.

7) To edit an app you already have, invoke /app-builder again and name it:

/app-builder

Add an Invoices table and related forms and views to the Supplier Management app.

A few things to note. The skill asks you to confirm which existing app it should retrieve, then presents an editable app spec built from the deployed app, and then the same plan-and-approve cycle applies. This is the path where the caution about manual customizations bites, so read that plan properly rather than skimming for the word "success."

One more thing that landed in the same set of changes

The generative pages article picked up a genuinely useful capability that has nothing to do with AI coding tools, and it would be a shame to let it get buried: you can now embed a generative page inside a model-driven app form, in a section or a tab. Create and publish a generative page set up to accept the recordId input parameter, then:

1) Open the form in the form designer.
2) In the left pane, select Components, and then expand Display.
3) Select Generative page.
4) Select the generative page you want to embed.
5) Optionally, provide values for any additional static inputs the page accepts.
6) Save and publish the form.

When a user opens a record, the form passes the current record ID to the page as recordId automatically. You do not configure a static value for it. That is a small paragraph in the docs and a fairly large door, because it turns generative pages from a separate destination into something that lives on the record the user is already looking at.

Companion repo sketch

A lab repository built around the round trip rather than the generation. A prompts/ folder with the exact prompts in order, so somebody else can reproduce the run instead of taking your word for it. A specs/ folder holding the approved app spec from the first build and the regenerated spec from after the manual edit, because the diff between those two files is the finding. A plans/ folder with the dry-run build plans exactly as they appeared, including the one you rejected, since a lab that records only the approved plan is hiding the interesting half. A solution/ folder with the exported and unpacked solution so the generated artifacts show up as reviewable files. And a short FINDINGS.md that says which artifacts the skill got right, which it missed, and whether the manual customization survived, in plain language.

Point the README at a developer environment, say so loudly, and repeat it. This is preview software that writes schema. Nobody should be pointing it at production to find out what it does.

Final Notes

What I keep coming back to is that the headline feature of this skill is a document. Not the generation, which is impressive but is the part everybody expected. The app spec is the thing: a reviewable description of a model-driven app, produced from a conversation, editable by a human, capable of building the app and capable of being rebuilt from it. We have wanted that artifact for a very long time, and it is a little funny that it arrives as a side effect of teaching a coding agent to click the designers for us.

It is preview, so treat it accordingly. Read the installer before you run it, keep your two CLI logins on the same identity, use a developer environment, and read every plan before you approve it. And if you take one habit from the whole exercise, make it the verification step, because the gap between "it built" and "it matches what I approved" is where every automation story eventually gets interesting.

What I learned from this exercise: when a tool asks you to approve a plan, the plan is not a formality it added to be polite. It is the tool telling you exactly where the responsibility moves from the machine back to you.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Copilot Studio | Turning War Stories into Guardrails: Introducing pac-copilot-kit

2026-08-31T07:00:00.000-04:00

Let me start with the announcement, because some of you came for the tool and not the story, and that is perfectly fine.

Today I am releasing pac-copilot-kit, open source under MIT at github.com/dgpblogster/pac-copilot-kit. It is a paved-road toolkit for the Copilot Studio agent lifecycle, and it does exactly two things. First, capability: it creates Dataverse knowledge sources from code, inside your solution, repeatably, which is the one thing pac cannot do at all. Second, the paved road: it makes Microsoft's own ALM prescription executable, one guarded command from YAML on disk to a published agent, in a shell or in CI. The first is why you install it. The second is why you keep it.

The PowerShell module is on the PowerShell Gallery as PacCopilotKit, and an MCP server that exposes the same engine to Claude Code, GitHub Copilot, or Codex is on npm as pac-copilot-kit-mcp. Two commands and you are running:

Install-Module PacCopilotKit
npx -y pac-copilot-kit-mcp   # optional: the MCP door, for your AI agent

Issues and pull requests are welcome, and the war-stories document in the repository is the living inventory of every gotcha the tool guards against. If that is all you needed, go build something and let me know how it goes!

Now, if you brought popcorn, stay for the rest, because the story of why this tool exists is the more interesting half, and it includes one moment where the build caught its own author in an overclaim.

Where it came from

My last two Copilot Studio articles, one on wiring Dataverse knowledge sources with the Web API and one on the ALM loop that keeps an agent rebuildable, both ended the same way: with a list of war stories and their workarounds. The runtime that silently ignores your knowledge source. The pac auth profile that another workspace quietly re-points. The Quick Find view update that fails with an opaque error code. Each one cost me real hours, each one got written down, and I felt rather good about that.

Then a thought started nagging at me. A war story you have to remember is a war story you will eventually forget. Six months from now, in a different tenant, I will hit one of these again and I will not remember the article, and neither will you. Writing it down was necessary. It was nowhere near sufficient. So, this time around, I turned the whole inventory into a tool.

From paragraphs to guardrails

The idea fits in one sentence: every war story becomes something that executes. Not documentation you consult, but a check that runs, refuses, and tells you why. I call them guardrails, and as it turns out, they come in exactly two flavors. Preflight checks refuse before anything is touched: the runtime trap and the authentication requirement from the knowledge article, the profile drift from the ALM article, each now a refusal with the fix named in the message. Error translators let a call happen and catch a known failure on the way back: when the infamous 0x80040216 shows up on a savedquery update, you get the war story and the working alternatives, not the opaque code.

Every guardrail lives under a contract from day one: one file, one test proving the failure it prevents is real, and one plain-language entry in a war-stories document that travels with the code. No entry, no guardrail. The document I would have written anyway now cannot drift from the code, because the code refuses to exist without it. And every refusal carries a typed exit code whose range means something: 10 through 19 says your environment is misconfigured, 20 says you asked for a route the platform is known to break. You may be asking why anyone should care about an exit code taxonomy. Very simple: CI cares. A pipeline that can tell "the environment is wrong" from "the operation failed" is one a human can diagnose from the log line alone.

The natural home for all of this was a PowerShell module. But I work with an AI coding agent driving a lot of the platform interaction now, and an agent cannot benefit from a guardrail it cannot see, so the same engine got a second door: the MCP server, seven task-shaped verbs over the same guardrails. My favorite is the one with no cmdlet behind it, explain-failure: when any operation is refused, the agent can ask what just happened and gets the war story, the fix, and a warning against working around the refusal, straight from the exit code registry, without another round trip.

NOTE: I did not build this alone, and pretending otherwise would be strange in 2026. I paired with an AI coding agent (Claude Code, for the record) for the entire build. Keep in mind the division of labor, though: every platform fact in the tool was verified against a live environment before it was allowed to ship, because an AI pair is exactly like every other tool in my shop. Trust, but verify.

How my own tool tried to lie to me

Once the first guardrails were in place, we ran a red team pass against our own code: thirteen tests written to attack the guardrails the way a careless caller would, written before any fixes, expected to fail. Seven landed. Seven! The worst were bypasses of the flagship guardrail, which watched for savedqueries( at the start of a request path. The very same forbidden request sailed right past it spelled as an absolute URL, or with a leading slash, or with the payload as a raw JSON string. Four spellings of one request, and the guardrail caught exactly one. Now, you may be thinking the fix is three more string checks. It is not! The fix was structural: normalize every request into one canonical shape before any check sees it, so the whole class of bypass dies at once. Suffice to say, every guardrail now gets a bypass hunt, red first, before it ships.

What live verification taught me, including about my own articles

The unit suite proves the code does what we intended. The live runs proved something better: that one of my published claims was too broad, and that the platform had two more surprises waiting. Three findings, in ascending order of embarrassment.

First, the drift guardrail caught me. Me! The very first live pipeline run refused to deploy, because the active pac profile on my machine pointed at a completely different environment than the one I had pinned. The founding war story of the whole effort, firing on its author on day one. I could not have scripted a better validation.

Second, my savedquery claim did not survive a third environment. I reported that the fetchxml update fails on every route, reproduced in two orgs. The integration test then found views that accept the very same call. We spent an afternoon hunting the discriminator: custom versus system table? No. The search index flag? No. Standard versus virtual versus elastic? Also no. The honest current claim is that the failure reproduces on most Quick Find views while a minority accept the call, and the discriminator is not yet identified. The guardrail was redesigned that same day, from refuse-up-front to attempt-and-translate, because refusing a route that sometimes works is its own kind of bug. If you figure out what separates the two, the comments are open and I will credit you properly!

Third, and this one should worry every CI pipeline you own: pac can print an error and hand your shell a success code. Three times in one session, the CLI wrote a clear Error: line and returned 0: an argument error twice, and an environment resolution failure. Any pipeline gating on the exit code treats all three as success and keeps right on going. Before publishing that sentence I wanted to know which part of pac was doing it, so I ran the same failing command two ways. Through the MSI-installed pac on my PATH, a two-line wrapper that calls pac.launcher.exe: error printed, exit code 0. Through the versioned pac.exe underneath it: same error, exit code 1. As it turns out, pac itself tells the truth. It is the launcher that discards the exit code, on every command I tried, and that launcher is version 1.0.7 with a file date of September 2019, still shipping in the current installer. A seven-year-old shim, silently defeating a command Microsoft documents as safe to run in a build pipeline!

This is not new. It sits on Microsoft's tracker as issue #912 (the launcher) and issue #1027 (the symptom, with other users chiming in), both still open as I write this, and I have added the isolation above to the thread. In the meantime the tool refuses to believe a zero exit code when the output carries an Error: line, and I would gently suggest your scripts do the same, or install pac as a dotnet tool, which skips the launcher entirely. The lesson generalizes: verify the exit codes of every CLI you automate, through the exact path your pipeline will call, because a wrapper on the PATH can defeat a perfectly honest executable underneath it.

The bottom line

A war story is a liability until it is executable. The moment the savedquery story became a guardrail with a test, the test caught my own overclaim, and documentation cannot do that. That is the whole reason pac-copilot-kit exists, and the discriminator hunt from finding number two is genuinely open, so if you run it against your own environments, I would love to hear what you find.

My next installment will be the one I promised last time: the walk from proof of concept to production, with the actual promotion done rather than theorized. Stay tuned!

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Copilot Studio | Real ALM for Agents (and the One Click That Breaks Your Pipeline)

2026-08-28T07:00:00.000-04:00

In my previous Copilot Studio article, I was working on a support agent grounded in Dataverse knowledge articles and a custom table of curated case resolutions, and I showed how to wire those knowledge sources up with the Web API rather than clicking them together in the maker portal. What I did not explain there is why I cared so much about scripting them in the first place.

The reason is a question every consultant eventually asks about a sandbox: what happens to all of this when somebody refreshes the environment from production? The answer, of course, is that it all goes away. The agent, its topics, its knowledge sources, the custom table behind them, all of it. And the honest follow-up is the question that actually matters: how long would it take me to build it back?

If the answer is "about a week, and I would probably forget something," then what you have is not a project. It is a sandcastle! So, in this article I will walk through the lifecycle loop I settled on for a Copilot Studio agent, score it honestly against what Microsoft prescribes today, and show you the three places where the prescribed path quietly runs out of road. All three are documented by Microsoft, in public, and not one of them is where you would expect.

What Microsoft actually prescribes

Let me start by being fair to the guidance, because it is good guidance and I follow most of it. Microsoft's ALM story for Copilot Studio agents is solutions, and it has not wavered: the documentation is explicit that to move an agent between environments you need a custom solution rather than the default one. On top of that sits a set of ALM golden rules familiar to anyone who has shipped a model-driven app: work in solutions, use a custom publisher and prefix, use environment variables for anything that changes between environments, deploy as managed downstream, and automate it all with source control. Microsoft also states a floor: at least three environments, development, test, and production.

Alongside that, there is now a genuine authoring story for code-first people. The Visual Studio Code extension is generally available, the pac copilot command group gives you a local workspace of YAML files, and the pitch includes Git and pull requests. Suffice to say, this is a real improvement over clicking everything in a portal and hoping.

NOTE: read the banner at the top of those pages. Every ALM and code-first article I could find says the features described are powered by the standard harness. If you are building in the newer agent experience, hold that thought.

The loop I actually ran

Here is the cycle, start to finish. Nothing exotic, and that is rather the point:

pac copilot init                          # scaffold a local agent workspace
# author agent.mcs.yml, settings.mcs.yml, topics/*.mcs.yml
# validate every file offline, before anything touches the tenant
pac copilot pack --publisher-prefix wrk --solution-name WorkbenchSupportAssistant
pac solution import --path .\WorkbenchSupportAssistant.zip --publish-changes
git add . && git commit

A few things to note here. The offline validation step is mine, not Microsoft's, and it is the single highest-value habit in the loop: a Power Fx string containing a colon followed by a space parses wrong and surfaces as strange runtime behavior rather than an error, and catching that locally costs a second where catching it after deployment costs an afternoon. pac copilot pack is the interesting one: Microsoft documents it as a purely local operation that needs no authentication and no environment, which makes it, in their own words, safe to run in a build pipeline. Hold that thought too. And then, always, a commit. That repository is not a nicety. It is the recovery plan.

Scoring myself against the golden rules

Golden rule	What I did
Always work in the context of solutions	Followed. Everything packs and imports as one solution.
Use a custom publisher and prefix	Followed, from day one.
Use environment variables for what changes between environments	Followed to the letter. The escalation address lives in an environment variable, never in a topic node.
Do not customize outside a development environment	Followed, though see below, because I only had one.
Create separate solutions only when you need independent deployment	Followed. One solution.
Automate ALM with source control	Followed, and then some.
Deploy as managed downstream	Not followed. Unmanaged only.

Six out of seven, and the miss is not laziness. It follows from a platform constraint that will hit you too: Copilot Studio's Dataverse knowledge sources only read the agent's own environment. My agent had to be grounded on data that lived in one specific environment, so the agent had to live there as well. That collapses the three-environment model into one, and with nothing downstream to deploy to, managed solutions buy you nothing but ceremony. That is a limitation of my situation, not a flaw in the guidance. Keep in mind, though, that "the data only exists in one place" is an extremely common shape for a grounded agent, and the standard ALM advice does not really account for it.

Where the prescribed path runs out

Three gaps, and I found all three the hard way before finding them in the documentation afterward.

First: the command built for pipelines has no pipeline. Microsoft explicitly documents pac copilot pack as safe to run in a build pipeline, so I went looking for the pipeline that accepts it. Let me be precise, because this claim deserves precision: agents are solution components, so the generic solution tasks deploy one just fine, and Microsoft's Build Tools FAQ says as much. What the Power Platform Build Tools task list does not contain is anything that knows an agent from a canvas app: no task wraps pac copilot, and the only "agent" in that reference is the build agent running the job. GitHub Actions for Power Platform is the same story. I could not find a single Microsoft sample pipeline that runs pac copilot pack followed by pac solution import. You can build it yourself, and it is not hard, but the CLI was designed for CI, documented for CI, and the CI tooling has not caught up.

Second: the newer agent experience has no documented lifecycle at all. Copilot Studio now ships more than one runtime, and I wrote last time about how that split silently breaks knowledge grounding. It splits the ALM story more sharply. Every solutions, import/export, and code-first article carries the standard-harness banner, and the newer experience's documented lifecycle is create, build, test, publish, monitor, all inside a single environment. No promotion, no solutions, no source control story. There is a related asymmetry worth knowing: in the newer experience each publish creates a new version, which the documentation frames as a way to tell the live release from newer drafts. That is a counter, and I found no documented way to browse history or restore a previous version; rollback lives at the solution layer instead. So an agent can carry two unrelated version numbers, and only one can take you backward. I will say only what I can defend: I found no documentation of a restore capability, which is not the same as proving there is none.

Third, and this is the one that changes how you should build: there is a manual click in the middle of the automated path.

The one click that breaks your pipeline

Microsoft publishes a troubleshooting article for agents whose components go missing after a solution import. The symptoms it lists are topics, environment variables, tools, child agents, and, yes, knowledge sources, all present in the source environment and absent in the target. The cause it gives is that the imported solution does not automatically include components added to the agent's source solution after the fact. The prescribed fix is to open the agent's commands menu, choose Advanced, select Add required objects, and export again, and the instruction is explicit that you repeat this before every export.

Read that as an operations person rather than a maker. The fidelity of your deployment depends on a human remembering to click something in a portal before every export. There is no CLI equivalent I could find, and no pipeline step, so your automated deployment has a manual precondition that fails silently when skipped. Nothing errors. The solution imports cleanly. The agent simply answers as though a knowledge source it needs was never there.

NOTE: the documentation is candid about the general shape of this. The import and export guidance says outright that some components, custom topics and knowledge sources among them, might not be included depending on how they were created or linked; there is a published list of things that are simply not solution-aware (Application Insights settings, manual authentication, Direct Line and web channel security, deployed channels, sharing); and after any import you must reconfigure authentication and publish before sharing. None of it is hidden. It is just easy not to go looking until something breaks.

Why scripting the components sidesteps all of it

In the previous article I showed that a Dataverse knowledge source is really four ordinary Dataverse records, and that one header on each create call, MSCRM.SolutionUniqueName, lands them inside your solution. That was written as a way around a tooling limitation. It turns out to be the whole answer to the click.

The knowledge wiring in this project is a PowerShell script. It takes a token from the signed-in Azure CLI, talks to the Dataverse Web API directly, and creates the custom table, its columns, the table search configurations, the knowledge-source components, and the associations between them, every call carrying that header. The shape is the part worth stealing:

$org   = "https://yourorg.crm.dynamics.com"
$token = (az account get-access-token --resource $org | ConvertFrom-Json).accessToken

$headers = @{
  Authorization             = "Bearer $token"
  "Content-Type"            = "application/json"
  "MSCRM.SolutionUniqueName" = "WorkbenchSupportAssistant"   # every call. no exceptions.
}

$search = Invoke-RestMethod -Method Post -Headers $headers `
  -Uri "$org/api/data/v9.2/dvtablesearchs" `
  -Body (@{ name = "wrk_case_resolutions_search" } | ConvertTo-Json)

A few things to note here. The token comes from the Azure CLI, so there is no credential in the script and nothing to rotate in source control. The solution header sits in the shared $headers block rather than being passed per call, which is the whole discipline in one line: you cannot forget it on the fourth create if it was never optional to begin with. And it deliberately depends on no pac state whatsoever, because pac authentication profiles are machine-global rather than per-project, and I have had a different workspace on the same laptop quietly re-point the profile my project was using. A recovery script that assumes the CLI is still aimed where you left it is a recovery script that fails on the one day you need it.

Because the knowledge sources come from a script I can run again, I never depend on a solution remembering them. The failure mode Microsoft documents cannot happen to a component I rebuild from source in ninety seconds. The same goes for the custom table, its columns, and the flow behind the escalation topic, which had to be created with a direct call to the Dataverse workflow endpoint carrying that same header, because the tooling I first reached for created a flow that never appeared in the solution at all.

And when something resists the API entirely, there is one more door. Last time I noted that updating a Quick Find view's find columns through the Web API fails with an opaque error, and that the maker portal was the fastest way through. Here is the part I promised to come back to: the same change can be made at the solution level, without clicking anything.

pac solution export --name WorkbenchSupportAssistant --path .\out
# unzip, edit the savedquery block in customizations.xml, re-zip
pac solution import --path .\WorkbenchSupportAssistant.zip --publish-changes

I have come to think of this as solution surgery, and the safety rule is the whole trick: a Quick Find view is an ordinary Dataverse view, not an agent component. Microsoft warns that changing an agent's components directly inside the solution breaks export and import, and that warning is correct and worth obeying. The rest of the solution is ordinary Power Platform metadata and behaves accordingly. Keep in mind the import round-trips everything else in the solution, so if you have a flow in there, verify afterward that it came back activated. Mine did, but I checked.

What this approach costs, honestly

The scripts are real code, and real code needs maintenance. They encode undocumented record shapes that can change in any release, so my recovery plan has a shelf life and needs re-verification rather than blind trust. I gave up managed solutions, and with them the layering protections that stop someone editing production by hand. Parts of what I built sit outside the supported path, which is a fine place for a proof of concept and a rather different proposition for production. And I gave up the three-environment model, so I have no test environment standing between an idea and the only environment that exists, and I want to be blunt that source control does nothing whatsoever about that.

That last point deserves precision, because I have seen it oversold. What all of this bought me is that the environment became replaceable, not unnecessary. Rebuildability protects you from losing work; a test environment protects you from breaking something in front of people, and those are two different problems with two different answers. Anyone who tells you a tidy repository removes the need for proper environments is selling you something. Here is what reconciles the two, though, and it is why I would do it all again: being able to rebuild the whole agent from source is precisely what makes a second environment cheap. When everything comes back by running a script, standing up a test environment stops being a project and becomes an afternoon pointed at a different URL. The discipline that looks like a substitute for the three-environment model is actually what makes it affordable.

So what does production actually look like?

Which is the question you are probably asking from inside your own proof of concept, and it has three answers worth knowing now.

Placement is not a choice. Dataverse knowledge reads only the agent's own environment, so the production agent lives in production, right alongside live customer data. Promoting a grounded agent is not like promoting a self-contained app into a tidy empty environment; you are placing an agent inside your live business system, and every decision about what it can see and say gets more serious the moment you do.

The solution carries less than you would hope. The agent, its topics, your table's schema, the environment variable definitions, and your flows travel. Authentication, deployed channels, sharing, and Application Insights settings do not, so a production deployment ends with an afternoon of hand configuration, plus pointing your environment variables at real values instead of the test address you have used since day one.

Your curated knowledge is data, not schema. The table definition rides along in the solution; the reviewed content in it does not. So you choose between regenerating that content against production data and migrating the rows you already reviewed, and as it turns out, regeneration is the tempting answer and probably the wrong one, because synthesis is not deterministic and re-running it discards the editorial judgement that was the expensive part. Migrate the reviewed rows, including the ones you deliberately rejected, so the audit trail stays intact.

NOTE: one sequencing trap. You cannot convert an unmanaged solution into a managed one in place. A development environment holding your work unmanaged is exactly right, and you export managed from it into production. But if you ever decide that environment should instead receive managed solutions, the unmanaged solution has to come out first, and it takes your agent with it. Decide what each environment is for before the first managed export, not after.

And then there is the part that is not really an ALM question at all: the guardrail work a sandbox lets you write down as caveats and a production rollout does not. That deserves its own article rather than a paragraph, so consider this the honest state of play. I know the shape production takes, I know which parts of my proof of concept were a loan rather than a discount, and the walk from one to the other is something I will be exploring in a future article, with the actual promotion done rather than theorized. Stay tuned!

The bottom line

Microsoft's ALM prescription for Copilot Studio agents is sound, and I followed six of its seven golden rules without argument. But the guidance assumes a shape of project that a grounded agent frequently cannot have, the tooling stops one step short of the automation it openly advertises, and the step that guarantees your components actually travel is a click somebody has to remember before every single export.

So my rule ended up simple enough to fit on one line: the repository defines the agent, and an environment is a place I can put it. One environment today, because the data gave me no choice. Two on the way to production, because promotion demands it. And the reason the second one will cost an afternoon rather than a fortnight is the same discipline that made the first one survivable.

If you have automated a Copilot Studio agent deployment end to end, especially if you have found a way to handle the add-required-objects step without a human in the loop, please drop a note in the comments describing how. That is the piece I would most like to stop doing by hand.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Copilot Studio | Adding Dataverse Knowledge Sources with the Web API (the "UI-Only" Rule That Isn't)

2026-08-26T07:00:00.000-04:00

Not long ago, I set out to build a support agent in Microsoft Copilot Studio for a product in the Dynamics ecosystem: the kind of agent that answers customer questions grounded in your content, meaning Dataverse knowledge articles plus a custom table of curated case resolutions. No web browsing, no model knowledge; the knowledge sources are the agent's entire world. And since I treat agents as code (YAML in source control, pac copilot pack, solution import, repeatable deployments), I ran head-first into a wall you may have hit yourself:

Dataverse knowledge sources can only be added through the Copilot Studio UI.

That is what the documentation implies, that is the line the community tooling holds, and pac copilot pack enforces it: put a Dataverse source definition in your workspace's knowledge/ folder and pack rejects it outright. Public website sources? Fine in YAML. SharePoint? Fine. Dataverse tables, the one source type that lives in the same platform as the agent itself, are clicks only.

Except, as it turns out, that is not quite true. Copilot Studio is built on Dataverse. Every knowledge source you click together in the maker portal materializes as plain Dataverse rows, and anything that is plain Dataverse rows can be created with the Web API: inside a solution, from a pipeline, repeatably. So, in this article I will walk through the recipe, battle-tested twice now: once in a production-grade Dynamics 365 CE org, and once in a freshly provisioned vanilla environment, where it surfaced several extra lessons you will want in hand before trying this yourself.

⚠️ NOT OFFICIALLY SUPPORTED: none of this is documented or supported by Microsoft. These are the shapes Copilot Studio happens to write today, discovered by inspecting what the maker UI creates, and they can change in any release. Use this for dev and ALM automation with your eyes open, and always verify the result in the maker portal afterward.

First, which kind of agent? (This one matters)

Copilot Studio now ships two agent runtimes, which Microsoft calls harnesses. The standard harness is the classic experience: topics, the full Knowledge pane, solution-first ALM. The GitHub Copilot harness is the new streamlined agent builder, with its Build, Preview, and Evaluate tabs and a model picker.

Dataverse knowledge is a standard-harness feature. The new experience does not offer Dataverse in its Add knowledge dialog at all, and here is the trap that cost me an evening: if you create your knowledge component via the API against a new-experience agent, the Knowledge panel will happily display it (the panel reads the same component table) while the runtime silently never queries it. The agent will cheerfully answer from its own general knowledge and tell you it has no documents. No error anywhere!

The trap in action: the new experience displays the API-created Dataverse source in its Knowledge panel...

...but its runtime never queries it. Note the answer opens with "I don't have any device docs or network data in this workspace" while the source sits right there in the panel.

So check your agent's runtime before wiring anything, as follows:

GET /api/data/v9.2/bots?$select=name,schemaname,template

A template of default-2.1.0 (or a similar default-*) means the standard harness; proceed. A template of cliagent-1.0.0 means the new experience, and this recipe will not ground there. To build standard-harness agents, flip the "New experience" toggle off on the Copilot Studio homepage, or pick "Other ways to build."

NOTE: a fun fact discovered along the way. In the new experience, the default "Search all websites" knowledge chip is not a knowledge source row at all; it is an enableWebSearch flag inside the bot's configuration JSON. Different harness, different bookkeeping.

Why bother?

If you are happy clicking the UI once, close this tab with my blessing. But if any of the following apply, read on:

Your dev environment is a sandbox that gets refreshed from production periodically, wiping everything you built. Mine was! With the agent rebuildable from a git repository, knowledge sources included, a refresh becomes a non-event instead of a lost week.
You deploy the same agent to multiple environments and want identical knowledge wiring in each without a click-checklist taped to the monitor.
You want knowledge sources inside your solution, versioned and transported like everything else you ship.

Finding the shapes: mirror a working example

The trick that unlocked everything is almost embarrassingly simple: find a working reference implementation in the same environment and mirror its record shapes. If your org runs Dynamics 365 Customer Service, Microsoft's own first-party copilots ship as solution components, and their Dataverse knowledge sources are sitting right there in the very same tables yours will use; that is what I mirrored. In a clean environment with no first-party copilots, make your own reference: click one knowledge source together in the UI, then query what it wrote. Either way, the shapes reveal themselves:

GET /api/data/v9.2/botcomponents?$filter=componenttype eq 16
  &$select=name,data,schemaname

Four moving parts emerge from that inspection:

Piece	What it is
`dvtablesearch`	A named "table search" configuration: the knowledge source's identity
`dvtablesearchentity`	A child row per table being searched, pointing at its parent via the `DVTableSearch` navigation property and naming the table in `entitylogicalname`
`botcomponent` (componenttype 16)	The agent-side knowledge component; its `data` column holds KnowledgeSourceConfiguration YAML whose `skillConfiguration` names the `dvtablesearch`
`botcomponent_dvtablesearch`	The N:N association tying the component to the search config

A few things to note before we build. First, the component attaches to your agent through its parentbotid lookup, and not, as you might reasonably guess, through the bot_botcomponent N:N relationship. That relationship exists in the schema, but for knowledge components it stays empty; the parent lookup is what the platform actually uses. Ask me how long that one took! Second, on naming, because it bit me: dvtablesearch.name is a machine-style identifier (the component YAML references it verbatim), while the friendly display name your makers see in the Knowledge tab lives on the botcomponent.name. Keep them distinct on purpose.

Step 0: the custom table (if you are grounding on one)

My scenario grounds the agent on a custom curated-resolutions table. If you only need standard tables like knowledgearticle (which, by the way, is a base Dataverse table, present even in environments without any Dynamics 365 apps), feel free to skip ahead to Step 1. Otherwise, three gotchas await, and the third one is the difference between an agent that grounds and one that shrugs.

Gotcha 1: Memo columns want an explicit format. Declare Format: TextArea on each MemoAttributeMetadata. That is plain multi-line text, which is what the knowledge indexer expects, and a working column reads back with both Format and FormatName as TextArea. Here is the whole table, one create:

POST /api/data/v9.2/EntityDefinitions
MSCRM.SolutionUniqueName: WorkbenchSupportAssistant

{
  "@odata.type": "Microsoft.Dynamics.CRM.EntityMetadata",
  "SchemaName": "wrk_caseresolution",
  "DisplayName": { "LocalizedLabels": [ { "Label": "Case Resolution", "LanguageCode": 1033 } ] },
  "DisplayCollectionName": { "LocalizedLabels": [ { "Label": "Case Resolutions", "LanguageCode": 1033 } ] },
  "OwnershipType": "UserOwned",
  "HasActivities": false,
  "HasNotes": false,
  "SyncToExternalSearchIndex": true,
  "Attributes": [
    { "@odata.type": "Microsoft.Dynamics.CRM.StringAttributeMetadata",
      "SchemaName": "wrk_title", "IsPrimaryName": true, "MaxLength": 300,
      "RequiredLevel": { "Value": "ApplicationRequired" },
      "DisplayName": { "LocalizedLabels": [ { "Label": "Title", "LanguageCode": 1033 } ] } },
    { "@odata.type": "Microsoft.Dynamics.CRM.MemoAttributeMetadata",
      "SchemaName": "wrk_symptom", "Format": "TextArea", "MaxLength": 4000,
      "DisplayName": { "LocalizedLabels": [ { "Label": "Symptom", "LanguageCode": 1033 } ] } },
    { "@odata.type": "Microsoft.Dynamics.CRM.MemoAttributeMetadata",
      "SchemaName": "wrk_resolution", "Format": "TextArea", "MaxLength": 10000,
      "DisplayName": { "LocalizedLabels": [ { "Label": "Resolution", "LanguageCode": 1033 } ] } }
  ]
}

One POST, one 204, done! And notice SyncToExternalSearchIndex: true riding along in the create payload. Which brings us to...

Gotcha 2: Dataverse search must be on, and the org-level flag is just a column. Copilot Studio's Dataverse knowledge rides Dataverse search. The admin-center setting (now two checkboxes in the modern admin UI, one for "AI and agent experiences" and one for the global search bar) ultimately reflects a boolean on the organization record, and yes, you can flip it via API:

The modern admin center splits search indexing into two scopes; the first checkbox ("AI and agent experiences") is the one Copilot Studio knowledge rides on.

PATCH /api/data/v9.2/organizations(<orgid>)
{ "isexternalsearchindexenabled": true }

But budget real time for what happens next. On a freshly provisioned environment, initial index provisioning took about two hours before my rows became searchable. And do not trust GET /api/search/v1.0/status to tell you how it is going; it reported "0 tables indexed" even while queries were returning hits. The only reliable readiness probe is an actual query:

POST /api/search/v1.0/query
{ "search": "scanner", "entities": ["wrk_caseresolution"], "top": 5 }

For a table that already exists and needs the sync flag flipped, resist the urge to PATCH the entity definition, because metadata entities cannot be updated with PATCH. Updates replace the whole definition: GET it, modify, PUT the entire document back with an MSCRM.MergeLabels: true header (or kiss your localized labels goodbye, since omitted properties reset to their defaults), then call the PublishXml action. You may be asking whether all that ceremony is really necessary for one boolean. It is! Which is exactly why you set it at create time.

Gotcha 3: find columns ARE the search index. This is the one that separates "source attached" from "agent grounded." Dataverse search indexes the columns configured as find columns on the table's Quick Find view, and a fresh custom table's Quick Find view has exactly one: the primary name. Your beautiful Symptom and Resolution text? Invisible to search, and therefore to your agent, until they are added.

NOTE: and here is the kicker. Updating the view's fetchxml via the Web API fails with an opaque 0x80040216 on every route I tried (record PATCH, single-property PUT), in two different orgs, while layoutxml on the very same record updates fine. Whatever message the maker UI sends, the Web API's savedquery update path is not it. Budget one manual click-step: go to Power Apps, then Tables, then your table, then Views, open the Quick Find view, click Edit find table columns, add your text columns, and Save and publish. That is the fastest route, and it is the one I used here. Now, it is not the only route: the same change can be made at the solution level, by exporting the solution, editing the view definition inside it, and importing it back, which automates cleanly. That belongs to a bigger story about treating agents as source-controlled artifacts, and it is where I am headed next!

Seed a few rows while you are here. An empty table grounds nothing!

Step 1: create the `dvtablesearch`

First surprise: the entity-set name is dvtablesearchs. Yes, really, that plural! Ask $metadata if you do not believe me; I did, twice:

POST /api/data/v9.2/dvtablesearchs
MSCRM.SolutionUniqueName: WorkbenchSupportAssistant

{ "name": "wrk_case_resolutions_search" }

That single property is genuinely the whole payload; verified. Machine-style name, remember: this exact string gets referenced by the component YAML in Step 3. And keep an eye on that MSCRM.SolutionUniqueName header, because it is doing quiet but important work in every call in this article. It lands each row in your solution instead of the default one, which is the whole ALM point of the exercise.

Step 2: add the table(s) to it

One dvtablesearchentity per table the source searches, bound to its parent via the single-valued navigation property, as follows:

POST /api/data/v9.2/dvtablesearchentities
MSCRM.SolutionUniqueName: WorkbenchSupportAssistant

{
  "entitylogicalname": "wrk_caseresolution",
  "DVTableSearch@odata.bind": "/dvtablesearchs(<dvtablesearch-guid>)"
}

Step 3: the `botcomponent` that makes it a knowledge source

This is the piece that surprises people: the knowledge source your agent sees is a botcomponent row of componenttype 16 whose data column is... YAML. A KnowledgeSourceConfiguration document whose skillConfiguration property names the dvtablesearch from Step 1, and whose parentbotid lookup attaches it to your agent, all in one create:

POST /api/data/v9.2/botcomponents
MSCRM.SolutionUniqueName: WorkbenchSupportAssistant

{
  "name": "Curated Case Resolutions",
  "componenttype": 16,
  "schemaname": "wrk_WorkbenchSupportAssistant20.knowledge.wrk_case_resolutions",
  "data": "kind: KnowledgeSourceConfiguration\nsource:\n  kind: DataverseStructuredSearchSource\n  skillConfiguration: wrk_case_resolutions_search\n",
  "parentbotid@odata.bind": "/bots(<bot-guid>)"
}

That data YAML, unfolded so you can actually read it:

kind: KnowledgeSourceConfiguration
source:
  kind: DataverseStructuredSearchSource
  skillConfiguration: wrk_case_resolutions_search

A few things to note here. The schemaname follows the convention <botSchemaName>.knowledge.<componentName>, and that is the bot's schemaname, which you should read rather than guess: the same GET /bots from the harness check gives it to you, and agents created in the new experience even carry a random suffix in theirs. And the friendly name is what your makers will see in the Knowledge tab, so make it read like a knowledge source, not like a database object.

Step 4: tie the component to the search config

The N:N association that closes the loop:

POST /api/data/v9.2/botcomponents(<component-guid>)/botcomponent_dvtablesearch/$ref

{ "@odata.id": "https://yourorg.crm.dynamics.com/api/data/v9.2/dvtablesearchs(<dvtablesearch-guid>)" }

Verify like the maker UI is watching

Open the agent in Copilot Studio and go to the Knowledge page. Your source should be listed exactly as if you had clicked it together: name, table, status. Then comes the real test, and no publish is needed. Go straight into the test canvas and ask a question only your table can answer.

When it works, it really works! My test agent answered a scanner-connectivity question with the exact resolution from the seeded row, three citations pointing at wrk_caseresolution records, and the canvas's activity map showing the knowledge searches with "Curated Case Resolutions" as the referenced source. Grounded, cited, and not one of those records touched by a mouse.

The payoff: the activity map traces three knowledge searches, the inspection panel quotes the seeded resolution verbatim, and the answer carries three citations into wrk_caseresolution; every one of those records created by the Web API.

Two behavioral notes for Dataverse sources generally, both documented but easy to miss:

Same environment only. Copilot Studio's Dataverse knowledge reads the agent's own environment. If your data lives in environment A, the agent lives in environment A. Plan placement before you scaffold.
End-user authentication must be "Authenticate with Microsoft." Dataverse sources ride the end user's identity; "No authentication" and "Authenticate manually" agents will not search them, and the docs are explicit about this one.

The bigger picture

Everything Copilot Studio's maker portal does lands in Dataverse tables, and a surprising amount of the "UI-only" surface is only UI-only until you look at what the UI writes. The same technique has bailed me out more than once: find where the platform stores it, mirror the shape, create it in your solution. In turn, it converts "click this checklist in every environment" into "run the deployment," and that is the difference between an ALM story with an asterisk and one without.

One more time, because it matters: these are undocumented shapes, subject to change, so verify in the portal after every deployment. But with that caveat honored, a source-controlled agent is rebuildable end to end, knowledge sources included, and that is always a good thing.

If you have automated your own way around a "UI-only" corner of Copilot Studio, or if these shapes have already drifted by the time you read this, please drop a note in the comments describing what you found; undocumented territory is exactly where comparing notes pays the most.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Power Automate | Cloud Flow Telemetry with Azure Application Insights, Down to the Action Level

2026-08-24T07:00:00.000-04:00

Longtime readers may remember that the very last article I published before this blog went quiet, back in August of 2021, covered monitoring Power Apps with Azure Application Insights. So it is only fitting that I return to the subject from the other side of the platform: getting cloud flow telemetry out of Power Automate and into Application Insights, down to the action level.

I will be honest about why I am writing this one. When I went looking for how this integration works, the picture I pieced together from searching around was incomplete, and once I configured it and read the actual tables, I understood why: the feature is admin-gated where makers cannot see it, and the telemetry schema is not what instinct suggests. I made the wrong assumption myself before the data corrected me! So, in this article I will walk through how the integration actually works, the schema surprise that changes how you query it, and the Kusto queries that turn "the flow failed" into "the flow failed at this action, with this error."

First things first: yes, the integration exists

Power Automate cloud flow telemetry can be exported to Azure Application Insights, and keep in mind, this is not a maker feature -- which is the source of a lot of the confusion. Canvas apps let a maker paste an instrumentation key into the app and start calling Trace(). Cloud flows offer nothing of the sort, and for a sound reason: flows have no client runtime to instrument. They execute server-side on shared infrastructure, so the integration was built as a platform-level export instead.

The setup lives in the Power Platform admin center, under Data export.

Admin Center > Manage > Data Export

An administrator creates an export package, selects Power Automate as the data type, chooses the environment, and points it at an Application Insights resource. Three requirements to check before you start, because each one can stop you cold:

The environment must be a Managed Environment. The feature is gated behind this governance tier, which is exactly why a maker who goes looking for it at the flow level concludes it does not exist. It does; it just lives upstairs.
You need admin rights, not maker rights. Power Platform administrator or Dynamics 365 administrator at the tenant level, plus environment or system administrator in the Dataverse environment.
You need Contributor rights or better on the Application Insights resource itself, over on the Azure side.

NOTE: once configured, expect up to 24 hours before telemetry starts appearing. Initial patience is required; ongoing latency is much lower. Do not spend that first afternoon rewriting your export package because the tables look empty!

The schema surprise: two tables, not one

Here is the assumption I walked in with: every action a flow executes, including the trigger, lands as an entry in the Application Insights requests table. It seems reasonable. It is also not how the schema works, and the difference matters more than any other detail in this article. As it turns out, the export splits telemetry across two tables:

Table	Contains	signalCategory value
`requests`	Cloud flow runs	"Cloud flow runs"
`dependencies`	Cloud flow triggers and actions	"Cloud flow triggers" / "Cloud flow actions"

In turn, if your monitoring queries only touch requests, you are monitoring at the run level. You will know a flow failed. You will not know which action failed, how long each action took, or whether a specific connector call is degrading over time. All of that lives in dependencies, waiting to be queried.

There is a second, related detail that took me a moment to appreciate. When you configure the export package, you explicitly choose whether to export cloud flow runs, triggers, or actions. These are separate checkboxes! If you only selected runs during setup, action telemetry never leaves the platform, and no Kusto query will conjure it afterward. Granularity is decided at configuration time, not query time.

Run-level monitoring: the baseline

Run-level failure alerting is the right starting point, and the query looks as follows:

requests
| where customDimensions.signalCategory == "Cloud flow runs"
| where success == false
| extend flowId = tostring(customDimensions["resourceId"]),
         environmentId = tostring(customDimensions["environmentId"])
| project timestamp, name, resultCode, duration, flowId, environmentId, operation_Id

A few things to note here. Filtering on signalCategory matters because your Application Insights instance may be collecting telemetry from many sources, and this keeps the flow signals separated from everything else. Filtering on environmentId matters when multiple environments export to the same resource. Wire this query to an Azure Monitor alert rule, and you have real-time failure notifications by email, SMS, or webhook.

Action-level monitoring: where the real value is

Now, with the actions checkbox enabled in your export package, the dependencies table gives you per-action telemetry:

dependencies
| where customDimensions.signalCategory == "Cloud flow actions"
| where success == false
| extend flowId = tostring(customDimensions["resourceId"])
| project timestamp, name, resultCode, duration, flowId, operation_Id

The name field carries the action name exactly as it appears in the flow designer. This is the query that turns "the invoice approval flow failed" into "the invoice approval flow failed at the vendor validation HTTP call with a 429."

Correlation is what makes the two tables work together. The operation_Id on an action's dependency row matches the operation_Id on the parent run's request row, so you can join them:

requests
| where customDimensions.signalCategory == "Cloud flow runs"
| where success == false
| join kind=inner (
    dependencies
    | where customDimensions.signalCategory == "Cloud flow actions"
    | where success == false
  ) on operation_Id
| project runTime = timestamp, flowRun = name,
          failedAction = name1, actionResult = resultCode1, actionDuration = duration1

What this join produces is a failure report at the granularity your support team actually needs: which run, which action, what error, and how long it ran before dying. The name1, resultCode1, and duration1 columns are Kusto's automatic renames for the joined table's fields; the projection gives them names a human can read.

Beyond failures, the same table supports performance work. Percentile queries over duration by action name will surface connector calls that are slowly degrading long before they start timing out, which is exactly the kind of early signal run-level monitoring can never provide.

Three caveats before you turn everything on

NOTE 1: ingestion cost scales with granularity. Application Insights bills per GB ingested, and action-level export on a busy flow with Apply to each loops generates a row per action, per iteration, per run. A flow processing a few thousand records nightly can produce telemetry volume that surprises you at invoice time. Scope the export deliberately: enable action-level export for the flows that justify it rather than blanketing the environment.

NOTE 2: validate scope nesting behavior empirically. If your flows use the Try/Catch pattern built on Scope containers, test how nested actions surface before you write production alert queries. Build a flow with a deliberately failing action inside a scope, run it, and inspect what lands in dependencies. Ten minutes with a test flow will teach you more than any amount of reading, and your failure queries should be written against observed behavior rather than assumptions. I know so as I've done so myself!

NOTE 3: treat the export as telemetry, not as a system of record. Microsoft is explicit that small data losses can occur due to transient service issues. The flow run history inside the Power Automate portal remains the transactional, authoritative record. Application Insights is for alerting, dashboards, and trend analysis, not for audit-grade completeness.

What about custom telemetry from inside a flow?

The export covers runs, triggers, and actions, but you may be asking, "where is the Trace() function for flows?" Very simple: there is no native equivalent. If you need business-level events -- "vendor matched," "payment batch released" -- the pattern is an HTTP action posting directly to the Application Insights ingestion endpoint at https://dc.services.visualstudio.com/v2/track, or preferably the regional endpoint from your resource's connection string. No authentication header is required; the instrumentation key inside the payload identifies the target resource:

{
  "name": "Microsoft.ApplicationInsights.Event",
  "time": "@{utcNow()}",
  "iKey": "<your-instrumentation-key>",
  "data": {
    "baseType": "EventData",
    "baseData": {
      "name": "InvoiceApprovalFlow.Step3.VendorMatched",
      "properties": {
        "flowRunId": "@{workflow()['run']['name']}",
        "flowName": "@{workflow()['name']}",
        "environment": "@{workflow()['tags']['environmentName']}",
        "vendorId": "@{variables('vendorId')}"
      },
      "measurements": {
        "recordsProcessed": 42,
        "durationMs": 1830
      }
    }
  }
}

A few things to note about this payload. Events posted this way land in the customEvents table. Swap baseType to TraceData with a message and severityLevel for trace-style logging, or to ExceptionData for structured errors. And carrying the flow run ID in the properties gives you a correlation key back to the platform-exported tables, so your business events join cleanly against the runs and actions they belong to.

Centralize it in a child flow

Do not scatter this HTTP action across every flow you own! Build it once as a child flow -- call it something like "LogTelemetry" -- and have every parent flow call it as a single action. The child flow takes three inputs:

Event name (text): the dotted event identifier, such as InvoiceApprovalFlow.Step3.VendorMatched
Properties (text): a JSON string of custom dimensions, parsed and merged into the payload inside the child
Severity (text or number): drives whether the child posts EventData, TraceData, or ExceptionData

In turn, the child flow owns the instrumentation key, the endpoint URL, and the payload envelope. When the ingestion endpoint changes, when you rotate the key, or when you decide to enrich every event with the environment name, you change one flow instead of forty. Parent flows stay clean: one "Run a child flow" action per telemetry point, and no HTTP plumbing in sight.

The same child flow pairs naturally with Scope-based error handling. Wrap your business logic in a Try scope, follow it with a Catch scope configured to run after "has failed" and "has timed out," and inside the Catch use result('Try') to extract the failed action details and pass them to LogTelemetry as an ExceptionData payload. That gives you structured failure telemetry carrying the actual action error, not just a run that shows red in the portal.

NOTE: two constraints to know before you commit to this pattern. The HTTP connector requires premium licensing, and the raw post does not work if your Application Insights resource enforces Entra ID-only ingestion. In that case, a small Azure Function relay running the real SDK is the better shape, since a flow cannot easily perform the token acquisition against Azure Monitor scopes.

And to save you the scaffolding: I built LogTelemetry exactly as described and published it as an importable solution on GitHub, over at github.com/dgpblogster/power-automate-logtelemetry. It uses no connectors that require authentication, so the import prompts for nothing; you replace two clearly-marked CONFIG values, turn it on, and start logging. The README walks the import click by click.

The bottom line

Power Automate telemetry in Application Insights is real, admin-configured, and gated behind Managed Environments. Runs live in requests; triggers and actions live in dependencies. If your monitoring stops at the requests table, you have built a smoke detector that tells you the building is on fire without telling you which room. The dependencies table, an export package with the actions checkbox enabled, and one join on operation_Id are all it takes to do better.

If you have wired up this export yourself, or found other signals hiding in these tables worth querying, please drop a note in the comments describing your experience; telemetry patterns get better every time somebody shares what they found in the data.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Power Automate | Design Every Flow So a Resubmit Is Always Safe

2026-08-21T07:00:00.000-04:00

If there is one question I have learned to ask of every single action in every Power Automate flow I build, it is this one: what happens if this runs twice?

Throughout our Business Central to Dynamics 365 CE billing integration, the same project from my previous articles in this series, we made the answer to that question a design requirement. Every flow had to produce the same correct end state whether an event arrived once, twice, or five times, and whether the runs came from the webhook, a retry, or a human clicking resubmit weeks later. So, in this article I will walk through why that requirement pays for itself many times over, the patterns that satisfy it, and the two match-key mistakes we made on the way to getting it right. Yes, it took us three attempts!

Why events arrive more than once

Keep in mind, if your integration is triggered by webhooks, replays are not an edge case. They are the operating environment!

The source system fires on modification, not creation. Our flows trigger on Business Central's customer ledger, where a single business event can touch several entries, and each touch fires the trigger. Guards filter the noise, but the same document can legitimately come through the front door repeatedly.
Repairs happen by resubmission. When a run fails -- a permissions gap, a defect, an outage -- the natural fix is: repair the cause, resubmit the stored run. The trigger payload replays against the flow as it exists now.
Testing happens by resubmission. The fastest way to verify a flow change against real data is to resubmit a known run and inspect the result. If reprocessing old events corrupts data, you have lost your best testing tool.
Late events reprocess old ground. A payment applied to an invoice months after posting triggers a reconcile over records your flow already created.

Now, you may be asking, "can I not just guard against each of these individually?" You certainly can, and you will be maintaining those guards forever. Or you can adopt the single stronger property that covers all of them at once: every run converges the target system to the source system's current truth, no matter how many times it executes.

Sync the state, not the event

The foundational pattern is a mental shift. An event-applying flow says "an invoice was posted, so create an invoice." A state-converging flow says "an invoice exists in the source; make the target match it." The first duplicates on replay. The second cannot, because its writes are defined relative to what is already there.

Concretely, our invoice sync is a reconciling upsert. It looks up the target invoice by the source system's document number. If it does not exist, it creates it with its lines. If it does exist, it updates the header and then reconciles the lines: match each source line to a target line, update the matches in place, create the missing, and delete the orphans that no longer exist in the source. The payment sync works exactly the same way, reconciling the payment's application detail rows against what the source says is currently applied, deleting rows the source no longer has, right down to deleting the payment header itself when zero applications remain.

In turn, a reconcile has a property an append never has: it is self-healing. When we later fixed a line-mapping defect, the reconcile did not just handle new invoices correctly; rerunning it against previously damaged invoices replaced the malformed lines with correct ones. The repair tool was the flow itself!

Let the source system name things

Idempotency needs a key, and the right key is the source system's own identity for the record, carried into the target where the flow can find it again. Our payment headers are named by the Business Central document number, which makes the name double as the idempotency key: any rerun finds the header it created before. Invoices are looked up by the posted invoice number. Nothing is keyed by anything the flow generates, because a generated key is different on every run, which is precisely the property you do not want.

Getting this right at the line level took us three attempts, and the two failures are worth studying, because they will save you from repeating them.

Attempt one: match lines by name. As it turns out, this failed immediately, because the target system overwrites the line description with the product name on product-based lines. Our matching field was being silently rewritten by the platform after every create, so matches always missed, and every reconcile deleted and recreated every line. The lesson: never match on a field the target system considers its own to modify.

Attempt two: match lines by product ID. This one worked for months. Then it failed structurally the day we met an invoice with two lines sharing one product -- a maintenance credit billed as a negative line on the same product code it credits. The reconcile saw the product already present and concluded the credit line was already synced. It was not a bug in the matching code; the key itself could not distinguish the rows. Worse, the failure mode was silent: the reconcile ran, reported success, and structurally could never repair the missing line. Suffice to say, a key that is merely usually unique is a defect with a delayed fuse.

Attempt three: match lines by the source system's line number, stamped into a dedicated field on every line the flow writes. Business Central's line numbers are the source's own identity for the row: unique within the document, stable across time, and meaningless for the target platform to overwrite. Every line create and update stamps it; matching and orphan detection key on it. This is the version that survived every scenario we could throw at it.

The general rule that falls out: the match key must be the source system's identity for the row, persisted in the target, and owned by nobody else.

A quick aside before moving on: both failures were diagnosed in minutes rather than an afternoon of clicking through run history, because we develop these flows with Claude Code reading run actions directly through FlowAgent. The agent walked the failed runs, found the exact action and input responsible each time, and in the second case also exposed that the product-keyed reconcile could never have repaired the damage. That workflow is a story of its own, and I told it in my FlowAgent article; here it is enough to say that resubmit-safe design and run forensics compose beautifully -- one gives you a safe repair tool, and the other tells you precisely when to use it.

Gate the side effects on change

Data writes converge naturally under a reconcile, but side effects -- notifications, timeline notes, cascade triggers -- duplicate cheerfully unless you design them not to. Two patterns handled every case we had:

Attach side effects to transitions, not to runs. Our settlement timeline notes are written only when a detail row is actually created, only when a synced row is actually deleted, and only on the first sighting of a cancellation, guarded by "the invoice is not already cancelled." A resubmitted run that changes nothing writes no note, because no transition occurred. We proved this on a live rerun: identical resubmit, zero writes, zero duplicate notes. The note trail reads like a history precisely because it records transitions.

Write only when the value differs. Our bundle cascade flow updates a child record only if its expiration differs from the parent's or the row is inactive. That single guard makes the cascade convergent: reprocessing is free, and a chain of cascading updates terminates on its own -- five runs, converged, no runaway, in our live verification. As a bonus we did not initially design for, the flow can safely react to writes made by other flows sharing its connection identity, because reacting to an already-correct value is a no-op.

The payoff: resubmit becomes your universal tool

Once every flow held the property, resubmission quietly became the answer to almost everything:

Repairs. When the credit-line defect left two invoices wrong in the target system, the repair was: deploy the fix, resubmit the two failed runs. Both invoices converged to the source's truth to the penny, replacing the malformed legacy lines on the way. No repair script, no manual edits!
Environment fixes. When a run failed on a missing privilege in a fresh environment, the fix was the role assignment plus one resubmit, which completed the scenario and re-proved reconcile idempotence in that environment for free.
Verification. Every flow change was tested by resubmitting a stored run and reading the results, precisely because reprocessing was guaranteed harmless.
Locked-record handling. Even where the target system makes records read-only -- paid invoices, in our staging environment -- the reconcile wraps its work in a capture-state, reopen, sync, restore sequence, so a resubmit against a paid invoice succeeds and leaves the record exactly as it found it.

Two caveats from the field

NOTE: a resubmit replays the trigger payload against the current flow definition. That is exactly what makes fix-then-resubmit work, but it has a sharp edge: if a deployment has left the flow stopped, a resubmit silently replays against the old definition, and the result can masquerade as a test outcome. It happened to us exactly once, which was enough to add "verify the flow is active and read the definition back" to the deployment checklist.

NOTE: idempotency does not replace concurrency control. Convergent runs racing each other can still interleave reads and writes. We run our webhook-triggered flows at concurrency one, not because the design needs it to be correct in sequence, but as cheap insurance that runs actually execute in sequence. The two properties compose: idempotency makes replays safe, and serialization makes overlaps impossible.

The checklist

For every flow, before it ships, walk through the following five questions:

Can I resubmit any historical run right now with no damage? If not, why not? Fix that first.
Is every record the flow writes findable by a key the source system owns?
Does the flow reconcile to current source truth, including deleting what the source no longer has?
Is every notification and note attached to a transition, not to a run?
Does every cascading write fire only when the value actually differs?

When it's all said and done, the cost is a habit of mind during design, and the return is an integration where the scariest phrase in operations, "just run it again," is not scary at all. It is the standard procedure, and it is always safe.

If you have your own resubmit war story, or a match key that failed you in a way I did not list here, please drop a note in the comments describing your experience; idempotency lessons are expensive to learn firsthand and free to learn from each other.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Power Automate | Getting Secrets Out of Your Flows with Azure Key Vault

2026-08-19T07:00:00.000-04:00

The flow we inherited at the start of our Business Central to Dynamics 365 CE billing integration, the same project from my FlowAgent article, had a problem so common it barely registers as a problem anymore: the OAuth client secret it used to call Business Central's OData services was sitting in plaintext, inside a String environment variable, referenced by the flow as an ordinary parameter. Everything worked. Nothing was on fire. And that secret was quietly everywhere!

So, in this article I will walk through where "everywhere" turns out to be, and the migration we ran to fix it: a secret-type environment variable backed by Azure Key Vault, runtime retrieval inside the flow, secured inputs and outputs, and a cleanup pass that chased the old secret out of every place it had settled. I will also cover the one gotcha that failed our first live run, because keep in mind, it will fail yours too if you do not know about it.

Where a plaintext secret actually lives

When a secret sits in a flow definition or a plaintext environment variable, it does not live in one place. It lives in every place the definition travels:

Every solution export. The environment variable's value rides along in the zip. Email that zip to a colleague, attach it to a ticket, or drop it in a shared folder, and the secret goes with it.
Run history. If the secret flows through an ordinary action, every run's inputs and outputs display it to anyone with permission to read run history -- and that audience is usually much larger than the audience you would knowingly hand a credential to.
Source control. The moment you bring the solution under version control, which you absolutely should, the plaintext secret is in a commit, and commits are forever. Rotating the secret later does not un-commit the old one.
Backups and working files. Any tooling that snapshots flow definitions -- designer copies, local backups, agent working files -- multiplies the copies further.

None of these is hypothetical. We found our inherited secret in the solution export, in the flow definition, in run history via the token request's visible inputs, and, once we started working, in the local backup snapshots our own tooling captured. The secret had more copies than the flow had actions!

The fix Microsoft provides for exactly this scenario is the secret-type environment variable: instead of storing a value, it stores a pointer to a secret in Azure Key Vault, and the flow retrieves the value at runtime. In turn, the vault becomes the only place the secret exists. Everything that travels -- the solution, the source tree, the definition -- carries only the pointer.

The migration, in the order that worked

We did this as a single day's remediation, and as it turns out, the sequencing mattered as much as the steps. Here is the order, with the reasoning.

1) Set up Key Vault RBAC first. Secret-type environment variables only support Azure Key Vault as the store, and two identities need roles on the vault before anything else works: the person doing the setup needs to write the secret and pass the environment variable's save-time validation (Key Vault Secrets Officer covers both), and the Dataverse service principal needs Key Vault Secrets User so the platform can retrieve the value at runtime. Also confirm the Power Platform resource provider is registered on the subscription that owns the vault; it is a one-time thing, and a confusing failure if it is missing.

2) Rotate by appending, and never look at the new secret. We did not migrate the old secret; we replaced it. The new client secret was created on the app registration with an append, leaving the old credential intact so the running flow never broke during the migration, and piped directly from the creation command into the vault in a single step. The value was never displayed on screen, never in a file, never in shell history. Keep in mind: if your new secret is ever visible, you have created another copy to worry about. The pipe means there is nothing to clean up afterward.

3) Create the secret-type environment variable, and get the reference format right. The variable lives in the solution like any other environment variable, but its value record contains only a pointer to the secret, and the form of that pointer is the part that stopped us cold, because it is not what instinct suggests. It is not the secret's URL from the Azure portal, and it is not a vault name and secret name pair. It is the secret's full Azure resource ID path:

/subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.KeyVault/vaults/{vault-name}/secrets/{secret-name}

A few things to note here. Every segment is required, including the providers/Microsoft.KeyVault in the middle that nobody types from memory. If you create the variable through the maker portal, the form collects the pieces separately and assembles the path for you; if you create it through the Web API, or find yourself editing the value record directly, you supply the whole path yourself, and anything else fails validation. The save is also more than a format check: Dataverse resolves the path against Azure with your permissions at save time, so a typo in any segment, or a missing role on the vault, surfaces right there rather than at the first flow run. That is a kindness once you understand it, and a mystifying save error until you do!

NOTE: export the solution afterward and inspect it; you should see the resource path and nothing else. We made this check part of the verification, not an assumption.

4) Prove retrieval with a throwaway flow before touching the real one. You may be asking, "can I just test the retrieval from the Web API?" Categorically no! Secrets in secret-type environment variables are only resolvable from inside flows and custom connectors, and that is by design. So we built a disposable test flow whose only job was to call RetrieveEnvironmentVariableSecretValue and succeed, ran it, confirmed the retrieval, and deleted it. Two minutes of scaffolding, and the real flow's rewire started from a known-good vault path instead of debugging two things at once.

5) Rewire the flow, and secure both ends. The real flow gained one action: a Dataverse unbound action call to RetrieveEnvironmentVariableSecretValue for the new variable, with secured inputs and outputs turned on. The token request was repointed to consume that action's output, and it got secured inputs and outputs as well. That second part is easy to forget and matters just as much: the client secret passes through the token request, and the bearer token that comes back is itself a credential. With both actions secured, neither the secret nor the token appears in run history anymore.

6) Add a graceful failure path. A vault outage or a permissions change now has a single, well-defined failure point, so we gave it a dedicated handler: an alert email carrying the run ID and the likely causes, then a Terminate with a named error code. Without this, a retrieval failure dies mid-run with secured -- and therefore blank -- diagnostics, which brings us to the gotcha in a moment.

Graceful failure path

7) Clean up until a search proves you are done. The old plaintext environment variable and the flow parameter that referenced it were deleted; a forgotten draft copy of the flow held the last dependency and had to go first, which the dependency checker told us. Then we searched the entire synced source tree for any fragment of the old secret and did not stop until the search came back empty. Local backup snapshots that predated the fix still contained it, so they went into .gitignore. Only after the tree was provably secret-free did the repository get its first commit. That ordering is worth stating plainly: git init comes after the secret hunt, not before.

8) Hand the old secret off for rotation. The old credential was left working throughout the migration and then handed to the system administrator to rotate, after checking whether anything else used it. In our case, something else probably did, which is its own small lesson: plaintext secrets get shared around precisely because they are visible, and you cannot assume you are the only consumer.

The gotcha: runtime RBAC follows the connection owner

Our first live-fire test failed at the secret retrieval with a BadRequest and no details, because secured outputs hide details by design. The error handling worked beautifully -- alert sent, run terminated cleanly, zero partial writes -- but the diagnosis took some actual thought, so here it is for free.

NOTE: Dataverse validates the vault RBAC of the calling user, and the calling user is the owner of the Dataverse connection the flow uses, not the person who built the flow. As it turns out, our earlier test flow had succeeded because it ran on the author's own connection, and the author had vault roles. The production flow ran on a shared connection owned by a service account that had none. Granting Key Vault Secrets User to that service account fixed it, and the resubmitted run passed end to end.

The practical rule: enumerate every identity that will ever own a connection your flow runs on, in every environment, and grant each one Secrets User on the vault. And when the retrieval fails with hidden diagnostics, check connection ownership before anything else. It is the most likely cause and the least visible one.

The payoff shows up at deployment time

Weeks later, when we deployed the solution to a staging environment through a Power Platform pipeline, the secret story was the part that just worked. The secret-type environment variable's vault reference traveled with the solution; no secret value needed to be supplied at import, because there is no secret value in the solution. The only per-environment chore is the RBAC grant for that environment's connection-owning identity, and the first live run tells you immediately whether you missed it, through the graceful failure path built in step 6.

Now, compare that with the plaintext alternative, where every deployment either carries the secret in the zip or prompts someone to paste it in. Both of those mint fresh copies. It just doesn't work!

The other half: everything else into environment variables too

The secret was the dangerous case, but the same remediation pass moved every per-environment value out of the flow definition and into ordinary environment variables: tenant ID, company ID, environment name, target system record IDs, alert recipients, and a set of sandbox-only test toggles. Two decisions there proved right in hindsight:

Ship no values in the solution for anything environment-specific. An import that prompts is a feature; a value that silently travels to the wrong environment is a defect waiting to be discovered in production.
Make the flow's behavior mode explicit. A Sandbox/Production mode variable, with test toggles honored only in Sandbox mode, means production can never accidentally run with a test configuration. The gate rule lives in the flow once, not scattered across conditions.

When it's all said and done, you end up with a flow definition that has no secrets, no environment names, no GUIDs, and no email addresses in it. Everything that varies is a variable, and the one thing that must not leak is a pointer to a vault. That is the whole trick, and a day of careful sequencing is all it costs.

If you run this migration yourself, or if you have chased a plaintext secret through more hiding places than the ones I listed here, please drop a note in the comments describing your experience; these war stories are how the community keeps each other's credentials out of run history.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

One Solution, Two Source Trees: The Maker Portal's Git Integration vs pac

2026-08-17T07:00:00.000-04:00

Early in our Business Central to Dynamics 365 CE billing integration, the same project I wrote about in my FlowAgent article, we ran into a lesson that Microsoft's own documentation only caught up to this spring, and that I have not seen written up from the trenches: there are now two official ways to put a Power Platform solution under source control, and they do not mix. At all! We learned this the day we put the solution source pac had cloned next to the solution source the maker portal's Git integration had committed, and found two completely different structures staring back at us.

So, in this article I will walk through the two formats, how the collision showed up in our project, and why we picked the CLI side, with a couple of smaller git-versus-pac frictions at the end that you will want to know about before you start.

Two formats, one solution

The classic XML format is what pac solution clone, pac solution sync, and the traditional SolutionPackager workflow produce. The solution's identity lives in Other\Solution.xml and Other\Customizations.xml, and the component files (workflow JSON, environment variable definitions, connection references) sit in a folder hierarchy alongside them. Keep in mind this is the format that pairs with the round-trip commands: pac solution pack builds an importable zip from the folder, pac solution import pushes it to the environment, and pac solution sync pulls the environment's current state back down.

Classic XML Format

The YAML source control format is what the maker portal's native Git integration writes. When you connect an environment or a solution to Azure DevOps from within Power Apps, every commit lands as a solutions\<name>\solution.yml manifest with component folders at the repository root. I will be the first to tell you it is a genuinely nicer format to read: compact YAML, small focused diffs, and support for canvas apps and modern flows that the XML layout never handled. It is also, and this is the entire point of this article, a different representation that the classic tooling chain does not interoperate with.

YAML Format

Now, here is the part that will save you an afternoon of head scratching. The packager tools decide which format they are looking at by folder shape. A solutions\ subdirectory containing solution.yml files means YAML; no solutions\ subdirectory means classic XML, in which case the tool goes looking for Other\Solution.xml. There is no flag that says "this repo contains both, figure it out."

NOTE: a folder that mixes the two layouts, or that has YAML files in the wrong place, produces the format war's signature error: a complaint about a missing Customizations.xml from a tool that has silently fallen back to the XML code path while staring at YAML files. If you have ever seen that error and thought "but this is not an XML solution," congratulations, you have met the auto-detection rules! And as of this spring, Microsoft's SolutionPackager documentation carries a troubleshooting entry for exactly this case, describing the silent fallback and calling the error misleading in so many words. It is good to see it written down; it would have been better to read it before we found it.

What happened to us

Our source control story started deliberately. On the first day, we ran pac solution clone against the inherited invoice flow's solution, dropped the XML source tree into a folder, and began a discipline we have kept ever since: the cloud flow is the working copy, the local tree is the versioned mirror, and after every applied change we run pac solution sync, write a changelog entry, and commit. That loop was not an accident. Our whole development approach, an AI coding agent editing flow definitions, packing them, and importing them, depends on having the real definition JSON locally and being able to round-trip it through pac solution pack and pac solution import.

Then the maker portal's Git integration entered the picture, the way it enters most pictures: it is right there in the portal, connecting a solution to a repo takes a few clicks, and it feels like the officially blessed path. And it is a blessed path! It is just a different one, and it wants to own the repository in its own format.

Now, the moment the incompatibility became real for us was not an error message; it was a side-by-side comparison. We put the tree pac had cloned next to the repository the portal's Git integration had committed, expecting two views of the same solution, and found two structures with almost nothing in common: different file names, different nesting, different serialization, and no file on one side corresponding one-to-one with a file on the other. This was not two dialects that a diff tool could reconcile. There was nothing to diff. Nothing! Keep in mind, that comparison is worth doing deliberately if you are facing the same choice, because it settles the question faster than any documentation will.

And once you have seen it, the operational hazard is obvious: had both stayed connected, every portal commit and every pac solution sync would have written its own divergent truth into the same repo, with the packager's auto-detection deciding which one it believed based on which folders it noticed first. Nothing about that fails loudly at the moment you set it up. It fails later, confusingly, in tooling errors that point at the wrong cause. A repository is going to hold one format or the other, and somebody has to choose.

So we chose, and wrote it down: this solution is versioned in the classic XML format maintained by pac, the maker portal's Git integration was deliberately disconnected, and the README carries a standing instruction, in bold, that says do not reconnect it. That last part matters more than it looks. The portal integration is a checkbox any admin can re-enable in a moment of tidiness, and the person who re-enables it will genuinely believe they are improving your source control posture. Suffice to say, that one bolded line in the README is the cheapest insurance we bought all week.

Why we picked the pac side

You may be asking, "so is the YAML format bad?" Not at all. On a fresh project with canvas apps in the mix, the YAML format and the portal integration are very likely the right choice, and Microsoft's direction of travel is clearly toward it. We picked the XML side for three reasons specific to how we work:

1) The round-trip commands are our development loop, not just our backup. Large flow edits in our project go through the solution route: edit the definition JSON locally, then pac solution pack, pac solution import, and publish. The clone and sync commands our loop depends on produce the classic XML format, and as I write this they still do not emit the YAML layout, whatever the documentation implies (there is an open issue on exactly that). Choosing the portal's format would have meant choosing away the loop.

2) Commit cadence and commit meaning. The portal integration commits when a maker clicks commit, at whatever granularity the portal batches. Our discipline is one commit per applied change, pushed immediately, with a changelog entry stating what changed, why, where it was applied, and how it was verified. In turn, that kind of history only happens when the same actor making the change also makes the commit, which in our case is the agent completing its edit-sync-log-commit ritual. The repository is not a backup of the solution; it is the audit trail of the project.

3) One writer per repository. Even if the formats had been compatible, two independent processes committing to the same branch on their own schedules is a merge conflict generator. A source control setup where you cannot predict who writes next is worse than either setup alone. It just doesn't work!

Two frictions that come with the pac side

Choosing pac did not end the git-versus-pac story. Two smaller frictions followed, both consequences of letting a CLI own the source tree, and both are worth knowing before you start.

Line endings. Git on Windows helpfully converts line endings unless told otherwise, and pac-generated source trees do not want the help. Every pac solution sync after a fresh clone produced walls of CRLF warnings and threatened noisy whitespace-only diffs. The fix was repo-local: set core.autocrlf=input in the repository config, and add a .gitattributes marking the pac-generated source trees as -text so git stops converting them entirely. The solution source is machine-generated and machine-consumed; git should store it byte for byte and stay out of the way.

Byte order marks. A later sync quietly restored UTF-8 byte order marks on files where our editing had stripped them, which showed up as mysterious whole-file diffs on files nobody had meaningfully changed. We widened the .gitattributes coverage and learned the larger lesson: treat the pac tree as pac's territory. Our edits happen there when the loop requires it, but the formatting conventions are the tool's, and fighting them costs more than accepting them. Fence the pac tree off from git's text handling with .gitattributes the day you create it, not the day the warnings annoy you.

What I would tell you to do

Whichever side you land on, two practices carry over to any project:

Pick one format before the first commit, and never let both write to the same repository. If your workflow lives in the CLI round-trip commands, take the classic XML format. If you are starting fresh, especially with canvas apps or a team of makers committing from the portal, take the YAML format and let the portal integration own the repo. Either way, if someone has already connected the other one, disconnect it before it writes a single commit. Divergence is silent, and cleanup is manual.
Write the decision down where the next admin will trip over it. A bolded "do not reconnect the Git integration for this solution" in the README, with one sentence of why, will save a future colleague from an afternoon of Customizations.xml errors on a repository full of YAML.

The two-format situation is a snapshot of a platform mid-transition, and it should resolve as the newer format's tooling support fills in. Until it does, keep in mind the failure mode is not that either path is broken. Both paths work, both look official, and nothing warns you that they cannot coexist in the same repository. Consider yourself warned!

If you have hit the two-format collision yourself, or found a cleaner way through it, please drop a note in the comments describing your experience; this corner of Power Platform ALM has very little written about it, and the community learns fastest when we compare scars.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Building Power Automate Flows with Claude Code and FlowAgent

2026-08-13T07:00:00.000-04:00

For the past week, my team and I have been heads-down building a Business Central to Dynamics 365 CE billing integration: posted sales invoices, applied cash receipts, subscription cancellations, and the product registry automation that ties them all together. Every one of those integrations is a Power Automate cloud flow, and every one of them was developed, debugged, and verified with Claude Code driving Power Automate directly, through a tool called FlowAgent. Suffice to say, this changed how I think about building flows, so I figured I would write up what we learned while it is still fresh.

Now, keep in mind this is not a review written after a demo. This is written after shipping three production-bound flows through dozens of iterations, a full test campaign, and a healthy number of defects found and fixed along the way. The scars are real!

What FlowAgent is

FlowAgent is an MCP server that ships inside the power-automate plugin from the good folks at Microsoft, published in the open source power-platform-skills repository. MCP, the Model Context Protocol, is the standard that lets an AI coding assistant call real tools instead of just talking about them. Once the plugin is installed, Claude Code gains a set of Power Automate operations it can invoke on its own:

List environments and flows, and set a working environment and current flow
Read a flow's full definition -- this is, the JSON under the designer
Edit, validate, and publish flows
Read run history, run details, and per-action inputs and outputs from any run
Inspect connections, connectors, and operation schemas
Search connector operations and get expression help

The plugin also bundles a Microsoft Learn MCP server, so the assistant can pull official documentation while it works, plus a set of skills -- guided workflows -- for creating, debugging, and diagnosing flows.

You may be asking, "why does this matter when the assistant can already tell me what to build?" Very simple: without FlowAgent, the AI describes a flow and you go click it together in the designer. With FlowAgent, the assistant reads the actual flow, makes the actual edit, publishes it, watches the actual run, and reads the actual error. The feedback loop that used to run through your eyes and your mouse now runs at tool speed.

Setting it up

The prerequisites are modest: Claude Code, Node.js, the Azure CLI logged into your tenant -- FlowAgent uses it for authentication -- and ideally the Power Platform CLI (pac) for solution work. Installation is two commands from within Claude Code:

claude plugin marketplace add microsoft/power-platform-skills
claude plugin install power-automate@power-platform-skills

A few things to note before moving on. The first command registers Microsoft's repository as a plugin marketplace; the second installs the power-automate plugin from it. After both commands complete, restart your Claude Code session, because plugins attach at session start. Then run the plugin's setup skill once: it verifies Node, the Azure CLI login, and the Power Automate token, and lets you pin a working environment so every later operation lands where you expect.

Two lessons from our own installation that may save you an afternoon:

NOTE: check which Claude Code binary you are actually running. We had an old standalone CLI on the PATH that predated the plugin system entirely, and it silently swallowed the plugin subcommands as if they were prompts. The VS Code extension ships a current CLI in its resources\native-binary folder; that one worked immediately.

NOTE: do not hand-edit the plugin registration files. Our first attempt at manual registration produced a "marketplace configuration corrupted" state that even blocked removal. Resetting the marketplace file and using the real CLI commands fixed it in minutes.

Debugging: the single biggest win

When a flow fails, the assistant pulls the run, walks the failed action, reads its exact inputs and outputs, and correlates all of it with the flow definition in one pass. Early in the project, this alone paid for the whole setup. As it turns out, our invoice flow had been silently broken for about two weeks, because the web services it called no longer existed, and the failure was masked by trigger noise. Two weeks! Nobody noticed, and frankly, nobody was going to: reading run histories systematically across hundreds of runs is exactly the kind of work a human never quite gets around to. Claude Code found it, remapped both HTTP calls to the replacement services, and verified the fix against a live run.

The same loop caught subtler things. A negative credit line on an invoice was failing because the CRM connector rejects negative discount amounts. The failed runs told the whole story: header created, positive line created, credit line refused. Reading the actual action outputs turned a vague "totals are off in CRM" report into a precise defect, a designed fix, and a verified repair, all inside one working session.

Edits go where edits belong

Our standing rule became: the cloud flow is the working copy, and the local solution source is the versioned mirror. Small, surgical changes go through FlowAgent's edit and publish tools. After every applied change, pac solution sync pulls the new definition into a git repository and the change gets a changelog entry. The assistant does all of this in one motion, so the discipline actually holds. Every flow change in this project, and there have been many dozens, is in version control with a written rationale.

For large edits, there is a practical workaround worth knowing: tool payloads truncate somewhere around 5 KB, so a big definition rewrite goes through the solution route instead. Edit the definition JSON locally, then pac solution pack, pac solution import, and publish. Same destination, different door. The assistant learned to choose the route based on the size of the change.

Verification stopped being optional

Because the assistant can resubmit a stored run and then read the new run's results, "deploy and hope" turned into "deploy and prove." Our habit became: make the change, resubmit a known trigger event, read every action's output, compare the CRM records against Business Central truth, and only then call it done.

During the test campaign, this cadence caught a deployment race where a managed export picked up a stale version and the target environment silently skipped the import as already installed. In turn, a resubmit against what turned out to be the old definition briefly looked like a test result. The lesson is now procedure: after every deployment, read the definition back from the target before trusting any run.

The rough edges, honestly

FlowAgent is genuinely useful and genuinely version one. Things we hit, and how we worked around them:

Solution-aware flows do not appear in the flow list, which only shows personal-scope flows. The workaround is to address your flow by its ID directly. Once pinned as the current flow, everything else works.
The resubmit and diagnose tools had bugs in the version we used; both threw type errors. We resubmitted runs through the underlying Power Automate REST API instead, which the assistant handles just fine, and filed the issues upstream with the plugin's built-in report-issue skill.
Importing a solution leaves flows stopped, and validation errors surface at activation time, not import time. Publishing or activating after import is a required step, not a nicety.
Connection authorization is per connection, not per flow. A brand new flow referencing a shared connection needs one activation by the connection's owner; after that, other makers can deactivate, edit, and reactivate freely. Knowing this pattern saved us from repeatedly misdiagnosing authorization failures.

None of these were blockers. All of them are the kind of thing you want written down before you start, which is exactly why they are written down here.

What it added up to

In a bit under a week of working sessions, this setup carried us through:

Remediation of six pre-existing defects in an inherited flow, including moving a plaintext secret into Azure Key Vault and parameterizing every environment-specific value into environment variables
A ground-up rebuild of the invoice flow onto a customer ledger trigger, eliminating an entire class of draft-noise and race-condition bugs
A cash receipts flow built from a feasibility stub to feature complete in a single day, across four live-verified iterations
A registry automation flow that replaced two hardcoded legacy flows with one table-driven design
A full staging test campaign in which every planned scenario across three flows fired live, with every defect found along the way fixed and re-verified

Could a person do all of that in the portal designer? Eventually. But the honest answer is that the verification depth is what a person would not do. Reading every action output of every test run, reconciling every synced record against the source system to the penny, and writing it all down as you go is precisely the tedious, high-value work that an agent with real tool access does without fatigue.

If you try it

Three practices made the difference for us, and none of them are about the tool itself:

Keep a changelog and a git mirror from day one. The agent moves fast; the paper trail is what lets you trust the speed.
Decide your edit routing up front. Cloud as working copy, local as mirror, one commit per applied change. Ambiguity here is how definitions drift.
Insist on live verification. The agent can prove its work against real runs. Make it do so every time, and "it should work" disappears from your vocabulary.

One last thing, because it matters: FlowAgent will not design your integration for you, and it should not. The design conversations, the business rulings, and the judgment calls stayed firmly human in our project. What it collapses is the distance between a decision and a verified, versioned, running flow -- a distance that used to be measured in hours of clicking and is now measured in minutes of reading the agent's evidence.

If you take FlowAgent for a spin, please drop a note in the comments describing your experience, including the rough edges you find; that feedback is exactly what makes open source tooling like this get better.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Same Agent, Two Architectures: When MCP Wins (and When It Doesn't)

2026-08-11T09:35:27.912-04:00

I know, I know. It has been almost five years since my last post, and in that time the masthead changed, the name changed, and frankly, the entire technology landscape changed with them. But I did not want to relaunch this blog with a ceremonial hello-world post, so instead, this first post from The Workbench starts out the way many of my posts have over the years: with a question.

The question comes up in just about every architecture review I sit in these days, whether in my day job as CTO or in conversations with folks in the community, and it goes something like this:

"Should we be using MCP for our Copilot Studio agents?"

I will be the first to tell you this is the wrong question. And rather than argue the point in the abstract, I built the same agent twice to prove it. Let's see how it's done!

Background

Model Context Protocol -- MCP for short, introduced by the folks at Anthropic -- has gone from curiosity to checklist item in record time, much like microservices did a few years back, and just like then, everyone wants to know where it fits before anyone has agreed on when it should. So, I put together a lab around a fictional but very realistic engineering program called Project Orion: a customer-facing web application mid-way through a major release cycle, with its operational truth split across two systems, the way it always is in real life:

GitHub Issues holds the code-level activity: 35 issues covering bugs, feature work, blockers, and performance problems.
A SQL Server database holds the delivery truth: five sprints of history, 70 work items, and 30 days of health metrics, including a release readiness score, critical bug counts, blocker counts, and velocity trend.

Now, the seeded data tells a story on purpose. Sprint 3 completed 38 of 45 points. Sprint 4 dropped to 33 of 44 with 11 points of rollover. The latest health snapshot shows a release readiness score of 52, three critical bugs, three blockers, and a velocity trend of Declining. Suffice to say, this project is quietly going sideways, and the signals are scattered across two systems that do not talk to each other.

With the stage set, I built the same agent twice in Microsoft Copilot Studio and asked both versions the same questions.

Version 1: the connector agent

The first agent uses nothing but the GitHub connector. Ten minutes of work, most of which is authentication, and here is the part that surprises people every time I demo it: this agent is good.

Ask it "What critical bugs are open in Project Orion?" and it answers cleanly, with issue numbers, titles, and labels. Ask it "What issues are labeled as blocked?" and it nails that one too. For questions whose answer lives entirely inside GitHub, the connector agent is fast, correct, and required exactly zero infrastructure from me -- no server to provision, nothing to patch, and it sits comfortably inside the tenant's existing governance and data loss prevention story, which your IT department will certainly appreciate.

Now, that's all cool, but then you ask it the ONE question your VP actually cares about: "What is blocking the Project Orion release?"

And there it is -- the ceiling! The agent can see three critical bugs in GitHub, so it reports three critical bugs. It cannot see that the release readiness score sits at 52 and falling, it cannot see that velocity has declined two sprints in a row, and it cannot see that two of the blocked work items have been stalled for over a week. Keep in mind, its answer is not wrong. It is something worse than wrong: it is confidently incomplete. A stakeholder reading that answer would walk away thinking the release has three bugs to fix, when the data says the release is structurally at risk.

In the lab version of this agent I made the limitation explicit, and I recommend you do the same for any single-source agent you ship. Its instructions include the following line:

"I can only see GitHub Issues data. For full project health including sprint metrics and release readiness, you would need access to the project health database."

An agent that states its blind spots is an agent you can trust. An agent that answers everything with whatever fraction of the truth it can reach is a liability wearing a chat interface. It just doesn't work!

Version 2: the MCP agent

The second agent is the same Copilot Studio agent rebuilt on two MCP servers: the GitHub MCP Server for issue data, and a custom TypeScript MCP server I wrote that fronts the Project Orion SQL database.

The custom server exposes seven tools, and I would encourage you to study the tool list closely, because this is where the real design work lives. These are not generic "run a query" endpoints; each one answers a question a human being would actually ask:

get_current_sprint: the active sprint with planned versus completed points
get_sprint_history: velocity and completion history across completed sprints
get_critical_work_items: open Critical and High priority items, including blocked ones
get_work_items_by_sprint: work items for a sprint, optionally filtered by status
get_latest_health_metrics: the current health snapshot, readiness score included
get_health_metrics_trend: readiness score over the last N days
get_stalled_work_items: items sitting in Active or New with no movement

Two implementation details will save you a considerable amount of head scratching, so pay close attention. First, as it turns out, Copilot Studio speaks HTTP, not stdio. Most MCP tutorials out there show the stdio transport, because that is what desktop clients use, but Copilot Studio requires the streamable HTTP transport running in stateless mode, with a fresh transport and server instance created for each incoming request. For brevity sake, I am only showing the shape of it:

// Copilot Studio requires HTTP transport in stateless mode
const transport = new StreamableHTTPServerTransport({
  sessionIdGenerator: undefined, // stateless: critical for Copilot Studio
});
// a fresh server + transport pair is created per incoming request
app.post('/mcp', async (req, res) => {
  const server = buildProjectOrionServer();
  await server.connect(transport);
  await transport.handleRequest(req, res, req.body);
});

Second, validate your tool inputs. The model -- not you, not your code -- is choosing the parameter values at runtime, so every tool takes a schema, not a prayer:

server.tool(
  'get_health_metrics_trend',
  'Returns the release readiness score trend over the last N days ' +
  'to show whether project health is improving or declining.',
  { days: z.number().optional().default(14) },
  async ({ days }) => {
    const rows = await getHealthMetricsTrend(days);
    return { content: [{ type: 'text', text: JSON.stringify(rows) }] };
  }
);

A few things to note before moving on. That tool description string is not documentation for humans; it is the interface the model reasons over when deciding which tools to call and in what combination. Write your tool descriptions the way you would write requirements for a sharp new team member, because for all practical purposes, that is exactly what they are.

The moment it earns its keep

Now ask the rebuilt agent the same question: "What is blocking the Project Orion release?"

This time the agent calls get_critical_work_items and get_latest_health_metrics on the SQL side, pulls the open critical issues from the GitHub side, and then does the thing no single-source agent can do: it correlates. The three critical GitHub bugs map to blocked work items in the sprint; the blockers explain the 11 points of rollover in Sprint 4; the rollover explains the declining velocity trend; and all of it together explains a readiness score of 52. And voila! The answer reads like something a good release manager would write, complete with a one-line risk summary at the end, because the agent finally has the same field of vision the release manager has.

Ask it "Are there any patterns between our open GitHub issues and our sprint health?" and it produces an answer that did not have a data path to exist in Version 1. That is the difference, and it is worth being precise about it: not better answers to the old questions, but answers to questions that were previously UNANSWERABLE.

What MCP costs you

Here is the part the hype conveniently skips, and the part I lean on hardest whenever I present this material: everything above has a bill attached.

With the connector agent, Microsoft runs the integration. With the MCP agent, I run the integration. In the lab, the server is a TypeScript process on my laptop reached through an Azure Dev Tunnel, which is perfectly fine for a demo and perfectly irresponsible for production.

NOTE: the moment this architecture goes to production, you own hosting, authentication, TLS, availability, logging, patching the SDK, and the security review for a brand-new surface area that reaches directly into a database. The connector came pre-governed; your MCP server is governed by whatever you remembered to build.

So the honest comparison is not "MCP versus connector." It is "cross-source reasoning versus operational simplicity." Sometimes that trade is spectacular, and sometimes it amounts to buying yourself a server bill to answer questions a connector already answered. It is your job as an architect to know which of the two situations you are standing in.

The decision signal

After building both versions side by side, the rule I trust fits in one sentence:

When your agent needs to reason across sources it did not know about at design time, that is your MCP signal.

In practice, I walk through the following four questions:

Does the answer live in one system? Use the connector. You are done, and you inherited Microsoft's operations team for free.
Does the answer require correlating two or more systems in a single reasoning pass? That is your MCP signal. No amount of prompt engineering will give a single-source agent data it cannot reach.
Will the source list grow? MCP servers compose. Adding a third source to the Orion agent is another server registration, not a rebuild.
Can you operate a service? If the answer is no, that is not a character flaw, but keep in mind the connector ceiling is your ceiling until that answer changes.

Build it yourself

Everything in this post is reproducible from the lab I published for my Community Summit NA 2026 session in Nashville, "Same Agent, Two Architectures: When MCP Wins (And When It Doesn't)". The repository contains the SQL schema and seed data, a script that creates all 35 GitHub issues, scaffold prompts for the MCP server and a Next.js health dashboard, and the Copilot Studio prompts for both agents -- including the intentionally limited one:

github.com/dgpblogster/project-orion-lab

You need VS Code, Node 18+, SQL Server Express, the GitHub CLI, Azure Dev Tunnels, and a Copilot Studio license -- a trial works just fine. Budget an afternoon, and make sure you build toward the moment where you ask both agents the release-blocker question back to back, because watching one agent hit the ceiling and the other reason straight through it will teach you more about agent architecture than any slide deck, including mine. The effort is well worth it!

If there is interest, my next installment will walk through hardening this MCP server for real production use -- authentication, hosting, and telemetry -- so please drop a note in the comments if you would like to see that. It is good to be back at the bench.

Until next post!

MG.-
Mariano Gomez Bent
Former Microsoft BizApps MVP

Power Apps - Application Monitoring with Azure Application Insights

2021-08-12T15:09:00.000-04:00

In this video, learn to enable Power Apps Application Monitoring with Azure Application Insights.

The following topics are covered in this video:

(0:00) - Intro

(0:36) - What is Azure Application Insights

(1:32) - The timesheet app

(2:12) - Creating an Application Insight for the timesheet application

(3:55) - Identify and copy the application instrumentation key

(4:09) - Enabling the timesheet application with the instrumentation key

(5:32) - Working with Application Insights

(8:06) - Outro

For additional information on Azure Application Insights, please follow these resources:

Microsoft Docs - What is Azure Application Insights? here

Adam Marczak - Azure for Everyone: Azure Application Insights Tutorial, here

To check out my YouTube channel visit: https://www.youtube.com/@workbench-blog

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Power Platform ALM - Visual Studio Code Extensions

2021-08-03T15:46:00.000-04:00

Learn about Power Platform extension for Visual Studio Code and how this toolset is improving both the code first developer experience and strengthening the ALM story.

The following topics are covered:

(0:00) - Intro
(1:16) - Installing the Power Platform extensions for Visual Studio Code
(2:13) - Working with the Power Platform CLI inside of Visual Studio Code
(3:42) - Authenticating to your environment from Power Platform CLI
(7:18) - Saving your canvas app to your local machine
(8:55) - Unpacking your canvas app
(10:19) - Using Visual Studio Code to make changes to your application
(11:50) - Packing and uploading your application changes
(13:55) - Outro

To check out my YouTube channel visit: https://www.youtube.com/@workbench-blog

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Power Automate | Passing Collections from Power Automate to Power Apps (Revisited)

2021-08-02T17:31:00.000-04:00

I revisit an old video I did couple years ago showing how to pass collections from Power Automate to Power Apps.

This time around, I show how to leverage arrays to accomplish the same. This time around you will learn about:

To check out my YouTube channel visit: https://www.youtube.com/@workbench-blog

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

The Workbench

Copilot Studio | The Skill That Isn't There

Copilot Studio | The Workflow That Runs Every Time

Power Apps | The Page That Reports Itself

Power Automate | Flows Without the Designer

Copilot Studio | Your MCP Server Now Needs a Key Vault

Power Apps | Rows Without an Owner

Power Apps | Ask in English, Get Rows Back

Copilot Studio | The Agent Your Flow Can't Call

Power Apps | Seven Skills, One Prompt: The Dataverse Plugin for Coding Agents

Power Automate | Licensing the Flow Nobody Owns

Copilot Studio | Grounding a Copilot Studio Agent on Azure SQL

Copilot Studio | Migrate the Agent, Keep the Client ID

Power Apps | Describe the App, Approve the Plan

Copilot Studio | Turning War Stories into Guardrails: Introducing pac-copilot-kit

Where it came from

From paragraphs to guardrails

How my own tool tried to lie to me

What live verification taught me, including about my own articles

The bottom line

Copilot Studio | Real ALM for Agents (and the One Click That Breaks Your Pipeline)

What Microsoft actually prescribes

The loop I actually ran

Scoring myself against the golden rules

Where the prescribed path runs out

The one click that breaks your pipeline

Why scripting the components sidesteps all of it

What this approach costs, honestly

So what does production actually look like?

The bottom line

Copilot Studio | Adding Dataverse Knowledge Sources with the Web API (the "UI-Only" Rule That Isn't)

First, which kind of agent? (This one matters)

Why bother?

Finding the shapes: mirror a working example

Step 0: the custom table (if you are grounding on one)

Step 1: create the dvtablesearch

Step 2: add the table(s) to it

Step 3: the botcomponent that makes it a knowledge source

Step 4: tie the component to the search config

Verify like the maker UI is watching

The bigger picture

Power Automate | Cloud Flow Telemetry with Azure Application Insights, Down to the Action Level

First things first: yes, the integration exists

The schema surprise: two tables, not one

Run-level monitoring: the baseline

Action-level monitoring: where the real value is

Three caveats before you turn everything on

What about custom telemetry from inside a flow?

Centralize it in a child flow

The bottom line

Power Automate | Design Every Flow So a Resubmit Is Always Safe

Why events arrive more than once

Sync the state, not the event

Let the source system name things

Gate the side effects on change

The payoff: resubmit becomes your universal tool

Two caveats from the field

The checklist

Power Automate | Getting Secrets Out of Your Flows with Azure Key Vault

Where a plaintext secret actually lives

The migration, in the order that worked

The gotcha: runtime RBAC follows the connection owner

The payoff shows up at deployment time

The other half: everything else into environment variables too

One Solution, Two Source Trees: The Maker Portal's Git Integration vs pac

Two formats, one solution

What happened to us

Why we picked the pac side

Two frictions that come with the pac side

What I would tell you to do

Building Power Automate Flows with Claude Code and FlowAgent

What FlowAgent is

Setting it up

Debugging: the single biggest win

Edits go where edits belong

Verification stopped being optional

The rough edges, honestly

What it added up to

If you try it

Same Agent, Two Architectures: When MCP Wins (and When It Doesn't)

Step 1: create the `dvtablesearch`

Step 3: the `botcomponent` that makes it a knowledge source