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.
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
No comment yet, add your voice below!