The Power Pages Enhanced Data Model Migration Tool Reached GA. The Four Templates That Couldn’t Move Now Can.

Solution architect reviewing data migration dashboards on a dual-monitor workstation in a modern office

The Migration That Kept Getting Delayed

If you have maintained a Dynamics 365 Customer Self-Service, Partner, Community, or Employee Self-Service portal since before the Power Pages rebrand, you have almost certainly run into this wall: everything Microsoft has shipped for Power Pages application lifecycle management over the last three years, solutions support, Power Platform pipelines, environment variables, faster provisioning, has applied only to sites built on the enhanced data model. Your site, built on the standard data model with its familiar adx_ prefixed tables, has been sitting outside that perimeter the entire time. You could read every announcement, watch every demo, and still not be able to touch any of it, because the migration tooling that was supposed to bring your site along explicitly excluded the four Dynamics 365 portal templates. That changed on September 7, 2026, when Microsoft moved the standard-to-enhanced data model migration utility in the Power Platform CLI to general availability and, for the first time, extended it to Customer Self-Service Portal, Employee Self-Service Portal, Community Portal, and Partner Portal sites.

This is not a small technical footnote. For a lot of organizations running production portals on these templates, it is the first realistic path off a data model that Microsoft has been quietly deprecating in practice, if not in name, since 2023.

What the Standard Data Model Was Actually Costing You

The distinction between the standard and enhanced data models is not cosmetic. On the standard data model, website configuration lives in a set of legacy adx_ entities: adx_webpage, adx_webrole, adx_weblink, and so on. Those tables were never built for the deployment discipline that modern ALM assumes. Configuration changes get made directly against a live environment, promotion between environments means manually reconciling records or wrestling with unmanaged solution exports, and Microsoft has to maintain backward compatibility with a table structure that predates Dataverse solution awareness altogether. The enhanced data model consolidates that configuration into the newer powerpagecomponent table structure, which is solution-aware, supports environment variables, and plugs directly into Power Platform pipelines. Sites on the enhanced data model also provision faster and pick up feature and security updates automatically, rather than waiting on package installs that someone on your team has to remember to schedule.

None of this was news. What was missing, until this month, was a supported way to get an existing site there without rebuilding it from scratch. Microsoft’s own documentation was blunt about the gap as recently as March 2026, stating outright that sites created with the four Dynamics 365 templates could not be migrated and that only new sites on those templates would land on the enhanced data model. If you were running a production Partner Portal from 2021, your only two options were live with the limitation indefinitely or replatform the entire site.

What the Enhanced Data Model Migration Utility Shipped at GA

The migration utility itself is not new. Microsoft first previewed pac powerpages migrate-datamodel back in April 2024, and it worked reasonably well for the templates it supported: starter layouts, application processing, blank page builds, program registration, and scheduling sites. What reached general availability on September 7 is both a maturity milestone and a scope expansion. The scope expansion is the four Dynamics 365 templates finally being added to the supported list, which is the headline for most technical teams reading this. The maturity milestone is three specific capabilities that were not reliable enough to trust in preview: a genuinely useful customization dependency report that tells you what will break before you commit to anything, a status-check command so you are not guessing whether a large migration job is still running or has stalled, and a formal rollback path if validation turns something up after the data has moved.

Running the migration itself still follows the same sequence architects who piloted the preview will recognize. You authenticate against the target environment, generate a customization report scoped to a specific website ID, and read that report closely before doing anything else, since it is the tool telling you exactly which of your customizations depend on tables that will not exist in the same form once you move. From there, you migrate configuration data and, separately, transactional data referencing that configuration, using mode flags that let you split the work rather than attempting a single all-or-nothing pass. A status-check command lets you monitor long-running jobs on sites with meaningful data volume, and only once you are satisfied do you run the command that actually switches the site over to serve from the enhanced data model record. The CLI now requires Power Platform CLI 2.11.2 or later, along with updated Dataverse base portal and Power Pages core packages, so confirm your tooling versions before you start rather than discovering a version mismatch mid-migration.

Close-up of a developer typing CLI migration commands with terminal windows and a data flow diagram in the background

The Five Things That Will Actually Break

The customization report is useful precisely because most Dynamics 365 portal implementations that have been running for several years have accumulated customizations the original template never anticipated, and those are where the real work lives. Five categories come up consistently. Custom columns added directly to the legacy adx_ metadata tables have no equivalent in the enhanced schema, so you will need to stand up a new custom table, add a lookup back to powerpagecomponent, and migrate the data across rather than expecting an automatic mapping. Relationships built between your custom tables and the old adx_ tables need to be recreated against their powerpagecomponent equivalents, which means auditing your solution for every such relationship before you migrate, not after. Liquid code that references entities directly, something like assigning a variable from entities[‘adx_weblinks’], needs to be rewritten to use the corresponding Liquid object instead, since the enhanced data model does not expose those legacy entity names the same way. FetchXML embedded in Liquid templates that queries adx_ entities by name has to be rewritten against powerpagecomponent with a componenttype filter, and getting that filter value wrong is a common source of queries that silently return nothing rather than failing loudly. Finally, any custom plugins or classic workflows registered against the old tables need to be re-registered against their enhanced equivalents, which is easy to forget if that logic was written by a developer who has since moved on and the automation itself has been running quietly in the background for years.

None of these are migration blockers on their own. They are the reason the customization report exists, and the reason this gets treated as a project with a real test phase, not a command run against production on a Friday afternoon.

How to Actually Run This

Start on a full copy of the production environment, not a shared sandbox someone else is also using that week. Run the customization report first and treat it as your scope document: every item it flags becomes a line in your migration plan, and if it flags nothing, that itself is worth double-checking against a manual review of your solution, since undocumented customizations from years back do not always get picked up cleanly. Migrate configuration data and configuration data references as separate, deliberate steps rather than reaching for the combined mode on a first attempt, since separating them gives you a natural checkpoint to validate before moving transactional data. Watch your table sizes going in: the migration processes records in batches of five thousand, so a site with a large volume of case records, form submissions, or forum content tied to configuration should expect the migration job to take real time, and you should plan your maintenance window accordingly rather than assuming it finishes in minutes. Once the migration completes, work through the five customization categories above methodically against your report before you consider the environment production-ready, and only then schedule the actual cutover during a low-traffic window given that end users will be locked out or degraded while the switch happens.

Treat this as a two-track modernization rather than folding it into the separate Bootstrap 5 template migration Microsoft made generally available for these same four templates back in June. One is about the underlying data model and ALM story, the other is about front-end markup and CSS, and combining them multiplies your testing surface for no real benefit. Sequence the data model migration first, stabilize, then take on Bootstrap as its own scoped effort.

Why This Is Worth Prioritizing Now

Every enhanced-data-model-only feature Microsoft has shipped since 2023 stays out of reach until you make this move, and the pace of that list is not slowing down. In our work at Routeget Technologies with legacy Dynamics 365 portal environments, we have consistently seen operational overhead trace back to being stuck on manual package management and unmanaged solution exports, simply because migrating never had a supported path for the specific template a client was running. That excuse is gone now. The work is not trivial, and the five customization categories above are real effort, not boilerplate. But for a portal your organization depends on, closing that ALM gap and getting onto a data model Microsoft is actively investing in is a better use of a sprint than continuing to work around a limitation that no longer needs to exist.

#PowerPages #EnhancedDataModel #PowerPlatformALM #DynamicsPortalMigration #LowCodeGovernance #PowerPlatformCLI

Azure AD B2C’s Retirement Just Reshaped the Power Pages Authentication Provider Decision

IT director reviewing an identity and access management dashboard, representing the Power Pages authentication provider decision

A supply chain director at a mid-market manufacturer recently asked her IT team to stand up a new supplier self-service portal on Power Pages: purchase order visibility, invoice status, a place for vendors to upload compliance documents. Nothing exotic. The kind of project that used to start with a fairly routine question: which identity provider do we wire up for sign-in? For years, the routine answer was Azure AD B2C. It isn’t anymore, and the reason has less to do with Power Pages itself than with a licensing decision Microsoft made about the identity service underneath it.

If your organization is not already an Azure AD B2C customer, you cannot create a new B2C tenant today. That single fact changes the Power Pages authentication provider decision for every external-facing portal currently on a scoping document, and most of the teams building those portals have not caught up to it yet.

IT director reviewing an identity and access management dashboard, representing the Power Pages authentication provider decision

What Actually Changed

Microsoft closed Azure AD B2C to new customers on May 1, 2025. Organizations that already had a B2C tenant on that date can keep using it, keep creating additional tenants, and Microsoft has committed to supporting the product through at least May 2030. Organizations that did not already have a B2C relationship lost the option outright. There was a second, quieter cutoff in between: B2C’s P2 tier, the one with the deeper Conditional Access and Identity Protection integration, was discontinued for all customers, existing and new, on March 15, 2026. Existing tenants moved to P1, which is the tier Power Pages sites have generally run on anyway, so that part of the change was less disruptive than it sounds. The tenant-creation cutoff is the one that actually redraws the map.

Microsoft’s stated replacement is Microsoft Entra External ID, which reached general availability for Power Pages on May 1, 2025 after a public preview that started the previous September. It is a real product, not a rebrand: it gives Power Pages a low-code way to add branded sign-in and registration screens, multi-factor authentication, social identity provider sign-in alongside your own directory, and built-in analytics on who is actually using the portal, all configured from the site’s Identity Providers settings rather than through a separate Azure tenant with a manually registered OpenID Connect application. For a straightforward customer or supplier portal, that setup experience is arguably better than what B2C ever offered.

The Power Pages Authentication Provider Choice, in Practice

Here is where the decision actually splits. If your organization already runs an Azure AD B2C tenant for something else, whether it is an older customer portal, a mobile app, or a partner-facing application, you retain the option to keep building on B2C for new Power Pages sites too, including its deeper customization layer. If you do not have that existing relationship, Entra External ID is not one option among several. It is the only Microsoft-native path forward, because the door to B2C is closed regardless of how well External ID happens to fit your requirements.

That asymmetry matters more than it looks like on the surface. A portal built by an existing B2C shop and a functionally identical portal built by a net-new customer are no longer choosing between comparable tools. One team has the full B2C toolkit available if they need it. The other is working within whatever Entra External ID currently supports, full stop.

The Gap Nobody’s Migration Deck Mentions

What Entra External ID currently supports is where the real planning risk sits. Azure AD B2C’s Identity Experience Framework let architects write custom policies: orchestration logic that could federate authentication out to an external identity provider, including something as specific as a legacy on-premises IdentityServer instance, and then auto-provision a user record in the destination system based on claims that came back from that external IdP. That pattern shows up constantly in supplier and partner portals, where the partner organization already has its own identity system and nobody wants to make external users create yet another password.

Abstract illustration of an aging security key transferring authentication to a new digital identity token, representing migration from Azure AD B2C to Microsoft Entra External ID

Entra External ID does not yet replicate that. A Microsoft moderator confirmed this directly in a Microsoft Q&A thread from an organization that ran into exactly this wall: new B2C tenant creation is closed to net-new customers, existing customers are unaffected, and there is no workaround for the federation and custom-policy gap in External ID. The response was candid about the limitation rather than papering over it, which is useful information in itself: this is a known, acknowledged gap, not a configuration mistake on the customer’s part.

There is a second limitation worth flagging for anyone running a multi-organization or B2B-style portal. Entra External ID’s contact-mapping feature, which automatically associates an authenticated user with the right Dataverse contact record based on their email address, does not apply to multitenant endpoints. If your portal is meant to serve users from several different partner organizations authenticating through their own tenants rather than one shared consumer-style sign-up flow, that automatic mapping convenience simply is not there yet, and the provisioning logic has to be built by hand elsewhere in the solution.

Neither gap is disqualifying on its own. Both are the kind of detail that surfaces three weeks into a build rather than during the initial scoping conversation, which is exactly when it is most expensive to discover.

What This Means for a Portal You’re Scoping Right Now

Before signing off on the identity approach for a new Power Pages site, it is worth getting a straight answer to a short list of questions. Does the portal need to authenticate users who already have credentials in a system Microsoft does not control, such as a partner’s own identity provider or an on-premises directory that predates your cloud migration? Does user access depend on custom provisioning logic beyond a standard email-and-password or one-time-passcode sign-up, such as auto-approving users from a specific partner domain or pulling attributes from an external system at the moment of first login? Will the portal ultimately need to serve users authenticating from more than one external tenant rather than one consolidated sign-up pool?

A “yes” to any of those questions is worth checking against your organization’s actual B2C status before the project plan gets locked in. If you already hold a B2C tenant, that route remains open and may be the lower-risk path for a portal with those requirements, with the reassurance of Microsoft’s support commitment running through 2030 to absorb the migration timeline. If you do not, the honest scoping conversation is about designing around Entra External ID’s current boundaries: pushing provisioning and claims logic into Power Automate flows or Dataverse plugins that run after a simpler authentication event, rather than assuming the identity layer itself will do that orchestration for you. Microsoft’s own FAQ on this transition is candid that detailed migration guidance is still being finalized and points customers to their account team for specifics, which is itself a signal that this is an evolving area worth revisiting before a portal design is treated as final.

None of this argues against building on Power Pages. It argues for treating the authentication provider decision as a genuine architecture choice again, the way it was before B2C became the automatic default, rather than a checkbox to clear on the way to the parts of the portal that feel more interesting. We have been walking clients through exactly this calculation at Routeget, both for organizations sitting on legacy B2C configurations deciding whether to keep extending them and for net-new engagements designing around External ID’s current limits rather than building technical debt against a gap Microsoft has acknowledged but not yet closed.

#PowerPages #AzureADB2C #EntraExternalID #IdentityGovernance #PowerPlatform #PartnerPortals

Power Pages Client APIs Replace jQuery Guesswork With a Real Object Model

Developer working at a dual-monitor desk with code editors open, illustrating Power Pages Client API development

A Power Pages developer spends an afternoon chasing a bug that only appears for some site visitors. A dropdown built on the Select2 jQuery plugin renders correctly for administrators previewing the site, but silently fails to initialize for anonymous visitors. After an hour of console logging, the cause turns out to be timing: jQuery itself loads from an auto-generated bundle file buried deep in the page, its filename changes with every publish, and the plugin code that depends on it sometimes runs before jQuery is actually available. Nothing in the markup changed. Nothing in the deployment changed. The site just behaves differently depending on exactly when the browser finishes fetching a script nobody on the team explicitly referenced.

This is the kind of problem that has quietly defined custom scripting on Power Pages for years. Developers have never had a real contract with the platform’s client-side behavior. They have had a page that eventually finishes loading a set of libraries in an order that Microsoft controls and can change, and a convention of dropping jQuery-dependent code into a web template and hoping the sequencing holds. Power Pages Client APIs, introduced in public preview in November 2025 and slated for general availability in August 2026 according to Microsoft’s own release plan, are the first attempt to replace that convention with something closer to an actual API surface. For technical teams still writing DOM-selector scripts and crossing their fingers, this changes the calculus on how much custom logic belongs in the browser at all.

What Power Pages Client APIs Actually Provide

The Client APIs expose a single global object, conventionally named $pages, that becomes available once the page signals readiness through Microsoft.Dynamic365.Portal.onPagesClientApiReady(). That function can be called with a callback for teams that need broad browser compatibility, or awaited directly in modern code:

let $pages = await Microsoft.Dynamic365.Portal.onPagesClientApiReady();
let form = $pages.currentPage.forms.getFormById('contact_form');

Once initialized, the object model covers most of what custom scripting on Power Pages has traditionally been used for. Forms expose their controls, tabs, and sections through typed methods rather than CSS selectors, so a script that used to search the DOM for an input with a fragile, auto-generated ID can instead call form.controls[].getValue() and setValue() directly against a named control. Multistep forms get their own navigation methods, hasNextStep(), goToNextStep(), and their counterparts, which replace the button-click interception that multistep customizations previously required. Lists expose visibility controls and a flag indicating whether a given list is rendering in the newer “modern” mode or the legacy one, which matters because the two have historically needed separate customization approaches.

The more consequential addition is $pages.webAPI, which gives scripts a direct, promise-based path to Dataverse through createRecord, retrieveRecord, and retrieveMultipleRecords, each accepting standard OData query options. A developer building a custom submission flow, or pulling related records into a page without a full form postback, no longer needs to hand-roll authenticated fetch calls against the portal’s web API endpoints. There is also a narrower but useful addition in $pages.agent, which lets a page send activities to and receive responses from a Copilot Studio agent embedded in the site, a capability that previously required custom iframe and messaging work to approximate.

Abstract 3D illustration of a structured network of connected data blocks representing an API object model

Where This Actually Sits: Preview Language Versus a GA Date

Here is where technical teams evaluating this feature should slow down rather than take Microsoft’s release plan at face value. The 2025 release wave 2 plan lists August 2026 as the general availability date, and that date has now passed. But as of this writing, Microsoft’s own client API reference documentation still describes the feature as being in preview, states that production use is not recommended until general availability, and points to supplemental terms of use that govern preview functionality. That is not a contradiction so much as a reminder that release plan dates are commitments, not guarantees, and that documentation updates do not always land the same week a feature’s status changes internally. The practical implication is straightforward: before writing a client API dependency into anything customer-facing, check the actual status shown in your own tenant’s Power Pages management app rather than assuming a date on a release plan page reflects where things stand today. If a site is public-facing and the API is still governed by preview terms, that changes the support and SLA conversation with whoever owns the relationship with the business stakeholder, not just the engineering timeline.

This is also a case where “automatically enabled for all users” cuts both ways. Microsoft’s release documentation states the feature is enabled automatically rather than requiring an administrator or maker to turn it on, which means client API availability is not something a governance team can gate the way they might gate a new connector or an AI Builder model. Any site already running on a current Power Pages runtime has access to it now, whether or not anyone on the team has deliberately adopted it yet.

What Actually Changes in Practice

The comparison worth making is not “old JavaScript versus new JavaScript.” It’s the difference between code that depends on the current shape of rendered markup and code that depends on a documented interface. A script that finds a form control by walking the DOM breaks the moment Power Pages changes how it renders that control, a form layout is redesigned, or a plugin update alters class names. A script that calls form.controls[0].getName() and setValue() against the client API object model keeps working across those changes because the API, not the markup, is the contract. That is the same argument that pushed the broader industry away from jQuery over the last decade, and it is arriving on Power Pages roughly ten years after most greenfield web development moved on from DOM-selector-driven scripting as a default.

For teams migrating existing customizations, the realistic approach is incremental rather than wholesale. Forms and multistep wizards with heavy custom validation logic are usually the highest-value targets, since they are where fragile selector-based code causes the most support tickets. A reasonable sequence is to rebuild form-level show/hide and validation logic against the client API first, since that logic tends to be self-contained within a single web template. Web API calls that currently go through hand-authenticated fetch requests to the portal’s REST endpoints are the next candidate, since $pages.webAPI handles the authentication context automatically and the OData query syntax is nearly identical to what most Dataverse developers already know. List customizations and any Copilot Studio agent embedding are reasonable to defer until GA status is unambiguous, given that both are newer additions to the API surface with less production mileage behind them.

One performance detail is easy to miss and worth calling out directly to anyone building against $pages.webAPI: every retrieve call should specify a $select clause. Omitting it returns every column on the entity, which on a wide table like Contact or a custom entity with dozens of fields adds real, measurable latency to what should be a lightweight in-page data fetch. Teams coming from Dataverse plugin or Power Automate development already have this habit; teams whose Power Pages experience is mostly front-end JavaScript may not, since the old web API patterns didn’t make the cost as visible.

The Practical Takeaway

Client APIs won’t retire jQuery from Power Pages overnight, and teams shouldn’t treat the GA date on a release plan page as a green light without checking their own tenant first. But for any organization that has accumulated a pile of DOM-selector scripts held together by convention and hope, this is the first credible alternative Microsoft has shipped, and it is worth prioritizing a pilot on one troublesome form rather than waiting for a big-bang rewrite. Routeget Technologies has walked several clients through exactly this kind of incremental portal modernization, and the pattern that works is consistent: pick the customization causing the most support tickets, rebuild it against the documented API, and let the results make the case for the next one.

#PowerPages #PowerPagesClientAPI #LowCodeDevelopment #PortalCustomization #PowerPlatform #DynamicsDeveloper

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

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

Power Pages Server Logic Is GA: Time to Stop Shipping API Keys to the Browser

Solution architect reviewing a secure server infrastructure and API governance diagram on an office display

Every Power Pages solution architect who has built an external-facing portal knows the workaround. A customer portal needs to check inventory in an external warehouse system, validate an account number against a legacy AS/400, or pull a credit score from a third-party service. Client-side JavaScript can’t do that safely, because anything it calls, including the API key or bearer token needed to authenticate the call, is sitting in plain view in the browser’s network tab the moment a curious (or malicious) visitor opens developer tools. For years the answer was to stand up a dedicated Azure Function as a proxy, just to keep a secret out of the page. It worked, but it meant every external integration came with its own deployment pipeline, its own monitoring, and its own set of credentials to rotate somewhere other than the Power Pages site itself.

Power Pages Server Logic, which Microsoft moved to general availability on April 1, 2026 after introducing it in preview the previous October, removes the need for that detour in a lot of cases. It lets developers write server-side JavaScript that runs inside the Power Pages runtime itself, callable from a page but invisible to it. For architects who have been maintaining a small fleet of Azure Function proxies purely to hide credentials, this is worth a real evaluation, not just a note for next quarter’s backlog.

Solution architect reviewing a secure server infrastructure and API governance diagram on an office display

Why the client-side workaround was never actually secure

It’s worth being precise about what Server Logic fixes, because the risk it addresses is easy to underestimate until someone actually demonstrates it. Web roles and table permissions in Power Pages do a solid job of controlling what a visitor can read or write in Dataverse. They do nothing, however, for a call your client-side script makes to an outside system. If that call needs an API key, and the key lives in a JavaScript file the browser downloads and executes, the key is exposed to anyone who opens the console, regardless of how tightly the portal’s Dataverse permissions are configured. Teams have worked around this by obfuscating scripts, by routing calls through Azure API Management with its own key, or by standing up the proxy function described above. All three approaches work, but all three also add infrastructure that has nothing to do with the actual business problem the portal was built to solve.

What Power Pages Server Logic actually executes

Server Logic scripts run in a constrained JavaScript environment, not a full Node.js sandbox. Microsoft’s documentation specifies ECMAScript 2023 compliance with browser-only APIs such as fetch, XMLHttpRequest, and direct DOM access deliberately blocked, along with other patterns considered unsafe for a multi-tenant hosted runtime. In practice, this means a script author can’t accidentally (or deliberately) reach outside the sanctioned execution model the way they could in an open Node environment.

The authoring flow itself lives inside the standard Power Pages workspace. From the site’s Set Up area, a developer selects Server Logic, creates a new entry with a name that also becomes its API resource identifier, assigns the web roles allowed to invoke it, and then opens the code editor directly in Visual Studio Code from that same screen. Each server logic resource is addressed at a predictable endpoint, /_api/serverlogics/<name>, and the script itself maps HTTP verbs to exported functions: get() for reads, post() for creates, put() and patch() for updates, and del() for deletes. That mapping alone tends to push teams toward cleaner API design than the grab-bag of ad hoc client functions many portals accumulate over a few years of incremental requests.

Developer workstation with a code editor and cloud API architecture diagram on dual monitors

Two ways to call it, and they’re not interchangeable

There are two supported invocation paths, and choosing the wrong one for a given scenario creates unnecessary friction. From a client-side script, you call server logic through shell.safeAjax(), which automatically attaches the CSRF token Power Pages requires for authenticated calls originating from the browser. This is the right pattern any time a form submission, button click, or dynamic page interaction needs to trigger the logic in response to something the visitor does.

The second path is the serverlogic Liquid tag, invoked directly inside a Liquid template during page rendering. Because Liquid itself already executes server-side, there’s no CSRF token to manage, and no round trip back to the browser is needed before the result is available to render. This path fits scenarios where a page needs to show data pulled from an external system, or Dataverse data transformed by business logic, as part of the initial page load rather than in response to a later interaction. Architects who default to the client-side call for everything, out of habit, end up adding an unnecessary network hop and a loading-state UI element for content that could have been resolved before the page was even sent to the browser.

The governance settings that decide whether this is safe to turn on

Server Logic ships with a handful of site settings that determine how much latitude the feature has, and a rollout plan should account for all of them before the first script goes live. ServerLogic/Enabled is the master switch, defaulting to true once the capability is available on a site. ServerLogic/AllowedDomains restricts which external hosts a script is permitted to call, which matters because the default behavior otherwise permits outbound calls to any domain. ServerLogic/TimeoutInSeconds caps execution time, defaulting lower but configurable up to 240 seconds for scripts doing heavier data transformation or waiting on a slow upstream API. Perhaps most importantly for security-conscious organizations, tenant administrators retain the ability to block outbound HTTP calls entirely on a per-site basis, which stops a compromised or misconfigured script from being used to exfiltrate data to an attacker-controlled endpoint. None of these settings are exotic, but skipping the review of even one of them before go-live is how a well-intentioned feature turns into a new attack surface instead of closing an old one.

Access itself is still governed by the same web roles and table permissions that already control the rest of the site, which is a deliberate design choice. Server Logic doesn’t introduce a parallel authorization model; it inherits the one your portal already has, so the roles you’ve already defined for a given customer or partner segment carry through to what that segment can trigger.

What this replaces, and what it doesn’t

It’s tempting to treat Server Logic as a wholesale replacement for custom plugin code, but that’s not quite the right mental model. Dataverse plugins written in C# still own the synchronous event pipeline, the true pre-operation and post-operation hooks that fire on record create, update, or delete regardless of which client touched the record. Server Logic operates at the Power Pages layer, invoked explicitly by a page or a Liquid template, not as a reaction to a Dataverse platform event. What it does replace cleanly is the narrower, very common pattern of a proxy built purely to keep a secret off the client: that use case moves into Server Logic with less infrastructure and one less deployment pipeline to maintain.

It’s also worth flagging that Microsoft’s own preview announcement listed several capabilities as planned ahead of general availability, including unbound Dataverse custom API support and a dedicated debugging playground. Given how quickly this ecosystem iterates, architects evaluating a migration should confirm the current state of those specific capabilities against the live Microsoft Learn documentation rather than assuming everything mentioned in the original preview post has shipped by the time they read this.

A practical starting point

For teams carrying one or two Azure Function proxies that exist solely to shield an API key from a Power Pages portal, Server Logic is a reasonable first migration candidate rather than a full platform overhaul. Pick the simplest existing proxy, rebuild its logic as a server logic resource, route the corresponding client call through shell.safeAjax(), and validate the governance settings against your organization’s actual security requirements before promoting it to production. Routeget Technologies has been walking clients through exactly this kind of targeted migration as Server Logic has moved from preview to GA, and the pattern holds regardless of industry: start with the integration that’s easiest to test, confirm the timeout and domain restrictions match what the proxy was already enforcing, and expand from there once the first one is running cleanly in production.

#PowerPages #ServerSideJavaScript #DataversePortals #APIGovernance #PowerPlatformSecurity #LowCodeDevelopment