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

Document Intelligence 4.0 Gave AI Builder Table Confidence Scores. Most Invoice Models Still Can’t Use Them.

Finance analyst reviewing an AI-extracted invoice line-item table with confidence indicators on a laptop screen

A Dynamics 365 Finance implementation team building an automated three-way match workflow ran into a strange gap last month. Their AI Builder model pulled line items off vendor invoices cleanly enough, quantities, unit prices, and extended amounts all landing in the right columns, but the confidence score field meant to flag shaky extractions for human review came back empty for every table row. The fields around the table had confidence values. The table itself did not. Nobody on the team had touched the model’s configuration since it went into production eight months earlier, so the assumption was a bug, or maybe a licensing issue. It was neither. It was a decision made on day one, buried in a dropdown most builders click past without a second thought: whether the model was trained as a Fixed Template document or a General document.

That distinction matters more than it used to, because AI Builder table confidence scores quietly became a real capability when Microsoft folded Azure AI Document Intelligence 4.0 into the document processing model, and that upgrade behaves differently depending on which training path a model took.

Finance analyst reviewing an AI-extracted invoice line-item table with confidence indicators on a laptop screen

What Document Intelligence 4.0 Actually Changed

Microsoft moved AI Builder’s document processing engine onto Azure AI Document Intelligence 4.0 in stages, with public preview starting December 12, 2024 and general availability landing April 30, 2025. For a lot of Dynamics 365 and Power Platform teams, that rollout came and went without much fanfare, since existing models kept working exactly as before. The upgrade wasn’t a forced migration. It was closer to a set of new tools sitting behind the same interface, available to anyone building or rebuilding a model from that point forward.

The practical additions are worth knowing because they change what’s realistic to automate. OCR accuracy improved, particularly on dense or low-quality scans, the kind that come off a fax gateway or a photographed receipt rather than a clean PDF. Layout detection got better at handling documents where content shifts position from one vendor to the next. Signatures became a taggable field type in their own right, not just background noise the model had to work around, which opens the door to processing signed contracts, lease agreements, and approval forms in ways the older engine handled poorly. And confidence scoring extended down to the table level: individual cells, not just whole fields, can now carry a numeric value a flow or canvas app can act on.

That last point is where the invoice team’s gap came from.

The Model Type Decision Behind AI Builder Table Confidence Scores

AI Builder’s document processing wizard offers three starting points: Fixed Template documents, General documents, and an option to extend the prebuilt Invoices model with custom fields. Fixed Template is built for layouts that don’t move, the same vendor sending the same invoice format every time, and it trains fast because the model only has to learn a small set of positions rather than reason about structure from scratch. General documents is built for the opposite case, varied formats, inconsistent layouts, documents that might come from dozens of different sources, and it trains more slowly because it has to learn structural patterns rather than fixed coordinates.

Here’s the part that doesn’t show up until you go looking for it: table and cell-level confidence scores are only available on models trained as General documents. A Fixed Template model can absolutely extract a table, and it can extract it accurately, but it will not return a confidence score for that table’s cells. Field-level confidence outside of tables works normally on both training types. It’s specifically the table data, line items, schedules, itemized charges, where the gap shows up.

For an accounts payable automation scenario built around Dynamics 365 Finance or Business Central, this is not a minor footnote. Line-item extraction is usually the whole point. A header field like vendor name or invoice total is easy to validate against a purchase order regardless of confidence scoring, but line-item quantities and unit prices are where a bad OCR read causes a real financial error, and they’re exactly the data a human-in-the-loop review queue needs a confidence threshold to triage. A team that chose Fixed Template because their vendor’s invoice format never changes gets faster training and solid extraction, but loses the one signal that would tell them which rows need a second look before they hit the general ledger.

Signatures Change What’s Worth Automating

The signature field type deserves its own mention because it shifts the category of documents worth running through AI Builder at all. Before Document Intelligence 4.0, a signed document was something the model either ignored or occasionally misread as stray marks corrupting a nearby field. Now a signature can be tagged, detected, and reported on as a discrete extraction result, true or false, with its own bounding box.

That matters for scenarios well outside invoice processing. A Project Operations team processing subcontractor agreements can now confirm programmatically whether a returned PDF actually carries a signature before routing it into an approval flow, rather than relying on someone opening every file. A procurement team validating vendor onboarding paperwork gets the same benefit. It’s a narrow capability, but it removes a manual verification step that previously had no automated equivalent in AI Builder at all.

Abstract 3D grid of data cells representing table confidence scoring in AI Builder document processing

Migrating an Existing Model Without Starting Over

Teams running an older model built before the Document Intelligence 4.0 rollout are not required to rebuild from zero to get these capabilities, and the upgrade path is more forgiving than the version number might suggest. According to Microsoft’s own documentation, re-tagging every training document is only necessary if you’re adding new fields, checkboxes, tables, or signature detection that the original model didn’t have, or adding new documents to a collection. If the goal is simply to move an existing, working set of tagged fields onto the newer engine, editing and republishing the model carries the upgrade forward without forcing a full retagging pass.

That’s a lower bar than most people assume when they hear “new model version,” so the practical blocker for most teams isn’t technical effort. It’s the training-type decision made at the start, which can’t be changed after the fact. There’s no toggle that converts a Fixed Template model into a General documents model in place. If table confidence scores turn out to matter after production models are already live, the fix is a genuine rebuild, tagging documents again under the General documents path, not a settings change.

Getting Confidence Scores Into an Actual Review Workflow

Once a model is trained the right way, pulling confidence values into something a human reviewer or a flow can act on is straightforward. In a canvas app, a formula like First(FormProcessor1.Results.'Table 1').Amount.Confidence returns the score for a specific cell, and that value can drive conditional formatting, flag rows below a chosen threshold in red, or filter a gallery down to only the extractions that need eyes on them. In a cloud flow, the Extract Information from Documents action exposes the same values through dynamic content, which makes it possible to branch a flow so that high-confidence invoices post automatically while anything below the threshold routes to an approval step in Teams or a shared queue.

Setting that threshold is more art than science. Microsoft doesn’t publish a universal number, because the right cutoff depends on the cost of an error against the cost of unnecessary review. A finance team automating high-dollar vendor invoices will reasonably set a stricter threshold than a team processing low-value expense reports, and it’s worth running a batch of real historical documents through the Quick Test tool before committing to a number, since that’s where the actual confidence distribution for your document set becomes visible rather than theoretical.

Before You Build the Next One

The rebalancing lesson here isn’t that General documents is always the right choice. Fixed Template models train faster, tend to hit high accuracy sooner with fewer sample documents, and remain the right call for genuinely stable, single-format use cases where table validation isn’t part of the workflow. The mistake is making the training-type decision without knowing it also decides whether confidence scoring will be available on table data later, and finding that out only after a review process built around those scores comes up empty.

Anyone scoping a new document processing model, or auditing one already in production, should treat this as a five-minute check worth doing now rather than a surprise found in eight months. If line-item or table-level confidence scoring is part of the plan, even a future plan, General documents is the only path that supports it, and that has to be decided before the first sample document gets tagged.

At Routeget Technologies, this is the kind of gap we look for early in an automation build, not because the underlying capability is complicated, but because a wrong assumption made in a five-minute setup screen tends to surface eight months later, in production, exactly when it’s most expensive to fix.

#AIBuilder #DocumentIntelligence #InvoiceAutomation #AccountsPayableAutomation #PowerPlatform #EnterpriseAI

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

The Dataverse Git Integration GitHub Preview Needs a Key Vault, Not Just a Login

An IT solutions architect presenting a software deployment pipeline diagram on a large office monitor

A Power Platform ALM engineer at a mid-market manufacturer spent a Tuesday afternoon trying to move a client’s Dataverse Git integration off Azure DevOps and onto GitHub, where the rest of the company’s engineering org already lived. The Azure DevOps connection had taken fifteen minutes to set up the year before: sign in, pick a project, pick a repository, done. She assumed GitHub would be the same flow with a different login screen. Four hours, one Azure Key Vault resource, one GitHub App registration, and one role assignment to a service principal she’d never heard of later, she had a working connection, and a much clearer idea of why Microsoft shipped Azure DevOps support first.

That gap between expectation and reality is worth understanding before any team commits to the GitHub option, because it is not a bug or an oversight. It reflects a real architectural difference in how the two providers authenticate, and it changes the planning and staffing conversation for anyone treating this as a same-day migration.

An IT solutions architect presenting a software deployment pipeline diagram on a large office monitor

What Dataverse Git integration actually does

Dataverse Git integration is Microsoft’s native, in-product answer to a problem that Power Platform teams have patched around for years: getting solution components out of an environment and into a real source control history without standing up a full pro-dev toolchain. Instead of relying solely on the Power Platform CLI, Azure Pipelines, and a developer’s local machine to export, unpack, and commit solution XML, makers and admins can now connect an unmanaged solution directly to a Git repository from inside make.powerapps.com, commit changes as they’re made, and let Power Platform Pipelines handle promotion to test and production from there.

The mechanics matter because they explain the limits. Only unmanaged solutions in development environments connect to Git; managed solutions still move downstream through Power Platform Pipelines, not through branch merges. Component changes sync to a human-readable, YAML-based file format designed to diff cleanly, a deliberate departure from the sprawling XML that classic solution exports produce. And a full solution commit is atomic: you cannot cherry-pick individual component changes within a solution the way you would stage individual files in a typical Git workflow. Teams coming from a code-first background, expecting Git semantics all the way down, tend to hit that ceiling first.

Azure DevOps was the first provider Microsoft supported, and it reached general availability well ahead of GitHub. The connection setup leans on infrastructure Azure DevOps and Dataverse already share inside the same Microsoft Entra tenant: create a project with Git version control enabled, confirm the connecting user has Contributor access to the repository, enable managed environments on both the source and target environments, and connect from the solution’s source control panel. There is no separate secrets store to provision and no custom application registration required, because the trust relationship rides on existing Azure identity.

Why the GitHub path looks different

GitHub support entered public preview in the 2026 release wave 1 cycle, and the setup reflects the fact that GitHub sits outside the Azure AD trust boundary that made the Azure DevOps connection comparatively simple. Rather than a native OAuth handshake alone, the documented path requires registering a dedicated GitHub App under organization settings, granting it read-and-write access to repository contents, generating a private key for that app, and then storing that key somewhere Dataverse can retrieve it securely. That somewhere is Azure Key Vault, in the same Microsoft Entra tenant as the Dataverse environment, which means a team without an existing Key Vault footprint is now standing one up specifically to support source control.

Abstract illustration of a secure vault connected to a code repository network and a cloud identity shield, representing credential management between GitHub and Dataverse

The chain continues from there. After the private key lands in Key Vault, the environment’s own managed identity, provisioned automatically as something like PPMI-githubappconfigmanagedidentity followed by a GUID, needs the Key Vault Crypto User role assigned to it through Key Vault’s access control settings before Dataverse can actually use the stored credential. Only after that RBAC assignment resolves does the GitHub connection in the solution’s source control panel have what it needs to authenticate. None of this is exposed as a single wizard; it’s a sequence across GitHub’s developer settings, the Power Apps maker portal’s Connections page, and the Azure portal, and a missed step in any of the three stops the whole chain cold with a generic authentication failure that doesn’t point back to which link broke.

Two additional constraints are worth flagging before a team plans around this path. GitHub-based connections are not currently compatible with Dataverse environments that have virtual network support enabled; if VNET injection is part of your environment’s security posture, the documented workaround is a GitHub personal access token instead of the OAuth connection, which trades one credential management problem for another. And if the organization has restrictions on third-party OAuth application access, which many regulated enterprises do by default, an org admin has to explicitly approve the GitHub App before any maker can complete the connection, adding an approval-queue dependency that Azure DevOps setups don’t carry.

Planning the rollout instead of the demo

None of this makes the GitHub option a bad choice. For an organization that has already centralized its application source, its pull request review culture, and its CI/CD runners around GitHub, keeping Power Platform solutions in a second, Azure DevOps-only silo creates its own governance problem: two source control systems, two access review processes, two places an auditor has to look. The GitHub preview closes that gap. It just closes it with real infrastructure work attached, not a checkbox.

Two prerequisites tend to get discovered late rather than planned for. Managed environments must be enabled on every environment in the chain, development and target alike, and that entitlement itself is included at no extra cost with standard Power Apps, Power Automate, Copilot Studio, Power Pages, and Dynamics 365 licenses, but explicitly excluded from the Developer Plan. A team piloting this in a free developer environment will hit a wall before they hit the GitHub App registration screen. Second, this is explicitly documented as a preview capability intended for development environments only, not test or production, so any rollout plan that assumes it is production-ready today is planning against documentation that says otherwise.

The practical sequencing that avoids the four-hour surprise looks like this: confirm managed environments are already enabled or budgeted for, decide up front whether VNET requirements in any target environment rule out the OAuth path in favor of a PAT, and treat the GitHub App registration, Key Vault provisioning, and managed identity role assignment as three discrete, ownable tasks rather than one setup step, ideally assigned to whoever already owns Key Vault and Entra app registrations in the organization rather than the Power Platform maker who happens to be doing the connecting. Teams that scope it that way tend to get through it in an afternoon. Teams that treat it like the Azure DevOps flow tend to get the same four-hour afternoon the engineer in the opening scenario had, just with more frustration attached.

Routeget Technologies has walked several clients through exactly this kind of ALM tooling decision, usually as part of a broader review of where Power Platform governance sits relative to the rest of an organization’s engineering practices. The right answer isn’t universally GitHub or universally Azure DevOps; it’s whichever one matches where the organization’s source of truth already lives, evaluated with the actual setup cost in view rather than the marketing description of “now supports GitHub.”

For architects scoping this now, the preview label matters less than the identity and secrets infrastructure it assumes you’re willing to stand up. If that infrastructure already exists in your tenant, the GitHub path is a reasonable few hours of work. If it doesn’t, budget for building it before you budget for the migration itself.

#DataverseGitIntegration #PowerPlatformALM #GitHubIntegration #EnterpriseDevOps #ITGovernance #PowerPlatform

Power Automate’s Object-Centric Process Mining Is GA. Your Bottleneck Data Still Needs a Pipeline First.

A finance operations leader reviewing a process mining dashboard showing connected order, invoice, and payment flows

A finance operations director running Dynamics 365 Finance and Operations recently walked into a budget review with a straightforward automation pitch: build Power Automate flows to shorten the order-to-cash cycle. The CFO’s response was less straightforward. Before funding new flows, she wanted proof of where the cycle actually breaks down, not an assumption based on which team complains loudest. That question, where is the process actually stalling and why, is precisely what Microsoft’s object-centric process mining capability in Power Automate was built to answer. It reached general availability on June 5, 2026, and it changes what a process mining exercise can tell a finance or operations leader. It also comes with a data engineering requirement that most teams have not budgeted for yet.

A finance operations leader reviewing a process mining dashboard showing connected order, invoice, and payment flows

Why Case-Centric Process Mining Kept Missing the Real Bottleneck

Power Automate has offered process mining for several years, and Dynamics 365 Supply Chain Management customers on version 10.0.35 and later already have a purpose-built entry point: a warehouse material movement analysis template that reads closed warehouse work records straight out of Dataverse, no custom configuration required. That capability is genuinely useful, and it works because it treats a process as a single, well-defined case, such as one warehouse work order moving through a fixed sequence of steps.

The limitation shows up the moment a process stops being a clean sequence. An order-to-cash cycle is not one case moving through one lane. A single sales order can spawn multiple shipments, each shipment can be tied to more than one invoice, and a payment can settle across several invoices at once. Traditional case-centric mining forces all of that into one case identifier, which means analysts either duplicate events across cases to preserve accuracy, or they flatten the relationships and lose the very dependency that caused the delay. Microsoft’s own framing of the problem is direct: a shipment held up because an unrelated invoice on the same customer account went unpaid is exactly the kind of cross-object dependency that a single-case view cannot represent cleanly. Object-centric process mining, or OCPM, is built to keep orders, invoices, payments, and shipments as separate but linked object types within one process map, so an analyst can see where those flows intersect and where the actual delay originates.

What Object-Centric Process Mining Changes Once It’s Running

The practical difference for a finance or supply chain leader is that root cause analysis stops requiring a manual reconciliation project. Instead of pulling separate reports for orders, accounts receivable, and logistics and asking an analyst to manually trace where they intersect, OCPM keeps those relationships intact in the underlying data model from the start. Microsoft describes the intended outcome as compressing root cause investigations that used to take weeks down to hours, along with the more familiar benefits of shorter cycle times, lower operational cost, and better resource utilization once the actual constraint is identified rather than guessed at.

For a CFO evaluating where to spend the next automation budget, that matters more than it might first appear. A process improvement initiative built on a flattened, case-centric view risks automating the wrong step: speeding up invoice approval, for instance, when the true constraint is a shipment reconciliation process three steps downstream that only becomes visible once orders, invoices, and shipments are analyzed together. Object-centric process mining is designed to surface that kind of hidden dependency before a Power Automate build begins, which is a materially better position than discovering it after a flow has already been deployed and the expected cycle-time improvement doesn’t show up.

An abstract illustration of connected order, invoice, and payment objects intersecting in a process map

The Data Pipeline Nobody Is Budgeting For

Here is the part that tends to get skipped in the pitch. The Dataverse-native warehouse analysis template mentioned earlier works because case-centric process mining can read Dataverse tables directly. Object-centric process mining, as it stands today, does not offer that same direct connection to Dataverse or to Dynamics 365 tables. It ingests data as a CSV file structured according to Microsoft’s object-centric event log, or OCEL, format, stored in either Azure Data Lake Gen2 or OneLake. Fabric Lakehouses with schema support enabled are explicitly not yet supported as a source, which rules out one path some teams might assume would work.

Building that OCEL file is not a trivial export. The mapping step requires at least one activity attribute, at least one start event attribute, and at least two object type attributes, with optional end event, resource, and additional event or object-level attributes layered on for richer analysis. In practice, that means someone, whether an internal analytics team or an implementation partner, needs to design an extraction and transformation process that pulls order, invoice, payment, and shipment events out of Dynamics 365 and Dataverse, aligns them to a shared activity and object model, and lands the result as a correctly structured CSV before OCPM can analyze anything. That is a real data engineering task, and it is separate from, and in addition to, the Power Automate Premium licensing already required to use process mining at all.

What the Licensing Actually Covers

On the cost side, process and task mining are bundled into the Power Automate Premium per-user license, which includes both capabilities along with a starting capacity pool: each licensed user contributes 50 MB toward a shared tenant-wide limit that caps at 100 GB. Organizations that outgrow that pool can add the Power Automate Process Mining add-on, priced at the tenant level, which adds another 100 GB of process mining capacity along with additional Dataverse database and file storage. Customizing the reporting layer against your own Power BI workspace requires a separate Power BI Premium license. None of that licensing changes because a team chooses object-centric analysis over case-centric analysis, which means the incremental cost of adopting OCPM is almost entirely the data pipeline work, not the software itself.

What’s Coming That Should Factor Into Timing

Two features on Microsoft’s own roadmap are worth factoring into a rollout decision rather than treating OCPM as a finished, static capability. Support for exporting object-centric process mining data to a Microsoft Fabric semantic model is planned for August 2026, which would let this data flow into existing Power BI and Fabric reporting rather than staying siloed inside the process mining tool itself. Normalized schema import support for data ingestion, also targeted for August 2026, is intended to ease some of the current data preparation burden, though it has not been detailed in enough depth yet to know how much of the CSV construction work it actually removes. A broader Process Intelligence Studio experience is set to preview in September 2026 and reach general availability the following month, consolidating process mining, task mining, and related analysis into a single workspace. Teams weighing whether to invest in the manual OCEL pipeline now versus waiting a quarter for these dependencies to mature have a legitimate reason to ask that question before committing engineering time.

Where This Leaves a Decision-Maker Today

None of this argues against object-centric process mining. It argues for treating it as what it is: a genuinely more accurate way to see how a multi-object process like order-to-cash or procure-to-pay actually behaves, paired with a data preparation cost that is easy to underestimate when the feature is pitched as simply “available now.” Before funding an OCPM initiative, it is worth confirming which specific cross-object process is causing the most cost or delay, whether that process’s underlying data already exists in a form close to the OCEL structure or will require meaningful transformation work, and whether waiting for the Fabric export and normalized schema import features changes the math on doing this now versus later this year. Routeget Technologies has walked several Dynamics 365 clients through exactly this kind of data readiness assessment before committing to a process mining build, and the pattern holds consistently: the mining tool itself is rarely the bottleneck. The data getting to it is.

#PowerAutomate #ProcessMining #AutomationROI #OrderToCash #DataverseIntegration #PowerPlatform

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 Automate’s Self-Healing Desktop Flows: What Gets Fixed, and What Still Breaks

IT operations engineer monitoring automated workflow dashboards on multiple monitors

A desktop flow that has run clean for eight months can start failing on a Tuesday morning for reasons that have nothing to do with the flow itself. A vendor portal repaints its login page during a routine update, a button that used to sit at a fixed set of pixel coordinates shifts three rows down, and the automation that finance has relied on for month-end reconciliation throws “Element not found” at 6 a.m. with nobody watching. This is the specific kind of fragility that Power Automate’s newly introduced self-healing desktop flows capability is built to reduce, and it is worth understanding precisely what the feature does before assuming it solves a problem it was never designed to solve.

IT operations engineer monitoring automated workflow dashboards on multiple monitors

Why UI Automation Breaks in the First Place

Desktop flows built around UI and browser automation actions work by capturing a selector, essentially a description of where an element lives inside an application’s structure, and replaying that description at runtime to find the same button, field, or menu again. That approach has always been reliable right up until the moment it isn’t. A web app ships a design refresh. A desktop application renames a control during a patch. A browser update changes how a page renders just enough that the original selector no longer resolves to anything. None of these changes touch the business logic of the flow at all, yet they are historically among the most common reasons a production RPA process stops overnight. They are also the reason RPA teams spend a disproportionate share of their maintenance time on selector repair rather than on building anything new.

What Self-Healing Desktop Flows Actually Do

Self-healing entered public preview on March 31, 2026, as an agentic capability scoped specifically to UI and web automation actions inside Power Automate for desktop, version 2.66 and later. It is not a general reliability feature, and it does not run continuously in the background. It activates only at the moment a specific action throws an Element not found error on the primary or secondary screen, or a Window not found error on the main screen, and only for actions involving a single UI element interaction such as a click or a checkbox selection.

When that failure occurs, the flow’s existing retry policy still runs first. Self-healing sits as a fallback step after retries are exhausted and before whatever error handling rules a maker has configured downstream, things like setting a variable or running a subflow. At that point, the desktop flow captures a screenshot of the missing element’s expected location, the parent window’s title, and a full image of the desktop, then passes that context to two large language models working in combination: GPT-4.1 mini and Claude Sonnet 4.5. The models attempt to identify a UI element that plausibly matches what the original selector was looking for, propose it as a substitute, and let the flow continue. If neither model can produce a confident match, the flow falls through to normal error handling exactly as if self-healing were not enabled at all.

That single design choice, using self-healing purely as a recovery mechanism rather than a permanent correction, matters more than it might first appear. The feature does not rewrite the flow’s stored selector once it recovers. Every future run of that same action will hit the same missing-element error and go through the same self-healing detour again, which means self-healing reduces the visible symptom of a broken selector without eliminating the underlying maintenance debt sitting behind it.

Where the Coverage Actually Stops

Teams evaluating this feature tend to assume it covers more ground than it does, and the gaps are specific enough to matter for planning. Self-healing does not apply to window or screen handling actions, so a flow that fails because an entire application window can’t be located, rather than a single control inside it, gets no help here. It does not extend to multi-element interactions like drag-and-drop, which remain exactly as brittle as before. It has no effect during designer test runs, applying only to console and cloud runs in attended or unattended mode, so a maker debugging inside the desktop flow designer won’t see it engage at all. And because the underlying models work from a screenshot and a window title rather than the application’s actual DOM or object model, self-healing is inherently probabilistic. Microsoft’s own documentation is direct about this: the models can occasionally identify the wrong element, which for a click action on a financial approval screen is not a theoretical risk worth shrugging off.

Close-up of a laptop screen showing a workflow diagram with one error node highlighted

There is also a visibility gap worth planning around before rollout rather than discovering during an incident. The Power Automate portal does not currently surface self-healing activity inside standard action-level run logs. The desktop flow run page shows a rollup of up to three successful self-healing attempts, but anyone who wants a full audit trail has to fall back to a registry setting that writes a repairWithAIInfo property into local log files on the machine running the flow. That is a meaningfully more manual process than most teams are used to for production RPA monitoring, and it is worth building into a rollout checklist rather than assuming the standard portal view will show everything.

Turning It On

Enabling self-healing is not a single toggle, and the chain of prerequisites is easy to get partway through and assume is finished. It starts in the Microsoft 365 admin center, under Copilot settings, where Anthropic has to be enabled as an approved AI subprocessor. This is already the default for most commercial cloud tenants, but it is worth confirming rather than assuming, especially in regulated environments where subprocessor lists get reviewed on a fixed schedule. From there, the same approval has to be granted a second time inside the Power Platform admin center, under Copilot settings, where external models are configured at either the environment or environment group level. A tenant using non-US regions also needs to explicitly allow data to move across regions under that environment’s generative AI features, since the underlying model calls are not necessarily processed in-region otherwise. Only after those three settings are in place does a fourth toggle, Copilot in Power Automate under the same admin settings, need to be switched on before the capability becomes available to makers at all.

At the flow level, the configuration is much simpler by comparison. Inside the desktop flow designer, a maker opens the error handling settings on a supported UI or web automation action and switches on self-healing for that specific action, one action at a time rather than as a flow-wide setting. This granularity is a genuine advantage for a phased rollout. A team can enable self-healing selectively on the handful of actions in a flow that interact with the least stable third-party interfaces, such as a vendor portal outside the organization’s control, while leaving internal, well-governed applications on standard error handling until there is a clearer track record to point to.

Fitting This Into an Error-Handling Strategy, Not Replacing One

The practical risk with a feature like this is not that it fails to work as documented. It is that a maker treats a preview capability with known gaps as a substitute for the selector discipline, monitoring, and testing that RPA has always required, and quietly stops doing that harder work because the flow appears to keep running. The teams getting real value from self-healing so far are treating it as one layer in a broader error-handling stack, sitting below a solid retry policy and above a documented escalation path, rather than as the whole strategy. That means still designing selectors deliberately instead of accepting whatever the recorder captures by default, still monitoring flow run history instead of assuming silence means success, and still budgeting time for the registry-level log review needed to catch a self-healing attempt that quietly picked the wrong element on a screen nobody double-checked afterward.

Used that way, self-healing does what its name suggests for a specific and fairly narrow category of failure: it buys time and reduces the volume of after-hours pages caused by a button that moved six pixels to the left. It does not, and by Microsoft’s own account is not meant to, remove the need for an RPA program that treats maintenance as part of the design rather than an afterthought to it. Routeget Technologies has been walking clients through exactly this kind of phased rollout, piloting self-healing on the least stable external-facing actions in a flow before deciding how far to extend it. That sequencing, more than the feature itself, is usually what determines whether a preview capability like this earns a permanent place in production.

#PowerAutomate #SelfHealingFlows #DesktopFlows #RPAGovernance #PowerPlatform #AutomationReliability