The Workbench

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

AI Builder Form Processing: Multi-layout Form Processing

2020-11-10T14:00:00.000-05:00

AI Builder Form Processing Multi-layout Form Processing has been one of the most requested features and is now available in preview for you to test. This feature allows you to process forms with a variety of different layouts (but similar in content) with a single model, which brings this feature one step closer to a scalable enterprise solution.

In this video I cover the following:

- Creating a model
- Form collections
- Training the form processing model
- Publishing the form processing model
- Testing the model

For additional information, please refer to:

Create a form processing model - click here
AI Builder form processing announcement - click 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: Application Lifecycle Management (Part 3/3) - Build and Release Pipelines

2020-10-20T16:15:00.000-04:00

Welcome to the final episode of Power Platform Application Lifecycle Management. In parts 1 and 2 you saw how to prepare your environments, set up an Azure DevOps project, and define Service Connections to your Power Platform environments.

In this, the final installment of this 3-part series, you will learn how to create the Build and Release pipelines using the Power Platform Build Tools to take your Power Platform solution from an environment, through source code control, through staging and production deployments.

Topics covered:

- Power Platform source code control with Azure Repos
- Build and Release pipelines
- Sharing your solution

References:

Power Platform Build Tools webinar - https://youtu.be/Qwue8fwetJA

Solutions Overview and Limitations - click 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: Application Lifecycle Management (Part 2/3) - Solutions and DevOps

2020-09-22T17:00:00.000-04:00

In the previous installment, you saw how to work through a set of prerequisites to get you going in your Power Platform Application Lifecycle Management journey. In this video, I will work through building an app and adding it to a solution and show you some additional Azure DevOps configuration options to link your repository to your Power Platform development environment.

Topics Covered:

1. Building app based on template
2. Adding your app to a solution
3. Linking your DevOps project to your Power Platform environment

References:
Power Platform Build Tools webinar - https://youtu.be/Qwue8fwetJA

Solutions Overview and Limitations - click 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: Application Lifecycle Management (Part 1/3) - Prerequisites

2020-09-14T15:42:00.000-04:00

This series is in response to multiple requests by my viewers to address the topic of Power Apps Application Lifecycle Management (ALM). This series is intended to breakdown the entire process in as much detail as possible, without lengthy explanations on how to get it done or, as often happens, little to no explanations on how you arrived at a particular step or result.

My first installment will focus on Prerequisites, this is, what you need to have in place to get started. I will walk you through provisioning your Power Platform Dev, QA, and Production environments, along with installing the Power Platform Build Tools and setting up your Azure DevOps project. I also explain the concept of solutions in Power Platform and why they are important to your ALM strategy.

Topics covered:

1. Creating Power Platform Environments
2. Azure DevOps and Installing Power Platform Build Tools
3. Creating an Azure DevOps Project
4. Solutions

References:
Power Platform Build Tools webinar - https://youtu.be/Qwue8fwetJA

Credits:
Summer - Bensound - Royalty free music at https://www.bensound.com

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: Transfer records from SharePoint list to Azure SQL database

2020-09-03T11:29:00.000-04:00

Majority of times, when we are working with various data sources, we want information to go from one source to another, conditioned to the occurrence of an event. Today, I will show you how to transfer records from a SharePoint list to Azure SQL database tables in response to a timesheet approval event. In the process, you will learn how I leveraged the existing Power Apps Expense template app and converted it into a Timesheet app for the purpose of recording time for various activities

Power Apps: Save Mixed Reality pictures to SharePoint

2020-08-10T14:57:00.000-04:00

In this video you will learn how to save pictures taken in Power Apps Mixed Reality or Augmented Reality viewer to a SharePoint document library.

Some topics covered include: Power Apps ForAll(), With(), Mid(), and Len() functions, the Self operator. Learn to use the Power Automate SharePoint connector and the Create File action, and the base64toBinary() function in an expression. Finally, you will see how you can call a flow from Power Apps to make it all work like a single application.

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: Working with Microsoft Graph API and Teams Connector

2020-07-28T21:33:00.000-04:00

In this video you will learn the basics of the Microsoft Graph API, how to use Graph Explorer, register an application to use Microsoft Graph in Azure Active Directory, and build a simple flow that will use the Teams Connector and Graph API to list a set of tabs in a Teams channel.

Other topics covered are: compose and HTTP actions, using the compose action as an alternative to variables, using the filter array action to filter the results in a JSON payload.

References:
Microsoft Graph: https://graph.microsoft.com

Credits:

Creative Minds - Bensound - Royalty free music at https://www.bensound.com

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: Calculate Soundex of a word with a flow

2020-07-07T09:25:00.000-04:00

In this video, I will be showing you how to use Power Automate to calculate the Soundex value of a word using a flow. This calculation uses the American standard algorithm, but can be adapted to support other algorithms developed for the English language.

In building the workflow you will learn how to use the Scope, Compose, and Append To String actions, the Do Until and If Then control structures, along with the substring(), replace(), add(), and mult() functions. Please leave your comments below.

References:
Wikipedia Soundex entry - https://en.wikipedia.org/wiki/Soundex

Downloads:
Power Automate Cookbook: Click 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 Automate: Building a REST endpoint with the HTTP Request connector

2020-06-19T18:41:00.000-04:00

In this video I show you how to build a REST endpoint with the Power Automate HTTP Request connector to be used as a web service to transfer data to a on-premises SQL database. In the process, I will be using Postman API development platform to test the endpoint and submit data to a Microsoft Dynamics GP company database via its eConnect API stored procedures.

To check out my YouTube channel visit: https://www.youtube.com/@workbench-blog

LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Power Apps: Calculating various dates with date functions

2020-06-10T16:58:00.000-04:00

In this article, I will show you how to leverage the DateDiff(), DateAdd(), Weekday(), DateValue(), and Day(), and Today() functions to calculate all sort of dates that are typical to business applications: first and last day of previous month, first and last day of previous quarter, first and last day of previous week, first and last day of current month, first and last day of current quarter, first and last day of current week, first and last day of next month, first and last day of next quarter, first and last day of next week, etc.

Let's begin:

Each calculation is self-contained for convenience sake, which means the only dependency is on the cdt context variable.

Current Date

UpdateContext({cdt:Today()});

Note: you could also use the Now() function, but be aware that this function also includes the timestamp.

First Day of Previous Month

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            mts: DateDiff(
                rootdate,
                cdt,
                Months
            ) - 1
        },
        DateAdd(
            rootdate,
            mts,
            Months
        )
    )
)

Last Day of Previous Month

DateAdd(cdt, -Day(cdt), Days)

First Day of Current Month

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            mts: DateDiff(
                rootdate,
                cdt,
                Months
            )
        },
        DateAdd(
            rootdate,
            mts,
            Months
        )
    )
)

Last Day of Current Month

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            mts: DateDiff(
                rootdate,
                cdt,
                Months
            ) + 1
        },
        With(
            {
                FirstNxtMonth: DateAdd(
                    rootdate,
                    mts,
                    Months
                )
            },
            DateAdd(
                FirstNxtMonth,
                -1,
                Days
            )
        )
    )
)

First Day of Next Month

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            mts: DateDiff(
                rootdate,
                cdt,
                Months
            ) + 1
        },
        DateAdd(
            rootdate,
            mts,
            Months
        )
    )
)

Last Day of Next Month

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            mts: DateDiff(
                rootdate,
                cdt,
                Months
            ) + 2
        },
        With(
            {
                FirstNxtMonth: DateAdd(
                    rootdate,
                    mts,
                    Months
                )
            },
            DateAdd(
                FirstNxtMonth,
                -1,
                Days
            )
        )
    )
)

First Day of Previous Quarter

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            qtrs: DateDiff(
                rootdate,
                cdt,
                Quarters
            )
        },
        DateAdd(
            rootdate,
            qtrs - 1,
            Quarters
        )
    )
)

Last Day of Previous Quarter

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            qrtr: DateDiff(
                rootdate,
                cdt,
                Quarters
            )
        },
        With(
            {
                NxtQrtr: DateAdd(
                    rootdate,
                    qrtr,
                    Quarters
                )
            },
            DateAdd(
                NxtQrtr,
                -1,
                Days
            )
        )
    )
)

First Day of Current Quarter

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            qtrs: DateDiff(
                rootdate,
                cdt,
                Quarters
            )
        },
        DateAdd(
            rootdate,
            qtrs,
            Quarters
        )
    )
)

Last Day of Current Quarter

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            qrtr: DateDiff(
                rootdate,
                cdt,
                Quarters
            ) + 1
        },
        With(
            {
                NxtQrtr: DateAdd(
                    rootdate,
                    qrtr,
                    Quarters
                )
            },
            DateAdd(
                NxtQrtr,
                -1,
                Days
            )
        )
    )
)

First Day of Next Quarter

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            qrtr: DateDiff(
                rootdate,
                cdt,
                Quarters
            ) + 1
        },
        With(
            {
                NxtQrtr: DateAdd(
                    rootdate,
                    qrtr,
                    Quarters
                )
            },
            DateAdd(
                NxtQrtr,
                0,
                Days
            )
        )
    )
)

Last Day of Next Quarter

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            qrtr: DateDiff(
                rootdate,
                cdt,
                Quarters
            ) + 2
        },
        With(
            {
                NxtQrtr: DateAdd(
                    rootdate,
                    qrtr,
                    Quarters
                )
            },
            DateAdd(
                NxtQrtr,
                -1,
                Days
            )
        )
    )
)

First Day of Previous Week

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            diffval: DateDiff(
                rootdate,
                cdt,
                Days
            ),
            Offset: 1 - Weekday(cdt)
        },
        DateAdd(
            cdt,
            Offset - 7,
            Days
        )
    )
)

Last Day of Previous Week

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            diffval: DateDiff(
                rootdate,
                cdt,
                Days
            ),
            Offset: 1 - Weekday(cdt)
        },
        DateAdd(
            cdt,
            Offset - 1,
            Days
        )
    )
)

First Day of Current Week

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            diffval: DateDiff(
                rootdate,
                cdt,
                Days
            ),
            Offset: 1 - Weekday(cdt)
        },
        DateAdd(
            cdt,
            Offset,
            Days
        )
    )
)

Last Day of Current Week

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            diffval: DateDiff(
                rootdate,
                cdt,
                Days
            ),
            Offset: 1 - Weekday(cdt)
        },
        DateAdd(
            cdt,
            Offset + 6,
            Days
        )
    )
)

First Day of Next Week

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            diffval: DateDiff(
                rootdate,
                cdt,
                Days
            ),
            Offset: 1 - Weekday(cdt)
        },
        DateAdd(
            cdt,
            Offset + 7,
            Days
        )
    )
)

Last Day of Next Week

With(
    {rootdate: DateValue("01/01/1900")},
    With(
        {
            diffval: DateDiff(
                rootdate,
                cdt,
                Days
            ),
            Offset: 1 - Weekday(cdt)
        },
        DateAdd(
            cdt,
            Offset + 13,
            Days
        )
    )
)

You can download the application on the Power Apps Community apps gallery

To check out my YouTube channel visit: https://www.youtube.com/@workbench-blog
LIKE AND SUBSCRIBE!!!

Until next post!

MG.-
Mariano Gomez, MVP

Power Apps: Mixed Reality spatial controls

2020-06-08T12:35:00.000-04:00

For the final installment of the Power Apps Mixed Reality series, I'm going to show you how to use the MR spatial controls, Shape in MR and Measure in MR. You will get to understand a bit more about the available properties for these controls and how they interact with collections and galleries to produce an app.

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 | 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)

Background

Version 1: the connector agent

Version 2: the MCP agent

The moment it earns its keep

What MCP costs you

The decision signal

Build it yourself

Power Apps - Application Monitoring with Azure Application Insights

Power Platform ALM - Visual Studio Code Extensions

Power Automate | Passing Collections from Power Automate to Power Apps (Revisited)

AI Builder Form Processing: Multi-layout Form Processing

Step 1: create the `dvtablesearch`

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