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

Business Central’s New Shopify Tax Matching Agent: What Confidence Levels Actually Tell You

Finance operations analyst reviewing a multi-state tax jurisdiction dashboard on a monitor

An integration consultant working a Shopify-to-Business-Central rollout will recognize this scenario immediately: an order comes through with sales tax already calculated at checkout, the sales order posts into Business Central, and three weeks later finance finds a jurisdiction mismatch during month-end reconciliation. Nobody did anything wrong. Shopify’s tax engine and Business Central’s tax engine simply disagreed about which jurisdiction, and which rate, applied to that ship-to address, and the native connector had no mechanism to catch that disagreement before posting. With Business Central 2026 release wave 2 (update 29.0), that changes. A new capability called the Tax Matching Agent enters public preview this month, with general availability set for October 2026 alongside the rest of update 29.0, giving technical teams a review checkpoint that has been missing from this integration since Microsoft first shipped it.

This piece looks at what the Tax Matching Agent actually reviews, what its confidence levels and rate differences mean in practice, and how it fits inside a broader set of Shopify connector changes landing in the same release that push the connector well past its original scope as a simple order-sync tool.

Why tax jurisdiction matching needed its own review step

Shopify calculates sales tax at checkout using its own nexus configuration and its own read of the customer’s shipping address. Business Central, when it creates the corresponding sales document, applies its own tax area and jurisdiction logic against that same address, through a separate calculation path, whether that path runs through Business Central’s built-in tax engine or a connected third-party service. The two were never designed to reconcile automatically. Most orders land on the same answer, since most addresses map cleanly to one unambiguous jurisdiction. The trouble shows up at the edges: marketplace facilitator states with their own filing rules, origin-versus-destination sourcing differences, home-rule jurisdictions layering municipal tax on top of state tax, and ship-to addresses that sit near a jurisdiction boundary. With no reconciliation step, those edge cases post silently and surface only when someone downstream, usually in accounting, notices the numbers don’t tie out.

That silent failure mode is really the problem the Tax Matching Agent solves. It isn’t that either system’s tax logic is wrong in some general sense. It’s that nobody was checking whether the two agreed, order by order, until now.

What the Tax Matching Agent actually does

Microsoft’s own description of the feature, as documented in the update 29.0 release notes, is precise about its scope: it lets a reviewer check suggested tax jurisdictions, confidence levels, and rate differences on a new Tax Match Review page before the sales document processes with sales tax. That phrasing matters. This is a pre-posting gate, not a background reconciliation job that fires after the fact and generates an exception report nobody reads until quarter close.

The design follows a pattern Business Central has already established with its other Copilot-based agents. The Payables Agent autonomously processes incoming vendor invoices and matches them to purchase orders, but it proposes posting accounts and flags routing exceptions for a human to resolve rather than posting blind. The Sales Order Agent handles incoming customer email requests and drafts a quote, but a person still reviews and sends it before anything commits. The Tax Matching Agent fits the same model: it does the comparison automatically, but the decision to accept a jurisdiction match, or override it, stays with the person reviewing the Tax Match Review page.

Confidence level and rate difference are the two pieces of information that page is built around, and they answer different questions. Confidence level reflects how closely the agent’s own jurisdiction assignment logic agrees with what Shopify calculated for that order, given the same ship-to and item data. Rate difference is the concrete dollar or percentage delta between the two calculations. A low confidence score with a near-zero rate difference is a very different situation from a high confidence score sitting next to a meaningful rate gap, and teams rolling this out should build their review workflow around that distinction rather than treating confidence level as a single pass or fail signal.

Part of a larger connector overhaul, not an isolated feature

The Tax Matching Agent didn’t ship alone. Update 29.0 adds four other Shopify connector capabilities in the same release, and understanding them together explains why the tax review step arrived when it did. Business Central now supports managing Shopify B2B companies, catalogs, and pricing directly, including mapping company tax identifiers and controlling price synchronization for whatever B2B capabilities a merchant’s Shopify plan includes. It adds handling for edited and exchanged Shopify orders, so changes and refunds on the Shopify side stay aligned with the sales documents already created in Business Central instead of drifting out of sync. It gives administrators explicit control over sales document creation, through Shopify Shop Card settings for order numbering and return processing, plus a contact review step before a sales document is created. And it adds tariff number and country-or-region-of-origin synchronization, through an HS Code and Country of Origin toggle on that same Shop Card, feeding into product synchronization tasks.

Abstract illustration of data flowing from an online storefront to an enterprise system through a validation checkpoint

Read alone, those four changes look like incremental connector maintenance. Read together with the Tax Matching Agent, they describe a connector being pushed past simple direct-to-consumer order capture and into territory that used to need a specialized middleware layer or a heavier custom build: B2B wholesale pricing, cross-border trade documentation, and multi-jurisdiction tax exposure. Each of those areas raises the stakes on getting tax right, which is presumably why the review agent landed in the same wave rather than as a standalone update later.

What technical teams should actually do with this

The preview window is worth using deliberately rather than skipping straight to general availability. Before update 29.0 reaches GA in October, teams running or planning a Shopify connector implementation should pull a sample of historical orders from exactly the jurisdictions known to be difficult: any home-rule state with meaningful order volume, ship-to addresses near a county or municipal boundary, and any state where marketplace facilitator rules changed how Shopify itself handles the calculation. Running those through the Tax Match Review page in preview, even manually, will say more about how the agent’s confidence scoring behaves than the release notes alone can.

It’s also worth being explicit about what this feature does not replace. If the organization already relies on a third-party tax determination engine, the Tax Matching Agent does not remove the need for that engine’s own jurisdiction and rate logic to be correctly configured. It adds a checkpoint between Shopify’s calculation and Business Central’s posting step; it does not become the tax engine itself. Treating it as a substitute for properly maintained tax setup, rather than a safeguard on top of it, is the surest way a team ends up disappointed after rollout.

The review process itself needs a threshold, not a habit of clicking through. A team that reviews every flagged order with equal scrutiny will either burn out and start rubber-stamping everything, defeating the point of the agent, or grind order processing to a crawl. A more workable approach sets a materiality threshold on rate difference, so small variances route to whoever normally processes sales orders, while anything above the threshold, or a persistently low confidence score from a specific jurisdiction, escalates to a tax specialist who can check whether the underlying nexus or tax area configuration needs correcting, rather than approving the same exception every time it appears.

One coordination point matters more than it might seem at first. Shopify’s tax and nexus settings are frequently owned by the e-commerce or marketing team, not finance or the ERP administrator, and a meaningful share of the mismatches this agent surfaces will likely trace back to Shopify-side configuration drift rather than anything wrong on the Business Central side. A feedback loop that gets a pattern of flags on the Tax Match Review page back to whoever manages the Shopify store’s tax settings, not just to the person clicking approve, is what turns this from a reporting tool into an actual fix.

The takeaway

The Tax Matching Agent doesn’t make the underlying tension between two independently calculated tax engines disappear, and Microsoft’s own preview disclaimer is a fair reminder that the exact behavior at GA could still shift before October. What it does is take a failure mode that used to stay invisible until reconciliation, or until an auditor asked an uncomfortable question, and put it in front of a person before the document posts. That visibility is usually worth more than automation would have been. The pattern holds across other e-commerce-to-ERP engagements we’ve worked: the tax gap was rarely a defect in either system so much as an unmanaged handoff between two logics that never talked to each other. The handoff finally has a checkpoint, and a technical team that uses the preview window to learn how it behaves in its own jurisdictions will be in a far better position than one that waits for GA and finds out the hard way.

#BusinessCentral #ShopifyIntegration #SalesTaxCompliance #ERPGovernance #DynamicsFinanceOps #EcommerceERP

Embedding Copilot Studio Agents in Power Pages: Why Authentication Comes First

A solution architect reviewing a web portal authentication architecture diagram with a chat interface panel on a monitor in a modern office

A solution architect building an external vendor portal in Power Pages gets asked, midway through the project, to add “a chat assistant that can actually answer supplier questions using our own data.” The instinct is to treat this as a UI task: drop in a chat component, point it at Copilot Studio, ship it by Friday. That instinct is the wrong one, and the mistake rarely surfaces on day one. It shows up three weeks later, when the agent works fine for logged-in partners but loops anonymous visitors through a login prompt they were never supposed to see, or when someone in security asks who approved the delegated permissions an agent is now holding on behalf of every anonymous site visitor. The single decision made when adding an agent to a Power Pages site, specifically which authentication model it runs under, quietly determines how it behaves for anonymous users, how much session state it shares with the rest of the portal, and how much rework is waiting the first time that same agent gets published to Teams or Microsoft 365 Copilot alongside the portal. Embedding Copilot Studio agents in Power Pages got considerably more capable in March 2026, and the expanded capability came with a wider set of ways to get the underlying architecture wrong.

A solution architect reviewing a web portal authentication architecture diagram with a chat interface panel on a monitor in a modern office

The Mechanics of Embedding Copilot Studio Agents

Power Pages has offered some form of Copilot-powered chat for a while, but the March 2026 updates changed what that actually means. Microsoft’s own Power Platform blog describes two related capabilities: an Agent API that lets a site’s own custom code build a tailored chat experience against a Copilot Studio agent rather than accepting the default widget, and expanded support for embedding any Copilot Studio agent, using any authentication type the platform supports, directly into a site through the setup workspace. That second piece matters more than it sounds. Previously, a site’s chat experience was tied fairly closely to a narrow generative-answers configuration. Now a maker can either let Power Pages provision a default site agent automatically, or attach a custom agent that was built and tuned independently in Copilot Studio, complete with its own topics, connectors, and orchestration logic.

The setup workflow itself is short. From Power Pages’ setup workspace, under AI Assistance, a maker toggles Site agent on and a generative-answers agent gets created automatically, or selects Add agent to bring in an existing custom one. Either way, the agent then needs web roles assigned before it becomes visible to any site visitor, the same mechanism Power Pages already uses to gate pages and forms. Multiple agents can coexist on one site, each scoped to a different role: a public FAQ agent open to anonymous traffic, say, alongside a case-lookup agent restricted to authenticated partner accounts. Before any of this works, a tenant admin has to enable the “Publish Copilots with AI features” setting in the Power Platform admin center, and the environment’s HTTP connector can’t be blocked, since the agent relies on HTTP nodes to communicate with the site.

The Authentication Fork That Shapes Everything Downstream

Here is where the real architectural decision sits. A default site agent, the one Power Pages provisions automatically, runs on generic OAuth 2 authentication with token pass-through by default. Practically, that means it inherits whatever identity providers the site already has configured, works for anonymous visitors without additional setup, and can tailor its answers based on a visitor’s web role with no extra configuration required. For a straightforward FAQ or knowledge-lookup agent, this is genuinely the easier path, and it is the one most teams will land on without thinking hard about it.

A custom agent added from Copilot Studio, on the other hand, can use any authentication type Copilot Studio itself supports, including direct Microsoft Entra ID authentication rather than the site’s own identity provider. That flexibility exists because some agents need to do more than answer questions from a knowledge source; a topic might need to call back into Dataverse, an external API, or another Microsoft 365 service using a token that carries the visitor’s own delegated permissions. Microsoft’s guidance frames this as a choice between an “Authenticate with Microsoft” option, simple to configure but without token access for topics, and an “Authenticate manually” path that enables token pass-through at the cost of setting up the OAuth registration and scopes correctly.

This is also the point where community reports, appropriately treated as anecdotal rather than confirmed platform behavior, start to matter for planning purposes. A recurring complaint in practitioner discussions is repeated login prompts appearing when a site’s own session and the agent’s authentication flow diverge, often traced back to a token exchange configuration that assumes a session the agent can’t actually see. It is a testable problem, not an unfixable one, but it is the kind of thing that is far cheaper to catch in Copilot Studio’s own testing pane, which now supports validating both the conversation and the authentication flow together, than to discover after a portal has gone live for external users.

Abstract illustration of a glowing padlock merging with a chat bubble and network nodes, representing secure AI agent authentication

Governance Multiplies Across Channels

The authentication decision doesn’t stay contained to Power Pages for long. An agent built once in Copilot Studio is frequently published to more than one surface: the portal, a Teams channel, possibly the Microsoft 365 Copilot app as well. Each channel can carry a different authentication context, which means a topic’s logic that checks for a delegated token, something like a User.AccessToken value, may find it present in one channel and absent in another. A topic written and tested only against the Power Pages experience can behave inconsistently the moment the same agent gets reused somewhere else, and that inconsistency tends to surface as a support ticket rather than a caught bug.

Practically, this argues for treating an embedded agent as a governed asset from the moment it is scoped to more than one channel, not as a Power Pages feature that happens to also work elsewhere. That means a named owner spanning the Copilot Studio author, the Power Pages maker, whoever administers identity for the tenant, and security, rather than assuming the person who built the topic also understands every channel’s authentication quirks. It also means treating the security surface honestly: an agent with broad delegated scopes, reachable from an anonymous-facing portal, is a more attractive target for OAuth consent-phishing style attacks than an internal-only agent would be, and the mitigations worth reviewing (narrower scopes, existing DLP policies, and in higher-sensitivity cases, a backend token-brokering pattern instead of direct client-side pass-through) are worth deciding on before launch, not after an incident review.

What to Confirm Before You Flip the Switch

A few items are worth confirming explicitly rather than assuming. First, decide the authentication model on purpose: the default token pass-through is fine for a lookup-and-answer agent, but anything calling back into Dataverse or another system with delegated permissions needs the manual path, planned for from the start rather than retrofitted. Second, map web roles to agents before enabling anything, since an agent provisioned without a clear role assignment can end up more broadly visible than intended. Third, use Copilot Studio’s own testing capability to validate the authentication flow itself, not just conversation quality, since that is now possible in one place rather than requiring a separate round of manual portal testing. Fourth, budget for consumption: agents provisioned through Power Pages start in a trial period and convert to capacity-based Copilot Studio billing once that period ends, drawing from the same quota pool used by every other Copilot Studio agent in the tenant, so a busy public-facing agent can compete with internal ones for capacity if nobody planned for it.

None of this makes embedding an agent in a Power Pages site a bad idea. It makes it an architecture decision rather than a component you drop onto a page, which is really the same lesson every other Power Pages capability with a security dimension has already taught: the web role model, the table permission model, and now the agent authentication model all reward being decided deliberately in week one. At Routeget, the Power Pages engagements that add agent-powered assistance now start with a short authentication and governance workshop before a single topic gets built, precisely because that conversation is inexpensive early and considerably less so after a portal is already live for external users.

#PowerPages #CopilotStudio #PowerPlatform #AgentAuthentication #PortalGovernance #EnterpriseAI

Power Platform License Enforcement Has a Deadline: February 2027

IT director and finance leader reviewing a software licensing compliance dashboard together in an office

A Power Platform administrator at a mid-size manufacturer got an odd notice in her Microsoft 365 message center in March. It referenced managed environments, a governance feature she associated with premium licensing decisions her CIO had deliberately deferred two budget cycles in a row. She assumed it was routine noise and archived it. Six months later, the same governance feature had been switched on for a dozen production environments without a single approval meeting, because those environments happened to be deployment targets in the organization’s new Power Platform pipelines setup. Nobody had connected the dots between an ALM modernization project and a licensing enforcement clock that started ticking the moment it went live.

That disconnect is becoming common, and it points to a real Power Platform license enforcement deadline that CIOs and IT directors should be treating as a budget line item rather than a footnote in an admin center notification. Microsoft has been quietly retiring the ALM Accelerator for Power Platform, the free, GitHub-based reference implementation many organizations used to bolt source control and deployment automation onto Azure DevOps. In its place, Microsoft is steering everyone toward Pipelines, the native, in-product ALM experience built directly into the Power Platform admin center. The pipelines feature itself is a genuine improvement for most organizations. The licensing mechanics it triggers are the part that deserves scrutiny before anyone signs off on the migration.

Why the ALM Accelerator Is Going Away

The ALM Accelerator was never meant to be permanent. Microsoft built it as a canvas app and Azure DevOps extension pairing, a reference pattern for makers who wanted Git-backed source control and staged deployments without hiring a professional DevOps team. Microsoft’s own documentation now marks it deprecated: no new features, and issues raised against it are no longer reviewed or fixed. The stated successor is Pipelines, described in Microsoft’s guidance as the strategic, in-product experience for maker-initiated application lifecycle management, extensible into Azure DevOps or GitHub when a team needs deeper customization.

For a lot of teams, that is a reasonable trade. Pipelines can be configured in minutes rather than the days or weeks a hand-built Azure DevOps release pipeline typically takes, and it comes with pre-validation, staged approvals, and automatic solution backups out of the box. The tradeoff is that Pipelines requires its non-host target environments, meaning the QA and production environments a solution deploys into, to be managed environments. Development environments are exempt, and the pipeline host itself does not have to be managed, but everything downstream of it does.

IT director and finance leader reviewing a software licensing compliance dashboard together in an office

The Auto-Enablement Nobody Voted On

Here is where the administrator’s ignored notice becomes relevant. Microsoft’s documentation states plainly that starting in February 2026, it began enabling managed environments automatically for any pipeline target environment that was not already configured that way. Tenant admins can opt into a setting under Deployments, Settings in the Power Platform admin center that converts pipeline targets to managed environments proactively, and Microsoft recommends doing so. But the underlying enforcement is not contingent on that opt-in. If a solution is deployed through a pipeline into an unmanaged production environment, Microsoft’s rollout will convert that environment regardless of whether an admin ever flipped the setting.

That matters because managed environments are not a purely technical governance toggle. They carry a licensing dimension that most conversations about ALM modernization skip entirely.

The Licensing Dimension Most ALM Conversations Skip

Managed environments themselves do not cost extra on top of the right license. They come bundled as an entitlement with standalone Power Apps Premium, Power Automate Premium, Copilot Studio, Power Pages, and most Dynamics 365 licenses, along with pay-as-you-go meters for per-app and Copilot Studio consumption. That sounds harmless until you account for how many production apps in a typical enterprise are actually running on seeded or included rights rather than a standalone license: a Power Apps use right bundled into an Office 365 plan, or Power Automate capability included with a Dynamics 365 Pro license and scoped only to that application’s context. Those included rights were never built to satisfy managed environment licensing requirements on their own, and Microsoft’s own FAQ language on the topic notes that Power Apps or Power Automate capability tied to a Dynamics 365 Pro license is meant to be used only within that licensed application, not as a general-purpose citizen development platform.

Managed environments carry an autoclaim policy that automatically assigns the correct license to a user who accesses an app there, provided the tenant has license capacity to draw from. Autoclaim solves the paperwork problem of manually assigning licenses one user at a time. It does not solve the budget problem of simply not owning enough qualifying licenses to autoclaim against, and it does nothing for a user whose only access to Power Apps or Power Automate comes through a seeded right that was never designed to extend into a managed, governed production environment.

Abstract illustration of a countdown clock merging with a network of cloud environment nodes, some locked and some unlocked

The Power Platform License Enforcement Timeline You Are Already Inside

This is not a distant, hypothetical deadline. Microsoft’s published timeline shows administrative notifications through the Microsoft 365 message center and Power Platform admin center beginning in March 2026. In-app notifications aimed directly at end users without an appropriate license started in June 2026, following a staged escalation: an informational message on day one, a warning after seven days, and an error state after fifteen, each urging the user to request a license from an admin. The hard stop lands in February 2027: users who still lack an appropriate license at that point are blocked from opening the app entirely, shown a standard message telling them they need a Power Apps license to use it. Apps are not deleted and access resumes automatically once a qualifying license is detected, but for that window, whatever workflow depended on that app simply stops working for that user.

Given today’s date, that means the notification phase is already well underway inside most tenants that run pipelines against production environments, and the enforcement date is now closer than most annual license renewal cycles.

What This Means for the Business Case

None of this is a reason to avoid Pipelines or to keep patching together an already-deprecated ALM Accelerator deployment. The practical response is to treat the license audit as part of the ALM modernization project plan rather than as an afterthought that surfaces after go-live. That means pulling a current list of every user who accesses production apps sitting in, or scheduled to sit in, a pipeline-managed environment, and checking each one against a standalone qualifying license rather than assuming a Microsoft 365 or Dynamics 365 seat covers it. It means asking whether apps currently running on included, scoped rights actually need to move to standalone Premium licensing, get rearchitected to stay within their original licensed application’s context, or get retired if nobody can justify the cost. And it means giving finance and procurement enough lead time to true up license counts well before February 2027, rather than discovering the gap when a plant floor supervisor gets locked out of a production app and escalates it as an outage.

Organizations that have gone through this kind of ALM transition tend to find the technical migration to Pipelines is the easy part. The harder, more valuable work is the license and governance audit that should have accompanied it from the start, which is usually where firms like Routeget Technologies get pulled into these engagements: less to configure a pipeline, more to make sure the environments behind it do not quietly turn into a compliance problem eleven months later.

#PowerPlatformPipelines #ManagedEnvironments #ALMGovernance #PowerPlatformLicensing #LicenseComplianceAudit #EnterpriseGovernance

Business Central CAMT.053 Migration: What Actually Needs to Change

Finance professional reviewing bank reconciliation data on a desktop monitor in a modern office

A finance systems administrator at a mid-size manufacturer got an email last month from the company’s German house bank. Starting in the first week of the new quarter, the daily MT940 statement feed that had fed Business Central’s bank reconciliation for six years would stop. In its place: a CAMT.053 XML file, delivered on a different schedule, with a different structure. The email asked, almost as an afterthought, whether the ERP would “just work” with the new format. It was not a rhetorical question the bank expected an answer to. It was a notice.

That conversation is playing out across Business Central shops right now, and it is worth understanding why the Business Central CAMT.053 migration is arriving in 2026 specifically, what Business Central’s native tooling actually does with a CAMT.053 file, and where that tooling quietly runs out before a consultant finds out the hard way during a month-end close.

Finance professional reviewing bank reconciliation data on a desktop monitor in a modern office

Why the Business Central CAMT.053 Migration Is Landing Now

The ISO 20022 migration has two distinct halves, and they are not moving on the same clock. The first half concluded in November 2025, when SWIFT ended coexistence for cross-border payment instructions. MT103, MT202, and the rest of the legacy payment message types stopped flowing in their original form; everything now moves as ISO 20022 MX, primarily pacs.008 and pacs.009. Institutions that kept sending legacy MT payment formats after that date found them auto-converted by SWIFT, with additional charges applied starting January 1, 2026.

The second half, covering statement and reporting formats rather than payment instructions, was deliberately left on a slower and less coordinated timeline. MT940 and MT950 (account statements), MT900 and MT910 (debit and credit notifications), and MT941 and MT942 (intraday reporting) are being replaced by camt.053, camt.054, and camt.052 respectively, but SWIFT is not converting MT9xx traffic to camt format automatically. Each bank negotiates its own cutover, account by account, on whatever internal schedule its own core banking migration allows. That is precisely why one Business Central customer converted a year ago without much drama, another is getting the notice this quarter, and a third will not hear anything until 2027. There is no single migration date to plan around. There are dozens of them, one per banking relationship, arriving on nobody’s schedule but the bank’s.

The Business Central Side of the CAMT.053 Migration

Business Central handles SEPA CAMT import through a Data Exchange Definition, a mapping layer that translates XML element paths in the bank’s file into fields across three tables: the General Journal table, the Bank Acc. Reconciliation header, and the Bank Acc. Reconciliation Line table. The mapping itself is fairly mechanical once you see it laid out. The transaction amount and its sign come from Stmt/Ntry/Amt combined with the credit or debit indicator at Stmt/Ntry/CdtDbtInd, with a configurable negative-sign identifier (typically set so that DBIT entries post as negative). Posting and transaction dates come from Stmt/Ntry/BookgDt, which can arrive as either a plain date or a full timestamp; Business Central accepts both. Payer information for matching comes from Stmt/Ntry/NtryDtls/TxDtls/RltdPties/Dbtr/Nm, and the free-text remittance information that drives most of the automatic matching logic comes from Stmt/Ntry/NtryDtls/TxDtls/RmtInf/Ustrd.

The field that actually determines whether any of this works is easy to miss: Stmt/Ntry/NtryDtls/TxDtls/Refs/EndToEndId. This is the identifier Business Central relies on to treat each line as unique within an open reconciliation. If a bank’s first-generation camt.053 export leaves this element empty, or populates it with a placeholder value repeated across an entire batch, the failure mode is not an import error. The file parses without complaint. What actually happens is worse in a subtler way: lines with a missing identifier get silently dropped, and lines that share a duplicated identifier with something already posted will import but fail automatic matching one by one, with no message pointing back to the cause. A team that has not specifically gone looking for this will spend a reconciliation cycle assuming the new statement format is simply less complete than the old one, when the real problem is a configuration gap that a five-minute look at the raw XML would have caught before go-live.

Abstract visualization of two data streams merging, representing a bank statement format migration

Where the Generic Definition Runs Out

Business Central ships a generic SEPA CAMT data exchange definition, and it is a reasonable starting point, not a finished solution. CAMT.053.001.08 is a schema, not a single fixed file layout, and individual banks populate it with their own dialect: some banks include optional elements Business Central’s default mapping ignores, some omit fields the default mapping expects, and namespace versions drift between institutions even within the same country. In practice, most multinational Business Central deployments end up cloning the generic definition per banking relationship rather than trying to maintain one shared version that quietly breaks every time a new bank is onboarded with slightly different habits.

It also helps to be honest about geographic scope. CAMT adoption is heavily concentrated in the EU and a handful of other markets that have committed to the SEPA-aligned schema. Plenty of banks elsewhere, particularly smaller regional institutions in North America and parts of Asia, are staying on BAI2 or proprietary flat-file formats for the foreseeable future, with no camt.053 timeline at all. A single Business Central tenant with entities in four countries can easily end up running MT940, camt.053, and BAI2 in parallel for years, not as a transitional state but as the normal operating condition. For organizations with a long tail of smaller regional banking relationships, this is where an ISV connector such as AMC Banking 365 Fundamentals earns its licensing cost: it converts against several hundred bank-specific format variants through its own service rather than asking an internal team to build and maintain a bespoke Data Exchange Definition for every regional bank quirk. That trade-off is worth evaluating deliberately, since routing statement data through a third-party conversion service is a data-governance decision as much as a technical one.

A Practical Migration Checklist

The teams that get through a bank-driven format change without a rough reconciliation cycle tend to do a few things in a specific order. They start by inventorying every bank account’s current import format code and confirming the actual cutover date per relationship, since assuming all banking relationships move together is the single most common planning mistake. Before the cutover, they request an actual test camt.053 file from the bank, not a sample pulled from vendor documentation, and run it through the Data Exchange Definition in a sandbox company where a bad mapping does no damage. They open that test file as raw XML and check the EndToEndId population line by line rather than trusting that because a mapping worked for one bank’s camt.053 export, it will behave identically for another bank using the same nominal schema version. Where any deviation shows up, they clone the generic SEPA CAMT definition into a bank-specific version rather than editing the shared default, so a fix for one relationship cannot silently change behavior for every other bank account using the same code. They keep the outgoing MT940 or BAI2 definition active and assigned for as long as the bank is willing to run both feeds in parallel, because a same-day cutover with no fallback window turns any mapping problem into an immediate reconciliation gap. And before retiring the old feed for good, they re-test automatic matching rates against a full month of real transaction volume on the new format, since a quiet drop in match percentage is a far more reliable early warning of a mapping issue than an outright import failure would be.

What Copilot’s Bank Reconciliation Assist Does and Doesn’t Solve Here

Business Central’s Copilot-assisted bank reconciliation feature, currently in preview, is genuinely useful for what it does: it analyzes unmatched transaction descriptions and ledger entries to suggest matches and likely G/L accounts, including scenarios where a single deposit needs to be split across several invoices. It is worth being clear about its boundaries in this specific context, though. It operates entirely downstream of the Data Exchange Definition, on statement lines that have already been successfully parsed into the system. If a mapping problem is dropping or mismatching lines before they ever reach the reconciliation worksheet, no amount of AI-assisted matching afterward will surface or correct that. The feature also performs best when transaction descriptions and G/L account names share a single consistent language, which is worth double-checking specifically during a format changeover, since a bank’s new camt.053 export sometimes reformats descriptive text differently than its old MT940 feed did.

The Deadline Is the Bank’s, Not Yours

None of this is a discretionary upgrade a Business Central team can schedule around a quieter month. It is a mapping and validation project with a deadline set by someone else’s core banking migration, arriving on a per-relationship basis rather than a single company-wide date. The organizations handling it well are the ones treating each bank’s cutover notice as a trigger for testing, not as an announcement to file away until the old feed actually stops. Routeget has walked several clients through exactly this kind of parallel MT940 and camt.053 coexistence during multi-entity rollouts, and the pattern is consistent: the mapping work is small, but only when someone does it before the bank forces the issue rather than after.

#BusinessCentral #CAMT053Migration #BankReconciliation #ISO20022 #DataExchangeDefinitions #ERPIntegrations

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

Dynamics 365 Remote Assist Retirement: What Field Service Leaders Do Next

Field service technician wearing a mixed reality headset inspecting industrial equipment

In a field service budget review this quarter, someone is going to ask why next year’s plan still carries a line item for Dynamics 365 Remote Assist. The uncomfortable answer is that it shouldn’t be there at all. Dynamics 365 Remote Assist retirement, alongside its companion product Dynamics 365 Guides, is now official and set for December 31, 2026, a little over three months from today, and new subscriptions or renewals actually stopped being available back on November 1, 2025. Organizations still running technicians through HoloLens-guided repair procedures, or connecting field crews to remote experts through live AR annotation, now have a hard stop on the calendar and, notably, no Microsoft-branded successor waiting on the other side of it.

This is not a routine feature deprecation buried in a release-wave changelog. It is the full retirement of a product category Microsoft spent the better part of a decade building around HoloLens, and it lands squarely on the Service Modules side of Dynamics 365 Customer Engagement, where field service dispatching and remote guidance have quietly become dependent on mixed reality tooling in a way that budget owners do not always track closely. For CIOs, IT directors, and field service operations leaders, the question is no longer whether to plan for this. It is what to do in the next few months before the apps simply stop functioning.

What Dynamics 365 Remote Assist retirement actually shuts down

It helps to separate the two products Microsoft is retiring, because they solve different problems and their replacement paths diverge. Dynamics 365 Guides is the authoring and playback tool for step-by-step, holographic work instructions: a technician wearing a HoloLens sees floating annotations pinned to the actual equipment in front of them, walking through a procedure without needing to hold a phone, a tablet, or a printed manual. Dynamics 365 Remote Assist is the live collaboration layer, letting a field technician share their point of view over a video call while a remote expert draws arrows, circles, and notes directly onto the technician’s real-world field of vision, and, where it is wired into Field Service, pulls booking and work order context directly into that session.

Both applications, along with their supporting Dataverse solution components, reach end of support on December 31, 2026. After that date, Microsoft has been explicit about what stops: no security updates, no bug fixes, no non-security patches, and no technical support. The apps themselves stop working. The one piece of good news is that underlying data, including authored Guides content, remains in the customer’s Dataverse environment rather than disappearing outright, but the applications used to create, edit, and play back that content go dark. Any organization that has not already exported its Guides library through the PC app should treat that as a near-term task rather than something to revisit closer to the deadline.

Mixed reality headset resting on a desk next to a laptop showing a dashboard

Why there is no like-for-like replacement

The retirement traces back to a decision Microsoft made roughly two years earlier and largely outside the Dynamics 365 product conversation: HoloLens 2 production ended, with the company confirming in February 2025 that no further units would be manufactured and no successor headset was in development. Hardware support for existing HoloLens 2 devices continues somewhat longer, into 2027, but the software layer that made those devices useful inside a Dynamics 365 context is being wound down first. That sequencing matters for planning purposes: an organization could, in theory, still have functioning HoloLens 2 hardware in the field well after the Guides and Remote Assist applications that ran on it have been retired.

What replaces the capability is genuinely unsettled, and that is worth saying plainly rather than papering over with reassurance. Microsoft’s own guidance points toward the spatial annotation feature inside Microsoft Teams mobile as the closest first-party option for live remote-assist-style collaboration, letting a remote expert annotate what a technician on a phone or tablet camera is seeing. It is a reasonable fit for lighter-weight scenarios, a quick second opinion on a mechanical issue or a walkthrough of an unfamiliar panel, but it is not a drop-in substitute for hands-free, HoloLens-based guidance on a complex, multi-step repair where a technician genuinely needs both hands free and instructions anchored to the physical equipment. For that heavier use case, Microsoft is pointing customers toward the mixed reality category of the commercial marketplace rather than offering a first-party alternative, which means evaluating third-party vendors, negotiating new licensing, and in most cases paying for a capability that was previously bundled into an existing Dynamics 365 or HoloLens investment.

What this actually costs, beyond the obvious

The immediate financial exposure is the easy part to catch: procurement should already be auditing Dynamics 365 licensing agreements to make sure nobody is still being billed for Guides or Remote Assist seats that will be worthless in a few months, particularly in larger organizations where mixed reality licensing was bundled into a broader Dynamics 365 or Microsoft 365 agreement and easy to overlook during a routine renewal cycle. That is a straightforward cost-avoidance exercise, and it should happen this quarter regardless of what an organization decides to do about replacement tooling.

The harder cost is the one field service leaders tend to underestimate: re-authoring. Any organization with a meaningful Guides content library, holographic work instructions built up over months or years for specific equipment models, safety procedures, or onboarding sequences, is going to need to rebuild that content on whatever platform replaces it, because the format is not portable in any turnkey sense. A 200-guide library built for HoloLens playback does not simply import into a third-party AR tool or a Teams-based workflow. Depending on how content-heavy the current deployment is, that re-authoring effort can rival or exceed the cost of the original build-out, and it is the piece most likely to get underestimated in a budget conversation that focuses only on licensing fees.

A practical response for the next quarter

The first step, before evaluating any specific replacement, is an honest inventory of who is actually using Guides and Remote Assist today, for what scenarios, and how often. Mixed reality tooling has a well-documented pattern of enthusiastic pilot adoption followed by quiet underuse once the novelty wears off, and some organizations will find that usage has already dwindled to a handful of technicians or a single business unit, in which case the retirement is an opportunity to simply stop paying for a capability that was not delivering proportional value rather than a crisis requiring a like-for-like replacement.

For organizations where usage is genuine and operationally important, the decision splits along the same line the capability itself splits on. Lightweight remote collaboration scenarios, a technician needing a second set of eyes on something unfamiliar, can likely move to Teams mobile’s spatial annotation with minimal disruption and no new procurement cycle. Hands-free, instruction-heavy scenarios tied to specific equipment and repeatable procedures need a dedicated evaluation of marketplace alternatives, budgeted as a genuine new software category rather than a lateral move, with enough lead time to pilot, contract, and re-author content before the December cutoff rather than after it.

Routeget Technologies has been helping clients work through exactly this kind of transition assessment, mapping current Guides and Remote Assist usage against actual field service outcomes before recommending whether a replacement is warranted at all. The retirement itself is not really the hard problem. The hard problem is that most organizations have not looked closely enough at how this capability is actually being used to know what they would be replacing, and that assessment is the work that needs to start now, not in November.

#DynamicsFieldService #RemoteAssistRetirement #MixedReality #FieldServiceOperations #ITAssetLifecycle #Dynamics365CE

Your Dataverse Customer-Managed Key May Have Silently Reverted in January

IT security professional reviewing a data encryption key management dashboard in a modern operations center

A compliance team preparing for a SOC 2 renewal pulls up its Power Platform admin center to confirm what it has told auditors for two years running: that its Dataverse customer-managed key, stored in the organization’s own Azure Key Vault, keeps its data encrypted under keys Microsoft cannot touch without their say. The screen says something different. The environment shows “Microsoft Managed key.” Nobody remembers approving that change, because nobody did. It happened automatically, on a date that passed eight months earlier, and the only trace of it is a single line in the environment’s admin history.

This is not a hypothetical. Microsoft retired its original bring-your-own-key (BYOK) encryption feature for Dataverse on a hard schedule: new production environments could no longer be enrolled in BYOK after June 1, 2025, and any environment still running on BYOK that had not completed migration to the newer customer-managed key (CMK) model by January 6, 2026 reverted automatically to a Microsoft-managed key. Encryption continued without interruption, so nothing broke. That is precisely the problem. An organization can lose the control it has been representing to regulators, customers, and its own board, and the system will not tell anyone unless someone goes looking.

For CIOs and IT Directors who treat encryption key ownership as a checkbox on a compliance questionnaire rather than a control that needs periodic verification, this is worth an afternoon of attention right now.

Why a Dataverse customer-managed key was worth having in the first place

Customer-managed key was never about making Dataverse more secure in a technical sense. Microsoft-managed keys use the same underlying encryption standards either way. What CMK provides is contractual and operational leverage: the ability to revoke Microsoft’s access to the underlying data by disabling a key in Azure Key Vault, independent of any support ticket or service request. For organizations in regulated industries, defense-adjacent supply chains, or jurisdictions with data sovereignty requirements, that revocation capability is often the specific control a customer contract, a government agency, or an internal risk committee asked for by name.

That is also why the BYOK-to-CMK transition matters more than a typical feature deprecation. A lapsed migration does not remove a nice-to-have. It quietly removes the exact control that a Business Associate Agreement, a defense contract, or a data processing addendum may reference. If that control disappeared in January and the organization’s compliance narrative has not been updated since, the gap is not a technical debt item. It is a misrepresentation risk sitting in a vendor security questionnaire that was answered honestly a year ago and has not been true since.

Checking whether this happened to you

The check itself takes minutes. In the Power Platform admin center, under Security, then Data and Privacy, then Customer-managed encryption key, any enterprise policy still listed will show its current status against each enrolled environment. An environment that reverted during the January cutoff will show “Microsoft Managed key” rather than “Encrypted.” The same information is visible at the environment level: open the environment’s history and search for “Update Customer Managed Key,” which will show the reversion event and its timestamp if one occurred.

Organizations that never adopted BYOK or CMK in the first place have nothing to check here, since they were never claiming otherwise. The exposure is specific to organizations that adopted BYOK, told someone about it, and then let the migration window close without follow-through, which is a more common outcome than it should be given how disruptive CMK migrations used to be to plan around.

Compliance officer and IT director reviewing a security audit and cloud governance dashboard in a meeting room

What changed that makes CMK worth reconsidering now

The reason many organizations dragged their feet on migrating from BYOK to CMK in the first place was operational risk, not indifference. Applying a customer-managed key used to mean an environment going fully offline for the duration of encryption, and if a Key Vault permission got revoked by accident, whether through an access review, a policy change, or a departing employee’s role cleanup, the environment locked and stayed locked until Microsoft support intervened. For an IT Director who has lived through that kind of outage once, avoiding a second one is a rational, if costly, choice.

Microsoft’s updates to CMK over the past year address both of those specific failure modes. Core Dataverse services now come back online once the primary encryption pass finishes, with secondary services continuing to encrypt in the background under an “Encrypting – online” status, so the outage window during initial enrollment is shorter than it used to be. More significantly, environment administrators can now restore access themselves once a revoked Key Vault permission is fixed, rather than opening a support case and waiting. That single change removes the scenario that made a lot of security teams nervous about CMK in the first place: an internal mistake in Azure RBAC no longer means the environment stays dark until Microsoft gets involved.

CMK has also expanded into GCC High, giving U.S. government entities and defense contractors the same encryption-key control in a sovereign cloud environment that commercial customers have had, and Azure Key Vault Managed HSM support for Dataverse has moved into preview, which will matter to organizations whose compliance framework specifically calls for hardware security module protection rather than software-protected keys.

Solution architect configuring cloud key vault access controls at a workstation

The coverage gap that still needs to be in the compliance narrative

None of this means CMK covers everything, and any accurate representation to an auditor or a customer needs to say so. Applying a customer-managed key to a Managed Environment encrypts Dataverse data and most of the Dynamics 365 apps built on it, but Power Automate flow data tied to that environment continues to be encrypted with a Microsoft-managed key regardless of the environment’s CMK status. Connector connection settings, environment configuration metadata, and a handful of other categories Microsoft classifies separately are also excluded. A CIO who tells a customer “our Dataverse environment is fully under customer-managed key” is accurate about the data that matters most in nearly every case, but a security questionnaire that asks about encryption coverage across the entire Power Platform estate deserves the more precise answer, not the simplified one.

What this means for planning the next quarter

For organizations that discover a silent reversion, the fix is a re-enrollment, not a support escalation: create or reuse an Azure Key Vault with soft-delete and purge protection enabled, generate or reuse an RSA key, stand up an enterprise policy, and add the environment back in through the admin center, with the expectation that core encryption completes within about four days and the environment stays reachable for most of that window under current behavior. Licensing needs a second look too, since CMK still requires a qualifying Microsoft 365 or Office 365 compliance-tier license (the E5, A5, F5, or G5 compliance and information protection SKUs) on top of the Managed Environments entitlement that comes with standard Power Platform and Dynamics 365 licensing.

For organizations that have been putting off CMK adoption entirely, the calculus has genuinely shifted. The two operational objections that used to show up in every internal debate, extended downtime and support-dependent recovery from an access mistake, have both been addressed directly. What has not changed is the governance discipline CMK requires: separating the person who administers the Key Vault from the person who administers the Power Platform environment, setting expiration alerts on the key well before it lapses, and documenting the enterprise policy and resource IDs somewhere that survives staff turnover. CMK gives an organization real control over its own encryption keys. It also gives that same organization the ability to lock itself out if that control is managed carelessly, and the discipline required to avoid that outcome has not gotten any less important just because the recovery path got shorter.

Routeget Technologies has walked several clients through exactly this kind of CMK re-enrollment after a lapsed migration, and the pattern is consistent: the technical fix is straightforward once someone notices the gap, and the harder part is almost always internal, tracking down who last touched the enterprise policy and confirming what was actually represented to auditors or customers in the meantime. That reconciliation work is worth doing before the next audit cycle asks the question first.

#Dataverse #CustomerManagedKey #EncryptionKeyManagement #DataSovereignty #ComplianceRisk #CloudGovernance