Dynamics 365 Copilot Capacity Budgeting Just Lost Its Calendar

A finance director and IT director review a cloud service capacity dashboard on a boardroom screen

A finance director we work with spent most of August putting together next year’s Copilot capacity budget for Dynamics 365 Sales the way her team always had: pull the spring release wave notes, pull the fall ones once they land, estimate how many new agent-driven features will touch the message pool, and set a prepaid capacity number that should hold until the next twice-yearly review. On August 25, that whole planning ritual stopped making sense. Microsoft announced it was retiring the release wave model entirely, and with it the predictable calendar that Dynamics 365 Copilot capacity budgeting has quietly depended on since agent-based features started billing by consumption instead of by seat.

If your organization runs Sales Qualification Agent, Sales Opportunity Agent, Sales Close Agent, or Recommended Actions Agent inside Dynamics 365 Sales, this is not a housekeeping change you can skim past. Those agents draw against the same shared Copilot Studio message capacity as every other AI feature on your tenant, and the mechanism Microsoft used to signal “new capability incoming, plan accordingly” just went away.

What Microsoft actually changed

For years, Dynamics 365, Power Platform, and Dataverse published a Release Wave 1 plan in the spring and a Release Wave 2 plan in the fall, each one a large, dated document listing what was coming and roughly when. Microsoft’s August 25 announcement folds all three product lines into the AI at Work roadmap, a single continuously updated destination that already covered Microsoft 365 Copilot and other AI capabilities. New features now get published individually, as soon as a plan is committed and ready to share, rather than batched into one of two annual releases. Each item on the new roadmap carries a status: In Development, Rolling Out, or Launched, and organizations can filter the view down to the products they actually run.

The transition runs through the back half of 2026. Existing release plan content with a preview or GA date of June 1, 2026 or later is migrating onto the new roadmap between September and November. The old Release Planner tool retires on November 15, 2026, though Microsoft says the historical plans will stay archived on Learn for reference rather than disappearing outright. Functionally, this means there will be no Dynamics 365 2026 release wave 2 as a discrete document. Capabilities that would have shipped under that banner are instead appearing on the AI at Work roadmap as they become ready, which for a CIO or IT director used to scanning one document twice a year is a meaningfully different rhythm to plan around.

Abstract illustration of a digital capacity gauge filling as streams of data particles flow into it

Why Sales Qualification Agent makes this concrete, not abstract

The reason this matters more for Sales and Customer Insights teams than for most other parts of Dynamics 365 is billing mechanics. Sales Qualification Agent, which researches inbound leads against a defined target customer profile and, in its research-and-engage mode, autonomously sends outreach and evaluates BANT criteria before handing qualified leads to a seller, does not bill per seat. Neither do its siblings. All four of the consumption-based Sales agents draw down Copilot Studio messages, the same billing unit Microsoft uses across its agent portfolio, and message consumption scales with how complex each interaction is rather than with how many users are licensed.

That capacity is purchased two ways, and most enterprise tenants end up running both at once. Prepaid capacity comes as message pack subscriptions bought through the Microsoft 365 admin center or a partner, assigned to a Power Platform environment, then linked to the Dynamics 365 Sales environment that will actually consume it. Pay-as-you-go billing charges for whatever gets used beyond that, provided the tenant has an Azure subscription linked to Power Platform. Prepaid capacity is always drawn down first, with pay-as-you-go picking up the overflow, and when both run dry the AI capabilities simply stop working. Dynamics 365 Sales does send in-app notifications as quota runs low, but by the time a seller notices Sales Qualification Agent has gone quiet, the qualification and outreach work it was doing has already stalled.

The detail that should worry a budget owner more than the billing model itself is that this message capacity is shared across the entire Power Platform environment, not ring-fenced for Sales. If your Customer Service team turns on a new Copilot capability, or someone in IT stands up an unrelated agent in the same environment, it draws from the identical pool that Sales Qualification Agent depends on to keep researching and engaging leads. Under the old wave model, at least you knew twice a year, in one document, roughly what new capacity-hungry features were about to land across the whole product family and could size your purchase accordingly. Under the always-on model, that visibility has to be built by your team instead of handed to you on a schedule.

What changes in Dynamics 365 Copilot capacity budgeting

None of this means the AI at Work roadmap is worse information than the old release plans. If anything, seeing individual features move through In Development, Rolling Out, and Launched stages in near real time is more accurate than a document that was often stale within a few months of publication. What changes is the operating rhythm your finance and IT teams need around it. A capacity budget that gets set once or twice a year and left alone until the next wave review was already a rough approximation. Now that the calendar cue for “review it again” is gone, treating capacity planning as a periodic project rather than a standing operational discipline will let gaps accumulate quietly until a quota depletion notice arrives at an inconvenient moment.

The practical fix is to move ownership of Dynamics 365 Copilot capacity budgeting from an annual or semi-annual planning exercise to a monitored, recurring process, and to assign it explicitly rather than assuming it falls out of the old wave cycle by habit. The Power Platform admin center already shows Copilot Studio message capacity and consumption at the environment level, and pay-as-you-go usage can be tracked and bounded with spending limits in Azure Cost Management. Neither tool is new. What is new is that nobody is going to hand you a twice-yearly reminder to go look at them.

Three changes are worth making before the Release Planner actually shuts down in November. First, subscribe to the AI at Work roadmap’s filtered view and RSS feed for the specific products your tenant runs, rather than relying on someone remembering to check a bookmark that no longer gets updated on a predictable schedule. Second, replace the biannual capacity review with a monthly or quarterly one, sized to how quickly your Sales, Service, and any other Copilot-consuming teams are actually adding agent capability, since a tenant running only Sales Qualification Agent has a very different burn rate than one that has also turned on Recommended Actions Agent and a Customer Service copilot in the same environment. Third, make sure whoever owns the Azure Cost Management budget for Power Platform pay-as-you-go spend is the same person, or is at least in the same room, as whoever owns the Dynamics 365 Sales rollout plan, because the two decisions are now effectively one decision made in two different admin portals.

We’ve helped clients rebuild exactly this kind of monitoring cadence after a licensing or capacity surprise forced the issue, and it is far less painful to set up deliberately than to reconstruct after an outage. The underlying lesson from Microsoft’s roadmap change is not that anything about Sales Qualification Agent or its sibling agents got worse. It is that a planning habit built around a fixed calendar just lost its calendar, and the tenants that notice first will be the ones that already treat capacity as something to watch continuously rather than something to budget for twice a year and forget.


#DynamicsSales #CopilotCapacity #SalesQualificationAgent #PowerPlatformGovernance #AIatWorkRoadmap #EnterpriseAI

Power Platform Connector Certification Just Got Faster. Your DLP Policy Still Has a Gap It Doesn’t Close.

An IT governance leader reviewing a connector security and data classification dashboard in a modern office

An IT Director at a mid-size manufacturer recently found herself trying to explain, in a security review, why the company had eleven custom connectors feeding Copilot Studio agents and Power Automate flows, and why only three of them could be governed with any real precision. The other eight sat in a tenant-level policy bucket, classified by a URL pattern someone had written eighteen months earlier, long before anyone imagined an agent would be reading from that endpoint autonomously. Nobody had done anything wrong. The tooling simply hadn’t caught up to how fast custom connectors were multiplying once agentic AI entered the picture.

That gap between what Microsoft’s first-party and certified connectors can be governed with, and what a homegrown custom connector can be governed with, has existed for years. It matters more now because Copilot Studio agents lean heavily on custom connectors to reach line-of-business systems, and every one of those connectors is a new surface for a data loss prevention (DLP) policy to either control precisely or wave through by default. Microsoft’s overhaul of Power Platform connector certification, now routed through Partner Center, is worth a close look, not because it makes publishing easier (though it does), but because of what certification actually changes about how a connector can be governed afterward.

The governance gap custom connectors created

Power Platform’s DLP model treats connectors in three tiers: Business, Non-Business, and Blocked, with a rule that data can’t move between a Business-tier connector and a Non-Business one in the same flow or app. Certified and Microsoft first-party connectors slot cleanly into that model at the environment or tenant level. Custom connectors do too, technically, but the mechanics are cruder. At the environment level, an admin classifies each custom connector individually by name. At the tenant level, classification runs on URL pattern matching against the connector’s host address, using ordered allow and deny rules that end in a wildcard catch-all. It works, but it asks a governance team to maintain URL pattern lists by hand, and it treats a connector’s trustworthiness as a function of its address rather than anything Microsoft has actually reviewed.

Advanced Connector Policies (ACP), the newer and stricter allowlist model Microsoft has been rolling out for tenant-wide connector governance, makes the distinction sharper. ACP applies to certified connectors. Custom connectors and HTTP-based connectors, including the generic HTTP connector and HTTP Webhook triggers that many home-grown integrations depend on, are explicitly not supported in ACP as of this writing and still require classic DLP policies or connector endpoint filtering. In practice, that means a company standardizing on ACP for its governed estate is, by definition, leaving its custom connectors in a separate, less rigorous governance lane, no matter how business-critical those connectors have become.

What actually changed in Power Platform connector certification

Microsoft’s new certification pathway moves connector and Copilot plugin submissions into Partner Center, tied to enrollment in the Microsoft 365 and Copilot program. The prior process required manual review that partners reported taking two to five weeks, with limited visibility into where a submission stood or what specifically had failed if it was rejected. The Partner Center path automates the review, gives submitters real-time status and error detail, and covers four scenarios: new custom connectors built in Power Automate, version upgrades to already-certified connectors, custom connectors paired with an associated Copilot plugin, and version upgrades to that paired combination.

Once certified, a connector stops being a homegrown artifact and becomes a standard connector in Microsoft’s catalog. It shows up in the same list as first-party connectors in Power Automate, Power Apps, and Logic Apps, and if it has an associated plugin, that plugin becomes available for admins to enable through the Microsoft Admin Center for Copilot for Microsoft 365. For an enterprise that built an internal connector purely to reach an ERP or CRM system from a Copilot Studio agent, and never intended to publish it externally, this is the detail that matters most: certification is not only a go-to-market lever for ISVs, it is a path out of the custom connector governance lane described above.

Illustration of a digital padlock connecting through a certification gateway, representing connector certification and security governance

What certification does, and does not, fix

It would be a mistake to read this as Microsoft closing the governance gap entirely, and a CIO evaluating whether to push a critical connector through certification should go in with accurate expectations. Certification moves a connector into the standard three-tier DLP classification that Business and Non-Business connectors already use, replacing the name-based or URL-pattern approach reserved for custom connectors. That is a genuine improvement in precision, and it makes a connector eligible for ACP’s stricter allowlist model instead of being permanently excluded from it.

What certification does not do is retroactively fix the connectors an organization decides not to certify, and it does not extend ACP support to HTTP or HTTP Webhook connectors, which remain governed under classic DLP regardless of certification status elsewhere in the estate. A company with a mixed environment, some certified connectors under ACP and a long tail of custom and HTTP connectors under classic DLP, is still running two governance models side by side. Certification narrows that split. It does not eliminate it.

There is also a real cost to weigh. Certification requires standing up a Partner Center account, completing verification materials, and enrolling in the Microsoft 365 and Copilot program, none of which is a five-minute administrative task. For a connector built and used entirely inside one business unit with no reuse potential, that overhead is unlikely to pay for itself. For a connector that a dozen teams route sensitive financial, HR, or customer data through, or one that sits underneath a production Copilot Studio agent making autonomous decisions, the calculus is different.

Deciding which connectors are worth the investment

The practical question for an IT Director or CIO is not whether to certify every custom connector in the tenant. It is which ones justify the enrollment overhead and the ongoing maintenance of keeping a certified version current as the underlying API changes. Three characteristics are worth screening for. First, does the connector back a Copilot Studio agent or automated flow that acts on data without a human reviewing every step, since that is precisely the scenario where blunt, address-based DLP classification is riskiest. Second, is the connector reused across more than one business unit or environment, since URL-pattern tenant policies were never designed to express nuance across multiple consuming teams with different data sensitivity needs. Third, does the connector touch data categories, financial reporting, payroll, customer records, that already sit under stricter internal data handling policy, where a coarser custom-connector classification is a harder position to defend in an audit.

Connectors that fail all three tests, a one-off integration built by a single team for an internal utility with no agent dependency, probably do not need to go through Partner Center at all. The classic DLP tools, applied deliberately rather than left on default settings, are adequate for that tier. Where the calculus shifts is in exactly the kind of estate the manufacturer’s IT Director was trying to defend: a small number of connectors that carry disproportionate risk because of what they connect to and what increasingly autonomous agents do with that access.

Where this fits in a broader governance plan

None of this replaces the fundamentals. A tenant that has not yet adopted DLP custom connector parity, the capability that lets custom connectors be classified individually rather than only by URL pattern, should do that first, since it is available today at no additional cost and requires no Partner Center enrollment. Certification is the next step up for the specific connectors where individual classification still is not precise enough, and where eligibility for ACP’s allowlist model is worth the administrative investment.

Routeget Technologies has walked several clients through exactly this kind of connector inventory exercise, mapping which integrations sit behind agentic workflows and which ones are candidates for certification versus tighter classic DLP rules. The pattern that keeps showing up is not that organizations have too many custom connectors. It is that almost none of them have ever been ranked by actual risk, which is what makes the certification decision harder than it should be. Microsoft has removed the excuse that certification takes too long. The remaining work, deciding which connectors actually warrant it, is squarely a governance decision, not a technical one, and it belongs on the same review calendar as any other access control question in an increasingly agent-driven Power Platform estate.


#PowerPlatformGovernance #CustomConnectors #DataLossPrevention #CopilotStudio #EnterpriseAI #ConnectorCertification

Copilot Studio MCP Server Authentication Isn’t a Checkbox. It’s a Governance Decision.

Solution architect reviewing an authentication and identity security dashboard on a large monitor, representing Copilot Studio MCP server authentication decisions

Copilot Studio MCP server authentication looks like a minor setup screen right up until it isn’t. A solution architect wires a custom MCP server into a Copilot Studio agent during a proof of concept, picks API key authentication because it takes ten minutes to configure, and moves on to the parts of the demo that actually need attention. Six weeks later the same agent is heading into a security review before production rollout, and the reviewer asks a question the architecture can’t answer: which specific user pulled which record through that tool call last Tuesday. With API key auth, the answer is nobody, or rather, everybody, because the key authenticates the connection, not the person using it. The rebuild that follows isn’t a settings change. It’s a different authentication architecture, registered with a different set of Entra ID app registrations, and it usually lands in the same week the go-live date was supposed to be locked.

This is a pattern worth naming because Copilot Studio MCP server authentication makes the wrong choice look reasonable in the moment. When you connect an agent to a custom Model Context Protocol server, whether that server exposes an ERP system, a proprietary data warehouse, or an internal API nobody else has touched, the platform hands you three authentication paths with almost no friction between them: none, API key, and OAuth 2.0. Only one of those paths gives you per-user identity, auditability, and the kind of least-privilege access that a governance team will actually sign off on. Picking correctly the first time saves a rebuild; picking correctly also means understanding a few implementation details that the onboarding wizard doesn’t surface until something breaks.

Solution architect reviewing an authentication and identity security dashboard on a large monitor, representing Copilot Studio MCP server authentication decisions

What Copilot Studio MCP Server Authentication Actually Offers

When you add a custom MCP server as a tool through the agent’s Tools page, using either the MCP onboarding wizard or a Power Apps custom connector built from an OpenAPI schema, Copilot Studio asks you to pick an authentication type for that connection. “None” skips authentication entirely, which is fine for an internal sandbox and indefensible for anything touching production data. API key authentication sends a static credential in a header or query parameter, and every user of the agent shares that same credential. It’s fast, it works, and it’s the reason so many pilots quietly graduate into unauditable production integrations: nobody revisits an auth decision that isn’t currently causing a visible problem.

OAuth 2.0 is where the real architecture decision sits, and Copilot Studio actually gives you three variants of it, not one. Dynamic Discovery is the simplest to configure on the Copilot Studio side, but it depends on the MCP server supporting OAuth 2.0 Dynamic Client Registration with a discovery document, so the burden shifts to whoever builds the server. Dynamic mode supports DCR without a discovery mechanism, which means you supply the authorization and token URLs by hand but the client still registers itself with the identity provider. Manual configuration is the fallback most teams end up using with an existing enterprise identity provider like Microsoft Entra ID: you supply a client ID, client secret, authorization URL, token URL, refresh URL, and optional scopes, and Copilot Studio generates a callback URL that has to be registered with that identity provider before the connection will work.

The reason Manual OAuth 2.0 is worth the extra setup time is the delegation model underneath it, not the configuration effort itself. Done correctly, the MCP server acts on behalf of the signed-in user rather than as an anonymous service account, which means access is bounded by what that specific person is entitled to see and every call can be traced back to an identity. That’s the difference between an integration a Center of Excellence team can approve and one it has to escalate.

Building the Delegated Flow Correctly

The Manual OAuth path requires two separate Entra ID app registrations, and skipping this distinction is where most first attempts go wrong. The first registration belongs to the MCP server itself, configured as an OAuth 2.0 resource server: you expose an API on that registration, set an Application ID URI, and add a scope such as access_as_user that supports both admin and user consent. The server’s own configuration then needs the tenant ID, client ID, and that scope so it can validate incoming tokens and, if it needs to call something like Microsoft Graph downstream, do so through an on-behalf-of flow rather than its own service identity.

The second registration belongs to Copilot Studio, acting as the OAuth client. This registration needs delegated permission to call the server’s access_as_user scope, and here’s the step that trips up teams building this for the first time: Copilot Studio doesn’t generate the redirect URI until after you’ve created the internal custom connector, and that URI, in the format https://global.consent.azure-apim.net/redirect/[id], has to be manually added back into the client app registration’s authentication settings afterward. Miss that step and the OAuth handshake fails at the consent screen with an error that doesn’t obviously point back to a missing redirect URI. Admin consent for the scope is optional; without it, every individual user gets prompted to consent the first time they trigger the tool, which is usually the right default for a least-privilege rollout but worth deciding deliberately rather than discovering in front of end users.

Illustration of a digital key passing through a secure gateway into a server, representing an OAuth 2.0 delegated authentication flow for an MCP server

The Token Refresh Problem You Should Test Before Rollout

Here’s the detail that doesn’t show up in the setup documentation and genuinely affects production reliability: multiple teams building Manual OAuth 2.0 connections against MCP servers fronted by Azure API Management have reported that Copilot Studio does not silently refresh an expired access token the way other MCP clients do. Instead of a background token refresh, users get a reconnection prompt asking them to open the connection manager and re-authenticate, even though the refresh URL is configured and API Management logs show no request ever reaching the token endpoint. Microsoft staff responding on the official Q&A forum acknowledged the documentation describes refresh URL support without fully documenting how automatic refresh is supposed to behave, and as of this writing there’s no confirmed, universally reproducible fix. Some teams report improvement after explicitly requesting the offline_access scope and ensuring it carries admin consent in the Entra app registration, including through an on-behalf-of token exchange if that pattern applies, while others have tried the same configuration in similar API Management and Dynamics 365 scenarios without resolution.

The practical implication isn’t to avoid Manual OAuth 2.0. It’s to test token expiry deliberately, before go-live, rather than discovering it from a support ticket after users start hitting reconnection prompts mid-conversation with the agent. Set a short token lifetime in a test environment, let it lapse mid-session, and watch what actually happens to the user experience. If your identity provider and MCP server both support Dynamic Discovery, it’s worth evaluating as an alternative specifically because it removes a layer of manual refresh-URL plumbing that you’d otherwise be responsible for getting right yourself, though it doesn’t eliminate the need to validate refresh behavior end to end.

Governance Doesn’t Stop at the Connection

One detail that often gets missed in the rush to get a tool call working: MCP connections in Copilot Studio still respect the Power Platform connector data policies your organization has already configured, and they require the agent to be running on the standard harness rather than the classic one. That means a Data Loss Prevention policy that blocks a connector for other reasons will also block it here, which is good news for governance teams worried about a new class of integration bypassing controls they’ve already invested in, and worth confirming explicitly during design rather than assuming.

What This Means for the Next MCP Integration You Build

Treat the authentication model for a custom MCP server as an early design decision, not an implementation detail to finalize after the demo works. If the agent will ever touch data that someone will ask “who accessed this and when” about, plan for Manual OAuth 2.0 with delegated permissions from the start, budget time for the two-app-registration setup and the redirect URI step that has to happen after connector creation, and build token expiry testing into your pre-production checklist rather than treating a reconnection prompt as a surprise. The extra hour spent on the identity model up front is consistently cheaper than the week spent explaining to a security review why a proof-of-concept shortcut is now the production architecture. Routeget Technologies has walked several clients through exactly this kind of MCP and Copilot Studio authentication design during Power Platform governance engagements, and the pattern holds every time: the auth decision made in week one is the one everyone lives with, for better or worse, long after the pilot is forgotten.


#CopilotStudio #MCPServer #OAuthSecurity #AgenticAI #PowerPlatformGovernance #EnterpriseAI

Power Apps’ Model App-Builder Skill Just Reached GA. The Approval Step Needs a Real Definition.

IT director reviewing an AI-generated model-driven app blueprint on a monitor

An IT director at a mid-sized distribution company got a message last week that would have been unthinkable two years ago: a business analyst on the finance team had built a complete case-management app, tables, forms, a security role, and an approval workflow included, in an afternoon, by describing what she needed in plain English. No developer was involved. No ticket sat in a backlog. The app worked on the first try. The IT director’s reaction was not relief. It was a question nobody on her team could immediately answer: who actually checked what that security role grants access to? The tool behind the app, it turned out, was the newly generally available Power Apps Model App-Builder Skill.

That scenario is no longer hypothetical. Microsoft’s September 2026 Power Platform update confirmed general availability for the Power Apps Model App-Builder Skill, a capability that lets makers use AI coding tools such as GitHub Copilot CLI or Claude Code to generate an entire model-driven app from a natural-language description, including Dataverse tables, forms, views, sitemaps, security roles, business process flows, and business rules. This sits alongside the already-GA generative pages capability, which handles individual pages inside a model-driven app the same way. Put together, the distance between “someone wrote a paragraph describing an app” and “a production business process exists in Dataverse” has collapsed to something close to zero.

For a CIO or IT director already managing a Power Platform footprint, the interesting part isn’t the productivity story. That part is straightforward: fewer requests stuck behind a scarce pool of Dataverse developers, faster turnaround for genuinely simple line-of-business apps, and a natural entry point for citizen developers who previously needed a professional developer just to get a security role configured correctly. The interesting part is what happens between the prompt and the deployment, because Microsoft did build a checkpoint into this workflow. The question worth asking before turning it on broadly is whether that checkpoint checks the things an organization actually needs checked.

What the Power Apps Model App-Builder Skill Actually Generates

The documented workflow follows a pattern Microsoft has used elsewhere in its AI code generation tools for Power Apps: a planner agent reads the natural-language requirement and proposes a plan describing what it intends to build, the maker reviews that plan and can ask for adjustments, the maker confirms once the plan matches intent, and only then do specialized agents generate the artifacts and deploy them. Some workflows in this family include an optional verification pass using automated browser testing before the app goes live. Microsoft’s own guidance is candid about where responsibility lands afterward: the tools make “a best-effort attempt to generate complete, production-ready code with accessibility and security best practices,” but the maker is ultimately responsible for validating what gets produced.

That single sentence is worth sitting with, because it reframes what “the app worked on the first try” actually means. It means the functional description matched. It does not mean the security role’s field-level permissions match the organization’s data classification policy, or that the generated business rule doesn’t create a downstream conflict with an existing plugin, or that the sitemap navigation doesn’t expose a table that shouldn’t be visible to that user’s role. A business analyst confirming a plan in the reviewer step is answering “does this do what I described,” which is a different question from “is this safe to run in production,” and most of the people who will use this tool are, by design, not the people equipped to answer the second question.

Abstract illustration of an AI-generated application blueprint with tables and workflow icons being approved by hand

Not Every Piece of This Carries the Same Guarantee

There’s a second nuance worth flagging before any organization treats “Model App-Builder Skill: GA” as a blanket green light. The broader family of AI code generation tools for model-driven apps includes capabilities at different maturity levels within the same feature set. Microsoft’s own documentation for the related generative pages capability, for instance, states plainly that connector support for reaching data outside Dataverse is a preview feature, and adds the standard caution that “preview features aren’t meant for production use and may have restricted functionality.” That distinction matters in practice: a maker building a generated page or app that only touches Dataverse tables is working with generally available functionality, while a maker who extends that same generation flow to pull data through a connector has quietly stepped into preview territory without necessarily realizing it, since the interface doesn’t force that distinction on them.

The practical lesson isn’t that this capability is unready. It’s that GA status attached to a feature name in a release announcement doesn’t automatically extend to every path a user can take through that feature. Anyone signing off on a broad rollout should ask, capability by capability, which specific paths are GA and which are still preview, rather than accepting the headline classification at face value.

Where the Business Case Genuinely Holds Up

None of this argues against adopting the capability. The economics are real. Organizations running Power Platform at any scale already carry a backlog of small, well-understood app requests that never justify a professional developer’s time: an approval tracker for a regional office, a case log for a compliance team, an intake form tied to a simple review workflow. These are exactly the apps this tool is suited to generate, and getting them built by the people who understand the business process, without a six-week wait for developer capacity, is a legitimate efficiency gain. The plan-review step, imperfect as a security control, is also a genuine improvement over the alternative most organizations had before AI-assisted building existed, which was citizen developers hand-configuring security roles inside the maker portal with even less structured oversight than a mandatory plan review provides.

What to Put in Place Before Turning This On Broadly

The fix isn’t to block the capability. It’s to extend existing Power Platform governance so it explicitly accounts for AI-generated artifacts rather than assuming manually built and AI-generated apps carry the same risk profile by default. A few specific steps hold up in practice. First, the plan-review step needs a defined second reviewer for any app that generates a new security role or business process flow, someone who understands the Dataverse security model and can evaluate a generated role’s actual grants, not just the person who requested the app confirming it matches their description. Second, generated apps should flow through the same promotion gate as manually built ones before reaching a production environment, meaning a Managed Environment with rules that don’t exempt AI-generated solutions from the review and testing stages already required for everything else. Third, generated solutions should be identifiable as such, through naming convention or solution metadata, so a Center of Excellence audit can actually find and review them as a distinct population rather than discovering one during an incident. Finally, before authorizing broad use, someone on the platform team should walk through which specific capabilities inside this tool family are GA and which remain preview, since that boundary will keep shifting as Microsoft continues to expand it through 2026 release wave 2 and beyond.

None of this is a reason to slow-walk adoption. It’s a reason to make sure the governance conversation happens at the same speed as the feature rollout, rather than six months after the first generated security role turns up somewhere nobody expected it. The tools that let a business analyst build a working app in an afternoon are genuinely useful, and organizations that get the review discipline right early will capture that speed without absorbing the risk that comes from treating a functional plan review as if it were a security review. Routeget Technologies has been helping clients extend Center of Excellence frameworks to explicitly cover AI-generated Power Platform artifacts as this category of tooling matures, and the pattern holds across nearly every engagement: the technology is ready faster than the governance process is, and closing that gap deliberately is cheaper than closing it after something ships that shouldn’t have.


#PowerApps #ModelDrivenApps #AIAppBuilder #PowerPlatformGovernance #CitizenDevelopment #EnterpriseAI

Power Platform Agent Authentication Governance Reaches GA: What to Audit First

An IT administrator reviewing an agent identity and access governance dashboard on a large office monitor

A CISO at a mid-market manufacturer asked her Power Platform admin a simple question last month: how many Copilot Studio agents does the organization actually have running, and how many of them require anyone to prove who they are before they can use them? The admin came back three days later with a spreadsheet of 214 agents. Nineteen had “No authentication” configured. Four of those nineteen had access to a knowledge source containing vendor contract terms. Nobody remembered turning authentication off for any of them, because nobody had turned it on to begin with. It had simply never been set. That gap is exactly what Power Platform agent authentication governance, which reached general availability this month, was built to close.

Microsoft has been describing this exact scenario in its own guidance for a while. In a February 2026 security post, Microsoft described unauthenticated agents as a recurring pattern rather than an edge case: authentication gets “deactivated for testing, left in its default state, or misunderstood as optional,” and the result is an agent that anyone with a link can use, sometimes surfacing internal information through its topics, actions, or knowledge sources without anyone intending it to. The fix Microsoft has been building toward arrived this month, and it changes who is responsible for catching this problem before it reaches production.

What Power Platform Agent Authentication Governance Actually Does

The feature reached general availability on September 2, 2026, after a public preview that opened in late May. Listed in Microsoft’s release plan as “Manage agent security with enhanced admin controls,” it gives administrators a way to set authentication and access policy for agents centrally, at the environment or environment group level, inside the Power Platform admin center. Rather than relying on individual makers to choose the right authentication setting each time they build or republish an agent, an admin can now require Microsoft Entra ID authentication across a group of environments, permit a defined list of approved external identity providers for agents that genuinely need one, or block anonymous access outright.

The detail that matters most for a governance program is when these policies get enforced. This is not a design-time warning that a maker can dismiss and move past. Microsoft’s own documentation describes the policy as evaluated both when an agent is deployed and again at runtime, so a policy change made after the fact actually reaches agents that are already published, not just new ones being built going forward. That closes a gap that has existed in Copilot Studio governance for a while: DLP data policies could already restrict unauthenticated usage at the tenant level, but that control was blunt. It did not give admins a way to say, for example, that the environment group serving finance requires Entra ID, while a separate environment group hosting a public-facing customer service agent is allowed to run anonymously because that is the intended design.

That distinction is worth sitting with, because the instinct after reading a story like the manufacturer’s spreadsheet is to conclude that anonymous access is always the mistake. It isn’t. A number of legitimate agents, particularly ones embedded in Power Pages sites or public marketing properties, are supposed to be reachable without a sign-in. The problem in most organizations is not that anonymous agents exist. It is that nobody made a deliberate decision about which ones should, and the setting drifted in by default rather than by design.

Abstract illustration of glowing padlock and key icons connected in a network, representing agent identity and access governance

Why This Became Urgent Now

The timing lines up with a broader shift that most IT leaders are already tracking anecdotally even if they haven’t quantified it. Citizen-developer agent creation in Copilot Studio has grown faster than most organizations’ governance processes have kept pace with, and a maker publishing an agent from a template or a quick prototype rarely stops to think about identity architecture. Microsoft’s guidance on securing Copilot Studio deployments at scale describes a zoned model, where agents built by citizen developers are expected to carry the least privilege and the most constrained data access, and where authentication choices become progressively more deliberate as an agent moves toward professional development and broader distribution. Enforcement has lagged the model. Before this release, an admin who wanted to guarantee that zone boundaries actually held had to lean on DLP connector policies and manual audits, neither of which was built specifically to answer the authentication question.

There’s also a compliance dimension that will matter more to some organizations than others. Regulated industries, healthcare, financial services, and any company subject to a SOC 2 or ISO 27001 audit cycle have been fielding questions from auditors about AI agent access controls for a while now, often without a clean answer. A centrally enforced authentication policy, applied at the environment group level and demonstrably active at runtime rather than merely recommended at build time, gives those organizations something concrete to show. It is the difference between telling an auditor that agents are supposed to require authentication and showing them a Power Platform admin center screen where that policy is actually configured and enforced.

What to Audit Before You Roll This Out

The rollout sequence matters more than the feature itself, and getting it backwards creates its own incident. The first step is the one the manufacturer’s CISO already took: get a current inventory of every agent in the tenant and its existing authentication setting, broken down by environment. Most organizations doing this for the first time are surprised by the count, and a meaningful share of that surprise usually comes from test or proof-of-concept agents that were never decommissioned rather than from production systems.

Once the inventory exists, the harder work is deciding environment group boundaries before applying policy, not after. An environment group that mixes internal line-of-business agents with a customer-facing Power Pages chatbot forces an uncomfortable compromise: either weaken the policy to accommodate the anonymous agent or break a legitimate public integration. Splitting those into separate environment groups first, then applying a strict Entra ID requirement to the internal group and an explicit, reviewed exception for the external one, is the pattern that avoids both outcomes.

It is also worth coordinating this rollout with whoever owns DLP policy in the organization, since the two controls now overlap in purpose even though they operate at different layers. A tenant-wide DLP restriction on unauthenticated connector usage and an environment-group-level authentication requirement can either reinforce each other or produce confusing, hard-to-diagnose failures if they are configured without reference to one another. Treating this as a single governance conversation, rather than two separate admin tickets handled by different people, avoids that outcome.

Finally, this is a good moment to revisit whichever Center of Excellence process the organization uses to track agent inventory and ownership, since an authentication policy is only as good as the organization’s ability to know when a new agent shows up outside of it. The policy catches misconfiguration. It does not catch an agent nobody knew existed until the inventory audit runs again.

The Practical Takeaway

None of this requires a large project to act on immediately. A first pass, an inventory of current agents and their authentication settings, a decision about which environment groups genuinely need anonymous access and which don’t, and a staged policy rollout starting with the highest-risk internal environment group, is realistic within a normal sprint or two for most Power Platform admin teams. What changes with this GA release is that the tool for enforcing the decision now exists natively, rather than requiring a workaround built from DLP policies never designed for this specific job.

Routeget Technologies has been walking clients through Copilot Studio governance reviews since well before this feature existed, largely because the underlying problem, agents accumulating faster than anyone tracks their authentication posture, predates any specific Microsoft release. The general availability of centralized agent authentication governance does not solve that problem by itself. It gives the teams already paying attention to it a real lever to pull, and it gives the teams who haven’t started yet a clear, specific reason to.


#CopilotStudio #PowerPlatformGovernance #AgentAuthentication #AIGovernance #EnterpriseAI #DataLossPrevention

Why Your AI Builder Default Model Keeps Changing Without Warning

An IT governance leader reviewing an AI model version timeline on a widescreen office display

A finance team at a mid-size distributor built a Power Automate flow eighteen months ago that reads incoming vendor contracts, pulls out payment terms and renewal clauses with an AI Builder prompt, and routes a short summary to the approver queue. The flow still runs every morning. Approvals still clear. Nobody who built the flow works there anymore, and nobody currently on the team could tell you which language model is actually answering the prompt today. It is not the one that answered it when the flow went live, and there was no meeting, no change ticket, and no line in a release note that told anyone it had changed.

That gap is not a one-off. It is how AI Builder’s generative AI prompts are designed to work, and it is worth understanding before the next swap happens rather than after a downstream process quietly starts behaving differently.

AI Builder’s prompt capability, the “Create text using a prompt” action available in Power Automate and Power Apps, runs on the same Prompt Builder infrastructure Microsoft also surfaces inside Copilot Studio. Unless a maker deliberately pins a specific model, every one of those prompts runs against the AI Builder default model, and Microsoft’s own documentation is explicit that this default is “periodically upgraded as new, more capable models become generally available.” The upgrade happens on Microsoft’s schedule, not the customer’s, and it happens without a change request landing on anyone’s desk.

Why the AI Builder default model keeps changing

The churn is not hypothetical. Microsoft’s published model availability record for Copilot Studio and AI Builder prompts shows GPT-4o and GPT-4o mini retired in July 2025, replaced by GPT-4.1 and GPT-4.1 mini. The o1 reasoning model retired the same month in favor of o3, which was itself retired on December 4, 2025 and replaced by GPT-5 reasoning. As of the current documentation, GPT-4.1 mini is the default model behind AI Builder prompts. Sitting just behind it in experimental status, available in limited regions ahead of a wider rollout, are GPT-5.3 chat, GPT-5.2 reasoning, Claude Sonnet 4.6, Claude Opus 4.6, and Grok 4.1 Fast. Experimental status is where every prior default model spent its final months before becoming the new standard, so this list is a reasonably good preview of what gets promoted next.

This is not even the first time the underlying mechanism itself has changed. The original AI Builder GPT feature, announced in December 2023 on GPT-3.5-Turbo, was itself deprecated in favor of the current Prompt Builder architecture. Teams that built early automation on that first action had to migrate the action type entirely, not just adjust to a new model version answering the same call. The lesson from that history is that the platform underneath these prompts has changed twice already, and there is no reason to assume it stops changing now.

Abstract illustration of glowing spheres arranged in a rotation cycle, representing AI model versions turning over

Thirty days is the entire window

When Microsoft promotes a new default, the model it replaces does not disappear immediately. Documentation for Copilot Studio confirms that a retired model stays usable for up to one month after retirement, and there is a setting, buried under an agent’s Settings page in the Model section, called “Continue using retired models,” that lets a maker keep running the outgoing version during that window while testing against the new one. It is a genuinely useful control. The problem is that it lives inside Copilot Studio’s authoring surface, and most of the people who built and now maintain a production flow in Power Automate or an app in Power Apps have never opened Copilot Studio at all. The setting exists. Whether the person responsible for a given prompt even knows to look for it is a separate question, and for most organizations right now, the honest answer is no.

The practical risk is not that the new model performs worse. Often it performs better on the metrics Microsoft optimizes for. The risk is that a model swap can shift output length, formatting, tone, or how confidently it phrases an uncertain answer, and none of that shows up as an error. A prompt that used to return a clean three-sentence summary might start returning five sentences with a caveat clause, and if a downstream Power Automate step parses that output into a fixed-width field or feeds it into a condition check, the flow keeps running successfully while quietly producing something different from what was tested and signed off.

What bring-your-own-model actually fixes, and where it does not

Microsoft’s answer to this is a real one: since September 15, 2025, AI Builder and Copilot Studio prompts have supported bringing your own model from Azure AI Foundry instead of relying on the shared default. An organization deploys its own model in its own Foundry resource, connects the deployment’s chat completion endpoint inside the prompt editor, and from that point forward it owns the version, the region, and the retirement timeline. Nobody upgrades it out from under them. For a prompt that feeds a regulated process, or one where consistent output structure genuinely matters, this is the correct fix, and it has been generally available for a full year.

It comes with two limits worth knowing before anyone builds a governance policy around it. First, a bring-your-own model connected through Prompt Builder can only be used inside prompt actions themselves. It cannot serve as the primary orchestration and planning model for a Copilot Studio agent, so it solves the AI Builder prompt problem specifically rather than every generative AI surface in the platform. Second, GPT-5-class models are not currently supported for bring-your-own connections at all. An organization that has already standardized its Azure AI Foundry deployments on GPT-5 cannot yet point an AI Builder prompt at that same deployment, which means the newest, often best-governed model choice is precisely the one this workaround does not yet cover.

There is also a licensing wrinkle that changes how a team should think about where a prompt lives in the first place. AI Builder credits are consumed when a prompt runs inside Power Apps or Power Automate, but the same prompt running inside Copilot Studio does not draw down those same credits. Two functionally identical prompts can carry meaningfully different cost profiles purely based on which product surface invokes them, which is easy to miss when a finance team is estimating consumption ahead of a rollout.

The governance moves worth making now

None of this requires a large program to address, but it does require someone to own it deliberately rather than let the platform default apply by omission. Start with an inventory of every production flow or app using a Prompt Builder action, and flag which ones are pinned to a specific model versus riding the default, since only the latter is exposed to the thirty-day retirement clock at all. For anything feeding a regulated, financial, or customer-facing process, evaluate whether bring-your-own-model through Azure AI Foundry is worth the setup cost given its current limits. At the environment level, the Power Platform admin center lets administrators disable the “Preview and experimental AI models” feature and lock that setting tenant-wide through environment group rules, which is a low-effort way to keep makers from quietly adopting an experimental model that has not been through any review. Because AI Builder sits inside the Dataverse connector for data loss prevention purposes, existing DLP boundaries already extend to prompt outputs, so that control is worth confirming rather than assuming.

The technology here is not the risk. A rolling default model, upgraded on a vendor’s schedule with a one-month grace period, is a reasonable design for a platform serving millions of makers. The risk is that most organizations have not assigned anyone to watch that clock. The AI Builder engagements Routeget gets pulled into to troubleshoot rarely trace back to a broken prompt. They trace back to a model decision nobody revisited since the day the flow was built, quietly drifting further from what the business actually validated.


#AIBuilder #PowerPlatformGovernance #CopilotStudio #AIModelGovernance #AzureAIFoundry #EnterpriseAI

Power Automate Error Handling: Why Your Approval Flows Fail Silently

IT professional reviewing a Power Automate approval workflow dashboard on a monitor in a modern office

A finance manager submits a purchase requisition through a Power Automate approval flow on a Friday afternoon. The flow’s run history shows a clean green checkmark. Nobody gets an error notification. Nobody gets paged. And nobody notices that the requisition is still sitting in “Waiting for approval” three weeks later, because the connection that created the flow belonged to an employee who left the company the same week the flow ran. The flow didn’t crash. It just stopped being able to reach the approver, and the default configuration had no mechanism to tell anyone that had happened. This is the gap that Power Automate error handling, done properly, is supposed to close, and it’s a gap that most approval flows in production today were never built to cover.

This is the failure mode that makes approval flows uniquely dangerous among Power Automate use cases. A malformed SharePoint update or a broken HTTP call to an external API tends to fail loudly and immediately, inside a run that someone is watching because they just triggered it. An approval flow fails quietly, often days or weeks after it started, to an audience that has already moved on to something else. Power Automate error handling for approval-heavy processes has to account for that gap between when something breaks and when a human would otherwise notice, and the out-of-the-box behavior of a cloud flow does very little to close it.

What Actually Breaks an Approval Flow

Before building an error-handling pattern, it helps to know what you’re actually defending against, because the failure modes for approvals are more specific than generic connector errors. Microsoft’s own troubleshooting documentation for flow approvals names two conditions directly tied to the connection that created the approval: ApprovalConnectionOwnerNotFoundInGraph, which fires when the account that owns the Approvals connection has been deleted from Microsoft Entra ID, and ApprovalConnectionOwnerNotEnabledInGraph, which fires when that account still exists but has been disabled. Both are common consequences of ordinary offboarding, and both will stop an approval flow cold with no warning to the requester or the intended approver.

A second cluster of failures involves timing. ActionTimedOut occurs when a “Wait for an approval” action’s configured timeout expires before a decision is made, and OperationTimedOut shows up on longer-running processes that exceed the platform’s maximum flow run duration of thirty days. Left at their defaults, many approval actions simply run until someone acts on them or the flow hits that ceiling, which means a request can sit unresolved for weeks without the flow itself ever reporting an error, because from the platform’s perspective nothing has technically gone wrong yet.

A third category sits at the connection layer more broadly: InvalidConnection and ConnectionAuthorizationFailed errors, which surface when a password reset, an expired OAuth token, or a Conditional Access policy change invalidates the credentials a flow depends on. Microsoft’s guidance on broken connections is blunt about the underlying cause, noting that connections tied to individual user accounts break whenever that account’s password changes or the account is disabled, which makes personal connections a structurally poor choice for anything running unattended in production.

Why Power Automate Error Handling Doesn’t Happen by Default

The reason none of this shows up as a visible incident is that Power Automate’s default run-after configuration only wires one path: continue if the previous action succeeded. There’s no branch for failure unless you explicitly add one, and there’s no notification unless you explicitly build it. A flow that fails at the approval step simply shows a red icon in a run history that, realistically, nobody is checking unless they already suspect something is wrong. For a process with dozens or hundreds of concurrent approval instances across an organization, that’s not a monitoring gap. It’s the absence of monitoring entirely.

This is precisely the situation Microsoft’s own coding guidance addresses through Run After configuration, and it’s worth treating as the non-negotiable baseline for any approval flow that matters to the business, not an optional hardening step reserved for critical systems.

Abstract illustration of a broken chain link being reconnected by gears, representing Power Automate error handling and recovery

Building the Scope-Based Try, Catch, Finally Pattern

The standard architecture for this, and the one Microsoft’s guidance points toward, wraps the core approval logic in three scopes. The first, a “Try” scope, contains the actual approval request, the wait, and whatever downstream actions execute once a decision comes back. The second, a “Catch” scope, is configured through Run After to execute when the Try scope has failed, has timed out, or was skipped, which are the three states that indicate something went wrong rather than simply concluded. Inside the Catch scope, the result() expression combined with a Filter Array action pulls the specific error code and message out of the failed action, which is what lets a notification say “the approval connection owner was removed from Entra ID” instead of a generic “something failed.”

A third scope, often labeled “Finally,” is configured to run after the Catch scope regardless of outcome, meaning after it has succeeded, failed, timed out, or been skipped. This is where cleanup and status logging belong, because it executes whether the Try scope worked cleanly or not, which keeps your audit trail complete instead of only recording the failure path.

For notification and logging, Microsoft’s guidance is explicit that Application Insights should be the default target rather than writing to a SharePoint list or a Dataverse table with a dedicated logging flow, both because it avoids the performance cost of excessive custom logging and because it consolidates monitoring across many flows into one queryable location instead of scattering it flow by flow. The workflow() function is useful here too, since it returns the run’s ID and environment metadata, which you can use to build a direct link to the failed run and drop it straight into a Teams message or an email to whoever owns the process.

Hardening the Approval Action Itself

Beyond the general try/catch pattern, approval actions specifically benefit from three adjustments that are easy to skip during initial flow design. First, set an explicit timeout on the “Wait for an approval” action rather than leaving it at the default, and pair that timeout with a Run After branch that fires on “has timed out.” That branch should escalate, typically to a backup approver, a manager one level up, or a distribution list, rather than simply notifying that the deadline passed and leaving the request unresolved. Second, configure retry policies on the connector actions surrounding the approval, using an exponential backoff pattern (an initial interval that doubles or triples with each attempt, up to a defined cap) so that transient throttling from Microsoft Graph or Dataverse doesn’t get treated the same as a permanent failure.

Third, and most important given how often it’s the actual root cause, move production approval flows off personal connections entirely. A connection reference paired with a service principal, rather than a connection tied to whoever happened to build the flow, means the flow keeps running when that person changes teams, resets a password, or leaves the company, which directly eliminates the ApprovalConnectionOwnerNotFoundInGraph and ApprovalConnectionOwnerNotEnabledInGraph failure modes described earlier. This is also an offboarding process question as much as a technical one: whoever manages user departures needs to know which production flows depend on that person’s connections before the account gets disabled, not after an approval silently stalls.

Testing Failure Paths on Purpose

None of this is verified until you’ve actually watched it fail. Before a flow goes into production, it’s worth deliberately breaking it: disable a test account that owns a connection and confirm the Catch scope actually catches it, set an artificially short approval timeout and confirm the escalation branch fires, and revoke a connection mid-run to see whether the resulting error surfaces somewhere a person will actually see it. Teams tend to build the happy path carefully and assume the failure path will behave the same way, which is rarely true the first time it’s tested. A flow checker pass and a clean test run through the approval itself tell you almost nothing about how the flow behaves once something upstream goes wrong, and that’s exactly the scenario a production approval process will eventually face.

The Takeaway

Approval flows fail differently than most other automation, because the cost of an undetected failure compounds silently while everyone assumes the process is working. The fix isn’t exotic: Run After branching, a Try/Catch/Finally scope structure, retry policies with backoff, connection references instead of personal accounts, and centralized logging through Application Insights. What it requires is treating error handling as part of the initial build rather than a patch applied after the first incident. At Routeget Technologies, the approval flows we get called in to fix almost never fail because the underlying logic was wrong. They fail because nobody built a path for the flow to tell anyone it had a problem.


#PowerAutomate #ApprovalWorkflows #FlowErrorHandling #ConnectionOwnership #PowerPlatformGovernance #EnterpriseAutomation

Advanced Connector Policies Are GA. Here’s What Still Needs Classic DLP.

IT governance administrator reviewing a Power Platform connector policy dashboard on a widescreen monitor

An admin at a 400-environment tenant spent a Tuesday afternoon tracing why a maker in a finance sandbox could connect a flow to a third-party file-sharing connector that should have been blocked tenant-wide. The tenant-level DLP policy classified the connector as non-business. An environment-specific policy, created eighteen months earlier for a since-retired pilot project, had it classified as business instead, and because classic DLP evaluates every applicable policy and merges the results, the older, looser rule won for that one environment. Nothing was misconfigured in the sense of a typo or a missed checkbox. It was misconfigured in the sense that nobody could reason about which rule applied where anymore.

That kind of drift is the specific problem Advanced Connector Policies were built to close, and as of June 4, 2026, they are generally available across the Power Platform admin center. For solution architects and platform administrators who have spent years managing DLP through the classic business/non-business/blocked model, ACP is not a UI refresh. It changes the underlying enforcement model, and it does not yet cover everything classic DLP does, which means the real work right now is figuring out exactly where the boundary sits.

What Advanced Connector Policies Actually Change

Classic DLP lets an environment inherit from multiple overlapping policies at once: a tenant-wide baseline, group-level rules, environment-specific exceptions, sometimes all three stacked on top of each other. The runtime evaluates all of them and applies the most restrictive result for a given connector, which sounds safe until you have dozens of overlapping policies and nobody has a single view of what’s actually allowed in environment 214. Advanced Connector Policies replace that model with something much narrower: each environment can have exactly one effective ACP, either configured directly on the environment or inherited from an environment group, never both at once.

The more consequential change is the default posture. Classic DLP sorts connectors into three buckets and anything not explicitly sorted lands in a default bucket, which in practice means most connectors are reachable unless someone deliberately restricts them. ACP inverts that. It is a strict allowlist: every connector is blocked until an administrator explicitly allows it, and critically, newly released connectors are blocked by default rather than automatically available. That second part matters more than it looks. Under classic DLP, Microsoft ships a new certified connector and it’s immediately usable in every environment that doesn’t have an explicit block rule against it, which is exactly how ungoverned tools accumulate over time. Under ACP, a new connector requires deliberate action before anyone can touch it, which shifts the operational model from periodic cleanup to ongoing curation.

Action-Level Control and Where MCP Governance Fits

ACP also goes deeper than connector-level allow or block. Within an allowed connector, admins get visibility into individual triggers, regular actions, internal actions, and actions Microsoft has marked deprecated, and can block any of those independently, which is useful for pushing makers off a deprecated action a legacy flow still references without pulling the whole connector. One behavior worth knowing before you rely on it: once a connector is scoped down to specific allowed actions, any new action or trigger Microsoft adds later isn’t automatically included. It has to be added deliberately, consistent with the allowlist philosophy but meaning a connector configured carefully in June can quietly miss a capability Microsoft ships in September until someone revisits the policy.

IT governance administrator reviewing a Power Platform connector policy dashboard on a widescreen monitor

This is also where ACP intersects with agentic AI governance, worth calling out since most classic DLP writeups predate MCP entirely. Advanced Connector Policies give admins visibility into MCP servers alongside standard connectors and let them block an entire server, but they don’t yet offer granular control over individual tools exposed by that server. If a team stands up an MCP server bundling a dozen tools and you need eight of them permitted while two are blocked, ACP can’t currently express that: the block is server-wide or nothing. For organizations moving quickly on Copilot Studio agents and custom MCP integrations, that’s a real gap to plan around, since it means governance over agent tool access is currently coarser than governance over a standard connector’s actions.

What’s Still Missing, and Why Classic DLP Isn’t Going Away Yet

The limitation that will affect the most environments in practice is that ACP currently only governs certified connectors. Custom connectors and HTTP connectors, including HTTP with Azure AD and the endpoint filtering that lets admins restrict a custom or HTTP connector to a specific allowed URL pattern, are not supported in ACP today and have no committed timeline for parity. If your tenant relies on endpoint filtering to say, for instance, that a generic HTTP connector may only call approved internal APIs and nothing else, that control still lives entirely in classic DLP. Virtual connectors are a separate case again: Copilot Studio’s virtual connectors are being moved to a dedicated governance model built specifically for that surface rather than folded into ACP, and Power Automate desktop flow virtual connectors are being converted into certified connectors over time, at which point they’ll fall under standard ACP rules like anything else.

Microsoft’s answer to this gap is mixed mode, which is also the default state for any environment or environment group where ACP has been configured. In mixed mode, both classic DLP and ACP evaluate simultaneously and the platform applies whichever result is more restrictive. That’s a genuinely useful design for migration: an organization can build out its ACP allowlist for certified connectors incrementally, watch how it behaves in mixed mode against real usage for a few weeks, and keep the existing classic policy doing the work ACP can’t do yet, namely custom connectors, HTTP endpoint filtering, and virtual connectors. Only once an environment’s governance needs are fully expressible in ACP, which for most tenants means never for HTTP-heavy environments, should it be switched to ACP-only mode, which turns off evaluation of classic policies entirely for that scope and can only be reversed by reconfiguring the rule.

Abstract network diagram on a laptop screen showing allowed and blocked system connections

Design-Time Enforcement Is Rolling Out Workload by Workload

One detail that’s easy to miss in the announcement is that GA for ACP as a policy engine is not the same as GA for design-time enforcement across every maker surface. Design-time blocking, meaning a maker sees an error while building a flow or app rather than discovering the failure at runtime, is rolling out one workload at a time: Power Automate’s maker portal first, Copilot Studio next, and Power Apps’ maker portal after that. Until a given surface has design-time support, ACP still enforces at runtime there, which means a maker in Power Apps today can build and save a canvas app referencing a blocked connector and only find out it doesn’t work when the app actually runs. That’s a materially different experience from the flow-checker warning a Power Automate maker gets today, and it’s worth setting expectations accordingly with any citizen developer population still working primarily in Power Apps.

A Practical Migration Sequence

The organizations getting this right aren’t treating ACP as a lift-and-shift replacement for their existing DLP policy set. They start with an audit of what their current classic policies actually enforce, separating that into a certified-connector allowlist that can move to ACP and a residual set of custom-connector, HTTP endpoint-filtering, and virtual-connector rules that has to stay in classic DLP indefinitely. From there, building the ACP allowlist environment-group by environment-group, publishing it in mixed mode, and giving it real usage time before considering ACP-only mode avoids the failure pattern of flipping a switch tenant-wide and finding the gaps through a flood of support tickets. It’s also worth reconciling allowed-connector lists periodically through the Power Platform API rather than the admin UI alone, since retired or invalid connector IDs accumulate in a policy’s configuration and throw off the connector count the UI reports without actually blocking anything.

One operational gotcha worth flagging before it surprises anyone: removing an ACP rule from an environment group does not automatically remove that policy from environments that already inherited it, and removing an environment from a group retains whatever ACP configuration it last had rather than reverting to unrestricted. That’s a deliberate design choice to prevent a connector from becoming unexpectedly available during a reorganization, but it means offboarding an environment from group-based governance requires an explicit cleanup step, not just a drag-and-drop out of the group.

None of this makes classic DLP obsolete, at least not on any announced timeline, and treating ACP’s June GA as a mandate to migrate everything immediately would be a mistake for any tenant with meaningful HTTP or custom connector usage. What it does change is the ceiling on how precisely certified-connector access and AI agent tooling can be governed, and for tenants running large numbers of managed environments, that precision is the difference between a policy set someone can actually audit and one that quietly drifts for eighteen months until an admin loses an afternoon tracing it. We’ve walked several clients through exactly this audit-first sequencing this year, and the pattern holds regardless of tenant size: know what you’re moving before you touch the switch.


#AdvancedConnectorPolicies #PowerPlatformGovernance #DataLossPrevention #MCPGovernance #ConnectorSecurity #EnterpriseAI

The Power Pages Security Model Is Changing. Your Table Permissions Still Need an Audit.

IT security professional reviewing an abstract portal permissions and access-control dashboard on a widescreen monitor

A CIO at a mid-size insurer found out about the problem during a routine vendor risk review, not from an internal alert. A claims-intake portal built two years earlier by a business analyst on the operations team, using Power Pages because it was faster than waiting for a developer sprint, had an Anonymous Users role configured with Global Access read permission on a table that included policyholder contact information. Nobody had touched the site’s permissions since launch. Nobody on the security team had reviewed it either, because it had never appeared on a list of applications anyone was tracking. That is the quiet risk of low-code external portals: they get built quickly, they work, and they slip out of the governance perimeter that would normally catch a misconfiguration like this one. It is also the backdrop against which every CIO should be reading Microsoft’s current overhaul of the Power Pages security model, because the two changes underway solve different halves of that same problem.

This is not a hypothetical. In late 2024, researchers at AppOmni disclosed that a large number of Power Pages sites across industries, including a UK National Health Service contractor, were exposing sensitive data because of exactly this pattern: table permissions granted at Global Access to the Anonymous Users or Authenticated Users role, on sites where self-registration meant “authenticated” effectively meant “anyone who signed up.” One case alone reportedly exposed contact information for more than a million people. Microsoft’s own documentation on table permissions has warned about this since Power Pages existed under its earlier name, but the setting is easy to get wrong and easy to forget about once a site is live.

Two Different Problems Wearing the Same Name

Microsoft’s response to date has taken two distinct forms, and it is worth CIOs and IT directors being precise about which one solves which problem, because the two get conflated in vendor briefings more often than they should.

The first is a genuine security tool: the Security Scan and Security Hub capability, which reached general availability in the back half of 2025. It scans a site’s configuration and flags the exact patterns AppOmni’s researchers were finding by hand, such as Anonymous or Authenticated roles with unusually broad table access. This is the tool that actually catches the problem described above, and if your organization has Power Pages sites in production and has not run this scan against every one of them, that is the first governance action to take this quarter, independent of anything else in this article.

Abstract close-up of a laptop screen showing a glowing network authorization diagram with role and permission nodes

The second is architectural, and it is easy to mistake for a security fix when it is really a plumbing change. Power Pages has always run two separate authorization systems side by side: Web Roles, which govern what a portal visitor can see and do on the site itself, and Dataverse Security Roles, which govern access to the underlying data. They were related but not unified, which meant a portal’s activity in Dataverse was historically attributed to a shared application user rather than the individual who was actually signed in, and administrators had to document, reason about, and troubleshoot two parallel permission models for the same site. Starting with a preview that shipped July 8, 2026 and targeted for general availability in November 2026, Microsoft is merging the two: each Power Pages user is now represented as both a Dataverse Contact and a Dataverse System User, and each Web Role maps directly to a corresponding Security Role. When a portal visitor calls Dataverse, the request now carries that visitor’s own identity rather than a generic service account.

What Changes in the Power Pages Security Model, and What Doesn’t

For a CIO evaluating whether this matters, the honest answer is that it is a governance quality-of-life improvement, not a vulnerability patch. The practical benefits are real but specific. Audit trails improve meaningfully, because actions taken through a portal now show up in Dataverse tied to the actual visitor rather than a shared identity, which matters for any organization that has to answer a compliance question like “who accessed this record and when.” Administrative overhead drops somewhat, because a security team no longer has to maintain a mental model of two loosely coupled permission systems and explain the seams between them to auditors or new hires. And because Microsoft describes this as a structural consolidation rather than a breaking change, existing sites are not expected to require a manual permissions migration when the rollout reaches them.

What it does not do is retroactively fix an Anonymous role that already has Global Access to a sensitive table, add column-level masking to a site that never configured it, or catch a wildcard entry in a site’s Web API field allowlist. Those are governance decisions, made by whoever configured table permissions when the site was built, and they persist through the unification exactly as they were. A cleaner, more auditable authorization backbone makes it easier to see a bad permission grant once someone goes looking for it. It does not go looking on its own.

What This Means for the Portal Sitting in Your Environment Right Now

If your organization has any Power Pages sites in production, three actions are worth taking before the November GA date, not because the unification itself is risky, but because it is a natural forcing function to finally do the review that should have happened at launch.

Start with an inventory question that is more often skipped than answered: does IT actually have a current list of every Power Pages site running in the tenant, who built it, and what data it touches? Citizen-developer tools succeed precisely because they let business teams build without waiting on IT, which also means those teams do not always think to tell IT what they built. A Power Platform Center of Excellence setup, or even a simple quarterly export from the admin center, closes this gap cheaply.

From there, run the Security Scan against every site on that list and treat any Global Access finding on the Anonymous or Authenticated role as a same-week fix, not a backlog item. Pair that with a manual check the automated scan will not catch on its own: whether column-level security profiles are configured on any table that includes personally identifiable information, since AppOmni’s testing found this control essentially unused across every site they reviewed, scanned or not.

Finally, treat the unification’s traceability improvement as an opportunity rather than a compliance checkbox. Once portal actions in Dataverse are attributed to individual users instead of a shared application identity, that data becomes genuinely useful for security operations and for internal audit, but only if someone owns pulling and reviewing it. Assign that ownership now, while the change is still new, rather than assuming a dashboard will surface it automatically.

We have run this exact audit sequence, security scan first, then a manual table-permission and column-security review, for several clients ahead of their own Power Pages authorization changes this year, and the pattern holds every time: the sites that fail are the ones nobody had looked at since the day they launched. A consolidated security model makes that oversight easier to catch. It does not make it disappear on its own, and the organizations that treat the two as the same thing are the ones that will still be explaining an exposure to their board next year.


#PowerPages #PowerPlatformGovernance #DataverseSecurity #CitizenDevelopment #DataProtection #DigitalTransformation

Standard vs Custom Dataverse Tables: The Schema Decision That Compounds

Solution architect reviewing an entity-relationship diagram of Dataverse tables on a wall-mounted monitor in a modern office

A solution architect reviewing a Dataverse environment for a mid-market industrial services client recently found three separate custom tables, each carrying a different prefix from three different implementation phases, all describing the same thing: a physical site where equipment lived. One had been built by an internal power user modeling “Locations.” Another arrived bundled with an asset management add-on that already shipped a standard table for exactly this purpose. A third was created eighteen months later by a consulting partner who never checked whether either of the first two existed. None of the three synced with each other. Field technicians updated one, finance reported from another, and a Copilot Studio agent built the following year queried a fourth table that didn’t even have the data anyone actually needed.

This is not an unusual story. It is close to the default outcome when the standard vs custom Dataverse tables decision gets made under sprint pressure by whoever is in the room that week, without anyone asking a simple question first: does a standard table already do this?

Solution architect reviewing an entity-relationship diagram of Dataverse tables on a wall-mounted monitor in a modern office

Why the standard vs custom Dataverse tables decision is easy to get wrong

Dataverse ships with hundreds of standard tables (Account, Contact, and Case are the obvious ones, but plenty of others arrive silently through installed solutions like Asset Management, Project Operations, or Customer Service) built on the Common Data Model, Microsoft’s shared schema for representing common business concepts consistently across apps. These tables carry no prefix. A custom table, by contrast, always carries one, whether that’s a publisher prefix like cra_ or a legacy new_. That naming convention is the fastest way to tell which category a table belongs to, but it only helps if someone actually looks.

The reason teams skip that check is rarely laziness. It is usually that building a new custom table feels faster and safer than researching whether a standard one already covers the need, especially early in a project when the backlog is long and the standard table’s full column list and relationship graph aren’t obvious from a quick glance at the maker portal. The problem is that this shortcut doesn’t cost you anything visible in week one. It costs you eighteen months later, when a Fabric Link migration, a cross-application integration between Finance and Operations and Customer Engagement, or a Copilot Studio agent expects the canonical CDM entity and instead finds three partial, disconnected substitutes.

What actually distinguishes standard, custom, and virtual tables

The decision isn’t really binary. There are three categories worth holding in mind, and each answers a different question about who owns the data’s lifecycle.

Standard tables are the right choice when Dataverse itself is the authoritative source for that data and the concept maps to something Microsoft has already modeled: a contact, an account, a case, a work order. Even when a standard table doesn’t fit perfectly out of the box, most standard tables are customizable, meaning you can add columns, choices, and relationships to extend them without forking the concept into a parallel structure. Extending a standard table keeps every existing app, flow, security role, and future Copilot agent that already understands that entity working correctly, because they’re still querying the same canonical table, just with a few more fields on it.

Custom tables earn their place when the data genuinely doesn’t correspond to anything in the Common Data Model and is specific to how your organization actually operates: an internal certification tracking table, a custom approval matrix, something with no reasonable standard analog. The mistake isn’t creating custom tables. It’s creating one before checking whether the concept already has a home.

Virtual tables solve a different problem entirely: they matter when an external system, not Dataverse, remains the true owner of a record’s lifecycle. A virtual table stores only metadata in Dataverse and queries the external source (an ERP system, a warehouse management platform, a legacy line-of-business database) live, through a data provider. This matters more than it sounds like it should, because the alternative, replicating that external data into a standard or custom Dataverse table on a schedule, introduces a staleness window that can turn into a real operational failure. If a warehouse system shows zero units on hand but the last Dataverse sync ran six hours ago and still shows ten, a sales rep can quote stock that doesn’t exist, and the order gets canceled after the customer has already been told it’s on the way. Virtual tables avoid that gap by not caching the data at all, at the cost of depending entirely on the external system’s availability and performance for every query.

Close-up of a laptop screen showing an abstract database table relationship diagram on a desk

The decision doesn’t stop at the table level

Getting the table category right is only the first layer of the structure question. Once you’ve decided a standard table is the right home for a concept, the choice columns and relationships you add to extend it are where a lot of the same discipline quietly gets abandoned. A choice column added to the standard Case table to capture an industry-specific status, for instance, is a reasonable extension. A parallel custom table built solely to hold a lookup list of those same statuses, connected back to Case through a one-to-many relationship that duplicates logic the choice column could have handled directly, is the same mistake as the duplicate-table problem, just one level down. Relationships matter here too: a standard table’s existing relationships to Account, Contact, or Activity records represent years of Microsoft’s own modeling work and every prebuilt view, form, and security role built around them. Recreating an equivalent relationship structure on a new custom table means none of that inherited tooling applies, and every new integration has to be taught the relationship from scratch. The pattern to watch for is simple: if you’re building a new table or relationship whose only real justification is that it mirrors something a standard table’s fields or connections already do, that’s usually a sign to extend the standard structure instead of building a parallel one next to it.

Where this decision shows up again at the platform level

Microsoft’s own tooling has started reflecting how much this decision matters beyond a single app. Guided table selection for Dataverse-to-Fabric sync, which reached general availability in March 2026, now lets administrators choose which tables get synced to Microsoft Fabric before any data movement happens, rather than syncing everything by default and cleaning up storage and compute costs after the fact. That capability is far more useful, and far cheaper to operate, when the tables being selected are standard, CDM-aligned entities that Fabric, Copilot, and cross-application processes already expect, instead of a scattered set of custom tables that each need to be individually understood, mapped, and maintained by whoever inherits the environment next.

The same logic applies to Copilot Studio agents built against Dataverse. An agent configured to reason over the standard Account or Case table benefits from every piece of existing metadata, relationship, and security context Microsoft has already built around that entity. An agent pointed at a custom table invented to avoid learning the standard schema starts from nothing, and every future integration against that data has to rediscover the same ground.

A practical check before the next table gets created

Before greenlighting a new custom table, it’s worth spending twenty minutes on three checks that would have caught the industrial services example above. First, search the environment for a standard table whose name or description plausibly matches the concept, since standard tables installed by add-on solutions often don’t surface in a maker’s mental model of “what’s already in this environment” the way tables they built themselves do. Second, if a standard table exists but seems incomplete, check whether it’s marked customizable before assuming it needs to be replaced rather than extended, since most standard tables accept new columns, choices, and relationships without any loss of the functionality that came with them. Third, before replicating any externally-owned data into Dataverse on a schedule, ask explicitly whether the business can tolerate a sync delay, because if the answer is no, a virtual table is very likely the more honest architectural choice, even though it takes more setup effort than a straightforward custom table import.

None of this is exciting work, and it rarely shows up as a line item any client asks for by name. But schema decisions are the one architectural choice in a Dataverse implementation that nobody revisits for years, which is exactly why they deserve more scrutiny at the start than they usually get. Routeget Technologies typically includes a standard-table gap analysis as one of the first steps in any new Dataverse engagement, precisely because the cost of fixing a schema mistake grows every quarter it goes unnoticed, while the cost of catching it early is measured in a single afternoon of research.


#DataverseArchitecture #CommonDataModel #PowerPlatformGovernance #DataverseSchema #FabricLink #EnterpriseDataStrategy