September 19, 2026

Dataverse Audit Logs to Purview Now Redact Sensitive Fields. Your Incident Response Runbook Still Points There.

Compliance analyst reviewing a Dataverse audit log dashboard with some sensitive fields redacted before reaching Microsoft Purview

A security engineer investigating a compliance escalation pulls up Microsoft Purview’s unified audit log and searches for changes to a customer’s tax identification field in a Dynamics 365 Finance environment. The Dataverse audit configuration has been correctly enabled for years: environment-level auditing is on, the table is audited, the column is audited, and “Read logs” has been flowing activity to Purview since the tenant went live. Yet the search results show the record was updated, by whom, and when, but the actual before-and-after values for that field come back empty. Nothing is broken. Since June 26, 2026, Dataverse audit logs to Purview have deliberately worked this way for a defined set of sensitive columns, and most compliance and security teams have not yet updated their runbooks to account for it.

The feature responsible is a narrowly scoped but consequential change: Dataverse now strips certain categories of sensitive data, specifically financial information, health data, and personally identifiable information, out of audit events before they are transmitted to Purview’s activity logging pipeline. The values still exist. They are simply no longer making the trip to Purview, and that distinction has real operational consequences for anyone who built incident response, eDiscovery, or SIEM processes on the assumption that Purview’s audit log search was the complete picture.

What Actually Changed in Dataverse Audit Logs to Purview

Dataverse auditing has always captured create and update events at the column level, including the before-and-after value of every audited field, when environment, table, and column auditing are all enabled through the hierarchy Microsoft documents under Security, Compliance, and Auditing in the Power Platform admin center. Historically, if the environment’s “Read logs” setting was turned on, that entire audit record, field values and all, flowed to Purview’s unified audit log and became searchable at compliance.microsoft.com/auditlogsearch by anyone with the appropriate compliance role.

That behavior is what changed with general availability on June 26, 2026. Microsoft’s own release notes describe the mechanism plainly: create and update events, including a column’s before-and-after values, are still captured in Dataverse’s native audit store exactly as before. What changes is the copy sent onward to Purview. Financial data, health and medical information, and personally identifiable information are removed from that outbound payload before it leaves Dataverse. A change to a customer’s shipping address or a sales order’s discount percentage will still show full detail in Purview. A change to a national ID number, a diagnosis code stored in a custom health field, or a salary figure will not, even though every one of those changes is still fully visible inside Dataverse itself.

The rationale is straightforward: the unified audit log has a materially larger blast radius than Dataverse’s native audit history. Native audit history requires a Dataverse security role scoped to a single environment. The Purview unified audit log is a tenant-wide surface, reachable through eDiscovery cases and exportable by compliance investigators who may hold no Dynamics 365 role at all, retained under Microsoft 365 audit policy rather than Dataverse’s own retention settings. Sending unredacted salary or health data into that surface multiplied the number of people who could, deliberately or accidentally, end up looking at it.

Two Purview Pipelines That Behave Differently

Here is where the practical confusion tends to start. Dataverse actually feeds Purview through two distinct mechanisms, and they were never symmetrical even before this change. Classic Dataverse auditing, the one most organizations configured years ago through the environment’s “Log access” and “Read logs” toggles, is the pipeline this new redaction applies to. It is also the pipeline that historically sent complete field-level detail.

Separately, Dataverse’s comprehensive activity logging, the broader mechanism that captures nearly every SDK message an environment processes, including bulk exports, Advanced Find queries, and support engineer actions, has never sent column-level before-and-after values to Purview at all. Microsoft’s own documentation on comprehensive auditing states that column-level secured field values are sent to Purview as an asterisk rather than the underlying data, and that detailed field-level changes are withheld entirely from that pipeline specifically to prevent data leaks. That restriction predates the June 2026 change and applies regardless of whether a field touches financial, health, or PII data.

The practical upshot is that an organization relying primarily on comprehensive activity logging for its Purview visibility was already missing granular field values, and nothing changes for them. An organization that built its compliance program around classic Dataverse auditing with “Read logs” enabled, treating Purview’s audit log search as a faithful mirror of Dataverse’s own audit history, just lost a slice of that fidelity for exactly the categories of data most likely to matter in a regulatory inquiry.

Abstract illustration of a data grid with selectively redacted cells representing sensitive data masking

Where the Complete Record Still Lives

Nothing about this change reduces what Dataverse itself retains. The full before-and-after values for every audited column, sensitive or not, remain in Dataverse’s native audit store under whatever retention policy the environment has configured, which can run from a fixed number of days out to indefinite retention on production environments that support it. That data is accessible through the Power Platform admin center’s auditing summary view, through the classic audit history UI on individual records, and programmatically through the Dataverse Web API using the Audit entity or the RetrieveRecordChangeHistory message.

This is the detail worth building process around: if an investigation genuinely needs the value of a redacted sensitive field, the answer is not to escalate a Purview support ticket, it is to pivot the investigation to query Dataverse directly, using a role that has legitimate access to the Audit entity in that specific environment. That is a narrower, more auditable path than a tenant-wide Purview search, which is precisely the point of the change, but it means any documented incident response procedure that says “search Purview” as the first and only step now needs a second step for sensitive-field cases.

What to Check in Your Environment

Start by confirming which environments actually have “Read logs” enabled at the environment level, since that is the specific setting this change affects. Environments relying solely on comprehensive activity logging were never sending field-level detail to Purview and require no adjustment on this front, though it is still worth confirming which pipeline your compliance team believes it is querying, because in practice that assumption is not always accurate.

Next, inventory any downstream system that consumes Purview’s unified audit log for Dataverse activity: SIEM ingestion pipelines, Sentinel analytics rules built on audit log content, scheduled compliance reports, or custom Power BI dashboards pulling from the audit log search API. Any of these that parse or alert on specific before-and-after field values for financial, health, or PII columns will now see blank or null values where they previously saw data, which can silently break a detection rule that was matching on a specific value pattern rather than simply on the fact that a change occurred.

It is worth testing this directly rather than taking the documentation’s word for it, since Microsoft does not fully specify the exact classification logic used to flag a column as financial, health, or PII data. In a sandbox environment, make a controlled change to a column you believe falls into one of those categories, then compare what appears in Purview’s audit log search against what native Dataverse audit history shows for the same event, and repeat the test with a column outside those categories. The gap between documentation and observed behavior is where governance teams tend to get surprised months later.

A Compliance Improvement, Not a Complete DLP Control

It is tempting to read this feature as Microsoft having solved sensitive-data exposure in audit logging, and it has not, at least not entirely. It reduces exposure specifically on the path from Dataverse to Purview’s unified audit log for three defined data categories. It does nothing about sensitive data that lives in Dataverse’s own audit store, in exports, in Dataflows destinations, in Power BI datasets built on top of audited tables, or in any custom integration that pulls audit data directly from the Web API rather than through Purview. Organizations that treat this as a checkbox for their broader data loss prevention obligations under regulations like HIPAA or a state privacy law are conflating a narrow platform default with a program-level control, and an auditor will draw that distinction even if the platform release notes do not spell it out.

The more accurate framing is that Microsoft closed one specific, previously overlooked exposure path, and organizations now need to confirm their own audit consumption patterns still work correctly on the other side of that change. For teams running Dynamics 365 Finance and Operations or Customer Engagement with meaningful volumes of regulated data, that is a worthwhile few hours of validation, not a reason to assume the compliance posture improved on its own without anyone checking. Routeget Technologies has walked several clients through exactly this kind of audit configuration review after a platform-level change shifted what their existing monitoring actually captured, and the pattern is consistent: the environments that catch these gaps early are the ones that treat platform release notes as an input to a review, not as the review itself.

#DataverseAudit #MicrosoftPurview #PowerPlatformGovernance #DataLossPrevention #ComplianceMonitoring #EnterpriseSecurity

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.

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

Accounts Payable Automation AI Builder Document Intelligence Enterprise AI Invoice Automation Power Platform

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

Dynamics Developer Low Code Development Portal Customization Power Pages Power Pages Client API Power Platform

Dynamics 365 Copilot Capacity Budgeting Just Lost Its Calendar

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

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

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

What Microsoft actually changed

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

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

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

Why Sales Qualification Agent makes this concrete, not abstract

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

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

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

What changes in Dynamics 365 Copilot capacity budgeting

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

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

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

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

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

AI at Work Roadmap Copilot Capacity Dynamics Sales Enterprise AI Power Platform Governance Sales Qualification Agent

Business Central’s New EDI Documents Feature Won’t Let You Cancel Your EDI Provider

Finance operations manager reviewing electronic document exchange status in a logistics office

If your finance team is currently paying an outside EDI provider a recurring fee to keep your Business Central environment talking to Walmart, a major distributor, or a third-party logistics partner, the preview notes for Business Central 2026 release wave 2 probably caught your eye. Buried in the update 29.0 feature list is the new EDI documents feature: the ability to exchange orders and payments, not just invoices, directly through the E-Documents framework using the Peppol BIS 3 standard. For a CFO or IT director who has spent years signing checks to a middleware vendor just to keep retail trading partner mandates satisfied, that sentence reads like an invitation to finally consolidate. It is worth understanding exactly what changed before anyone drafts a cancellation notice.

What the new EDI documents feature actually adds

Business Central’s E-Documents framework is not new. It has existed for several release cycles as the mechanism behind country-specific e-invoicing mandates: Peppol for Australia and New Zealand, OIOUBL in Denmark, XRechnung and ZUGFeRD in Germany, Factura-E in Spain, with France support arriving this year. Until this release, the framework’s job was largely to get sales invoices out the door and purchase invoices in, formatted correctly for whichever national authority or trading network required them.

What update 29.0 adds, currently in public preview as of September 2026 and scheduled for general availability in October, is support for exchanging orders and payments through that same framework, using the Peppol BIS 3 EDI standard specifically. In practical terms, that means a document type beyond the invoice can now move through E-Documents using a message format built for machine-to-machine exchange rather than a PDF attached to an email. That is a genuine expansion of scope, and for the right customer it closes a real gap.

The catch is in the phrase “Peppol BIS 3.” Peppol is a specific network and message specification, developed originally for European public procurement and now widely used for e-invoicing compliance across the EU, the UK, Australia, New Zealand, and a growing list of other jurisdictions. It is not the same thing as the ANSI X12 or EDIFACT standards that govern the EDI relationships most North American manufacturers, wholesalers, and distributors maintain with retail trading partners. A purchase order transaction set 850, an invoice 810, or an advance ship notice 856 sent through a retailer’s EDI network does not speak Peppol, and nothing in this release changes that.

Abstract illustration of electronic documents flowing between two connected trading partner networks

Why the connector layer still matters

There is a second detail worth flagging before anyone assumes this feature makes Business Central’s e-document capability self-sufficient. The E-Documents framework has always relied on named third-party service connectors to actually move documents onto whatever network the recipient uses. Pagero, Avalara, Logiq, SignUp’s ExFlow e-invoicing service, and B2BRouter are the currently supported options, and each requires its own separate contract and, in most cases, its own subscription cost. Microsoft’s documentation is explicit that these are external commercial relationships, not services Microsoft itself manages end to end.

That architecture does not change with the EDI feature. Adding order and payment support to E-Documents means the framework can now carry more document types over the Peppol BIS 3 rail, but a business still needs a connector relationship in place to actually reach a Peppol access point, just as it does today for invoices. For a company operating primarily in Peppol-covered geographies, that is a meaningful simplification: one framework, one set of document types, and potentially fewer point-to-point integrations for order confirmations and payment status messages that previously ran through a separate mechanism entirely.

For a company whose EDI obligations run through a North American retail network instead, the calculus barely moves. The dedicated EDI platforms built around Business Central, names like TrueCommerce, SPS Commerce, and the various Business Central-specific EDI ISV solutions on AppSource, exist precisely because they translate between Business Central’s data model and the X12 and EDIFACT transaction sets that retailers, grocers, and big-box trading partners require, along with the value-added network relationships those partners often mandate. None of that is addressed by extending Peppol BIS 3 coverage to orders and payments. If your EDI provider’s invoice is for connecting to a VAN and translating X12 850s into sales orders, this preview feature does not touch that relationship at all.

What to actually check before wave 2 reaches general availability

The practical work here is not deciding whether to switch, it is figuring out which category your organization falls into, and that requires a document-by-document inventory rather than a guess. Start by pulling the list of every trading partner your company currently exchanges electronic documents with through Business Central, and note the standard each one actually uses. A subsidiary invoicing government or large enterprise customers in the EU, Australia, or New Zealand through a Peppol access point is a strong candidate to benefit directly once this feature reaches general availability, since order and payment documents for those same relationships may be consolidatable into the same connector and the same E-Documents setup already in place for invoicing.

A distribution or manufacturing business fulfilling retail purchase orders through a VAN-based EDI relationship should not expect this update to reduce that spend. It is worth raising the question directly with your existing EDI provider anyway, since some of them are exploring hybrid support that bridges Peppol and traditional EDI standards, and a provider roadmap conversation now costs nothing and might surface options before your next contract renewal.

It is also worth remembering that this is a preview feature, not a shipped one. General availability is not expected until October 2026, and preview functionality in Business Central has a track record of shifting in scope, licensing treatment, or connector support between preview and GA. Testing this in a sandbox environment against a real Peppol-connected trading partner, rather than assuming the release notes describe the final behavior, is the responsible way to validate whether it does what your business actually needs before making any commercial decision tied to it.

One more consideration deserves a place on the evaluation checklist: cost. Connector-based e-document exchange through Avalara, Pagero, or similar providers is typically priced per transaction or per connection, separate from Business Central licensing itself. Adding order and payment document types to that same connector relationship may increase transaction volume through the connector without necessarily reducing your total third-party spend, particularly if your current EDI provider is priced on a flat annual basis rather than per document. Getting an updated quote from your connector provider that reflects the expanded document scope, before assuming the math works in your favor, avoids an unpleasant surprise on the next renewal invoice.

The gap this does close

None of this is a criticism of the feature itself. Extending E-Documents to cover orders and payments, and doing it through a widely adopted international standard rather than a proprietary Microsoft format, is a sensible direction for a platform that increasingly serves multinational subsidiaries alongside single-entity small businesses. Firms with meaningful European, UK, Australian, or New Zealand operations that have already invested in Peppol-based invoicing now have a credible path to extend that same investment to a broader set of transaction types, which is exactly the kind of incremental platform improvement that reduces the number of point integrations a lean IT team has to maintain over time.

The mistake would be treating a preview release note as a green light to unwind an existing EDI relationship without first confirming which standard that relationship actually runs on. Routeget’s engagements with Business Central customers on electronic document strategy typically start with exactly that inventory: mapping every trading partner document exchange against the standard it uses, before any conversation about consolidating connectors or renegotiating contracts. That groundwork takes a few days, and it is the difference between a genuine cost reduction and a canceled contract that gets reinstated three months later once a retail partner’s EDI compliance team sends a noncompliance notice.

#BusinessCentral #EDIIntegration #PeppolBIS3 #ElectronicDocuments #TradingPartnerCompliance #DigitalTransformation

Business Central Digital Transformation EDI Integration Electronic Documents Peppol BIS 3 Trading Partner Compliance

Dynamic Work Classification Rules Are Now On by Default. Your Warehouse Templates Still Need a Rewrite.

Warehouse operations supervisor reviewing an automated work routing dashboard on a wall-mounted screen in a distribution center

A client I spoke with last month runs three distribution centers and had built twenty-two separate work templates just to route outbound work by carrier, shipping deadline, and pick zone. Nobody had designed it that way on purpose. It grew one exception request at a time, until the warehouse team could no longer explain why template seventeen existed or what would break if someone deleted it. Then Supply Chain Management 10.0.49 shipped in September 2026, and dynamic work classification rules, which had been sitting in feature management as a production-ready preview since June, switched on by default. Nobody flipped that switch deliberately. It just happened, and now every one of those twenty-two templates is technically obsolete even though none of them have been touched.

That is roughly the position a lot of warehouse teams are in right now, whether or not they knew this feature existed. Understanding what a Power Fx formula here can and cannot do is the difference between quietly benefiting from a real simplification and quietly breaking work assignment logic nobody remembers building.

What Dynamic Work Classification Rules Replace

The traditional approach to routing warehouse work in D365 Supply Chain Management has always been template proliferation. Every combination of conditions, say three carriers crossed with two shipping windows crossed with four pick zones, has historically meant a separate work template with its own pool assignment, priority, and location directive setup. It works, but it fails quietly: someone adds a fourth carrier, forgets to clone the templates correctly, and outbound work for that carrier silently inherits default priority instead of being expedited.

Dynamic work classification rules collapse that structure into a single work template plus a Power Fx formula that evaluates conditions at the moment work is created, and optionally again when the underlying load changes. Instead of a template per carrier, one rule with a Switch statement handles all three:

Switch(workTable.Load.CarrierCode,
    "Carrier1", {WorkPoolId: "Carrier1", DefaultWorkPriority: 100},
    "Carrier2", {WorkPoolId: "Carrier2", DefaultWorkPriority: 50},
    "Carrier3", {WorkPoolId: "Carrier3", DefaultWorkPriority: 10}
)

That single formula does the job of three templates, and when a fourth carrier gets added, it is one more line in a Switch statement rather than a cloned template someone might configure incorrectly.

Two Points Where the Formula Actually Runs

The mechanics matter here because they determine what data a rule can see. A classification rule has a scope, and the scope is either "Work" or "Work and initial work lines." A work-scoped rule runs once, after the work header itself is created, and it can only reference header-level objects: the work record, its associated load, shipment, wave, and any transportation management appointment tied to it. That is enough for the carrier and deadline examples above, because carrier code and shipping schedule live on the load.

A rule scoped to work and initial work lines runs twice: once for the initial pick line, where it has access to line-level data including the item master record, warehouse-specific item settings, and the pick zone, and again at the header level using the same objects a work-scoped rule sees. This matters when classification depends on something below the header, such as routing freezer-zone picks to a restricted work class that only certified workers can claim, which requires referencing workLine.ZoneId, a field only available at the initial-line evaluation.

Picking the wrong scope is a common early mistake. A rule written to reference workLine fields will simply fail or return blank values if it is configured with "Work" scope, because that data object was never in scope for the formula to read from.

Reading Blank and Empty String Correctly

The formula's return values control four fields on the work header: the work pool ID, a numeric default work priority, a set of location directive code overrides, and, for line-scoped rules, work class overrides. The distinction that trips up almost everyone writing their first rule is what happens when a field is omitted or explicitly cleared.

Returning Blank() for a field, or simply leaving it out of the returned record, tells the system to preserve whatever value the work template already had configured. Returning an empty string actively clears that value. These look similar on a quick read of a formula, but they produce opposite outcomes, and the difference is invisible until a load hits an edge case the formula author did not anticipate and the work pool field ends up wiped instead of defaulted. Anyone porting logic from a spreadsheet of business rules into Power Fx should treat this distinction as a required review step, not a detail to catch during testing.

Time-based priority formulas are where this feature earns its keep beyond simple carrier routing. A formula that reads a load's scheduled ship time and converts it into a same-day numeric priority, nine in the morning becoming priority 900 and three in the afternoon becoming 1500, while pushing anything scheduled for a future date to a flat low-urgency value, replaces what used to require either a batch job recalculating priorities on a schedule or a set of static templates keyed to time windows that someone had to remember to update every quarter.

The Reclassification Setting That Determines Whether This Helps or Hurts

The warehouse management parameter setup has a field called "Work classification on load update" with two practical states: disabled, meaning rules fire once at work creation and never again, and synchronous, meaning any load change, a carrier reassignment being the obvious case, triggers an immediate reclassification of every work record tied to that load before the user's screen returns.

Synchronous reclassification is correct in low-volume environments where a carrier reassignment genuinely should re-route work immediately. In a high-volume distribution center running continuous wave releases, setting this to synchronous means a single load correction by a transportation coordinator can trigger a reclassification pass across hundreds of work records in the same transaction, and that user experiences the delay directly. Time-based priority formulas compound this: if a formula depends on current time rather than a fixed schedule value, it needs recalculating on a recurring interval rather than only on load events, pushing the design toward a scheduled batch job instead of synchronous evaluation. Teams that enable this feature without deliberately choosing this setting are, by default, accepting whatever behavior comes pre-configured, which is not necessarily what their volume can tolerate.

Abstract illustration of a digital routing engine sorting warehouse work into color-coded priority lanes

Migrating Off Template Sprawl Without Guessing

The practical migration path starts with the Preview function built into the rule editor, which evaluates a candidate formula against existing work headers without committing any changes, letting a solution architect validate logic against real production data before it goes live. The Copy function on existing rules turns a working formula into a starting point for the next variation rather than requiring every rule to be written from scratch.

The one alignment check that gets skipped most often is making sure work template grouping settings match what the formula actually classifies on. A rule that assigns work class based on pick zone only makes sense if the underlying work template groups work so that each header contains lines from a single zone. If the template grouping mixes zones within one work header, a zone-based classification formula is evaluating against a header that spans multiple zones, and the result will not reflect the intent of the rule. This is a configuration mismatch, not a Power Fx defect, and it will not surface as an error, only as classification results that look wrong for reasons that are not obvious from the formula itself.

There is also no built-in mechanism for chaining multiple rules or setting rule priority across rules. Only one dynamic work classification rule can be attached to a given work template, so any scenario requiring multiple conditional layers has to be built as nested logic within a single formula rather than as a stack of separate rules evaluated in order. Teams used to unified routing's classification rulesets in Customer Service, where multiple rulesets and conditions can be layered, will find this a meaningfully different mental model, and formulas that try to replicate that layered structure will need to do it with nested If and Switch statements rather than rule ordering.

Where This Actually Pays Off

The twenty-two-template warehouse from the opening is not a rare case. Template sprawl is what happens by default in any warehouse operation that has been live for more than a couple of years and has accumulated exception handling one request at a time. Dynamic work classification does not eliminate the need to think through routing logic, but it moves that logic into a formula that a single person can read end to end, version, and test against real data before deployment, rather than a folder of templates whose relationships to each other exist only in institutional memory. Getting the scope, the Blank-versus-empty-string distinction, and the reclassification timing right the first time is what determines whether that consolidation actually reduces operational risk or just relocates it into a formula nobody has reviewed yet. Routeget's warehouse implementation work increasingly starts with exactly this kind of template audit, because the fastest way to write a good classification rule is to first understand precisely which decisions the old templates were actually encoding.

#DynamicsSCM #WarehouseManagement #PowerFx #WarehouseAutomation #SupplyChainOptimization

Dynamics SCM Power Fx Supply Chain Optimization Warehouse Automation Warehouse Management

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

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

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

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

The governance gap custom connectors created

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

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

What actually changed in Power Platform connector certification

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

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

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

What certification does, and does not, fix

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

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

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

Deciding which connectors are worth the investment

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

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

Where this fits in a broader governance plan

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

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

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

Connector Certification Copilot Studio Custom Connectors Data Loss Prevention Enterprise AI Power Platform Governance

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

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

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

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

What Copilot Studio MCP Server Authentication Actually Offers

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

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

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

Building the Delegated Flow Correctly

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

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

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

The Token Refresh Problem You Should Test Before Rollout

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

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

Governance Doesn’t Stop at the Connection

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

What This Means for the Next MCP Integration You Build

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

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

Agentic AI Copilot Studio Enterprise AI MCP Server OAuth Security Power Platform Governance

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

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

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

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

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

What the Power Apps Model App-Builder Skill Actually Generates

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

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

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

Not Every Piece of This Carries the Same Guarantee

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

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

Where the Business Case Genuinely Holds Up

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

What to Put in Place Before Turning This On Broadly

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

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

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

AI App Builder Citizen Development Enterprise AI Model Driven Apps Power Apps Power Platform Governance

Sales Research Agent Fabric Lakehouse Connections Don’t Grant Access. They Borrow Yours.

Solution architect reviewing a cloud data security and permissions dashboard on a large monitor in a modern office

A VP of sales operations at a mid-size manufacturer asks the new Sales Research Agent a simple question: “Are we tracking to quota this quarter across the East region?” The lakehouse holding quota, backlog, and actuals data has been live for months, built by the FP&A team specifically so questions like this could be answered without another spreadsheet cycle. The agent comes back with nothing useful, a vague answer built entirely from Dataverse pipeline data with no mention of quota or backlog at all. IT checks the lakehouse. The tables are there. The data is current. Nobody on the support call can explain why the agent can’t see what is plainly sitting in front of it.

The explanation, once you find it, is almost always the same: the person asking the question doesn’t have permission to the lakehouse item itself, only to the workspace it lives in, and the agent will not go around that. This is the part of a Sales Research Agent Fabric Lakehouse setup that trips up architects who have configured plenty of Power BI reports and Dataverse connections but have not internalized that this feature behaves nothing like either of those.

What a Sales Research Agent Fabric Lakehouse connection actually is

Dynamics 365 Sales’ Sales Research Agent reached general availability on April 30, 2026, after a public preview that started in mid-February, and it does something genuinely useful: it lets sales and revenue operations teams ask natural-language questions that span CRM pipeline data, finance and quota data sitting in a Microsoft Fabric lakehouse, and ad hoc files like a CSV export or a PDF board deck, all from one research canvas instead of three separate tools. The predefined insights it ships with cover attainment against quota, pipeline coverage relative to revenue goals, and variance between forecast, actuals, and invoiced results, which is exactly the kind of cross-system reconciliation that used to require a dedicated analyst and a Tuesday afternoon.

The part worth slowing down on is how the lakehouse connection is architected. It is not a data integration in the ETL sense, where an admin authorizes a service principal once and everyone downstream inherits access to a curated dataset. It is closer to a live pass-through: the agent authenticates to Fabric using the requesting user’s own Entra ID identity, via the same credentials they already use to sign into Dynamics 365. Whatever that person can see in the lakehouse through normal Fabric permissions is what the agent can see on their behalf, and nothing more. The agent never elevates privileges, and it never caches a broader view of the data than the user asking the question is entitled to.

The permission layers people forget

That single-sign-on design means two separate permission checks have to pass before a query against Fabric data will return anything at all. First, the user needs at least Viewer access at the workspace level, since Contributor and Admin also satisfy this but nothing less does. Second, and this is the one that catches people, workspace access alone does not imply access to a specific lakehouse item inside that workspace. Fabric enforces item-level permissions independently, so a user can be a workspace Viewer and still be denied at the lakehouse itself if nobody has explicitly granted them access to that item. Most Dataverse-oriented admins are used to security roles being the single gate; Fabric’s layered model means there are effectively two gates, and skipping a check on the second one is the most common reason a rollout stalls in the first week.

Abstract illustration of a digital identity key passing through a security gate to access layered data lake tables

If the lakehouse data is organized through shortcuts pointing to another OneLake location or to Azure Data Lake Storage Gen2, there is a third layer: the user also needs read access on whatever the shortcut actually targets, since Fabric will not silently grant that just because the shortcut itself is visible. And if the organization has applied row-level or column-level security through a semantic model sitting in front of the lakehouse tables, that policy is enforced automatically for every query the agent runs. A regional sales director and a national VP asking the identical question through the agent can legitimately get different, both-correct answers, filtered by whatever RLS scope already applies to their account. That is a feature, not a bug, but it needs to be explained to end users before launch, or the first person who gets a narrower answer than a colleague will assume the tool is broken.

Getting the rollout right

The practical fix is to treat the Fabric connection as an access review project before it is a feature-enablement project. Before turning this on for a sales operations team or a broader analyst group, pull the actual list of who has workspace and item-level access to the relevant lakehouse, compare it against who is expected to use the agent, and close the gap deliberately rather than reactively. It is worth testing with a genuinely representative non-admin account rather than an admin’s own credentials, since an admin will almost always have blanket access that masks exactly the permission gaps a normal seller or ops analyst will hit.

Data quality inside the lakehouse matters just as much as access does, because the agent leans heavily on table names, column headers, and any descriptive metadata attached to them to figure out what a natural-language question is actually asking for. A table named tbl_fct_rev_q3 with undocumented columns will produce worse, less trustworthy answers than one named clearly with business-friendly column labels, even though the underlying numbers are identical. Where the schema can’t be renamed because other systems depend on it, the agent supports adding plain-language business context separately, and that extra half day of documentation work consistently pays for itself in answer quality once real users start asking open-ended questions instead of the handful you tested with.

One more subtlety worth building into a QA pass: currency handling is straightforward for native Dynamics 365 Sales data, since the agent uses the environment’s base currency automatically, but for lakehouse and uploaded-file data it has to infer currency from context. For a domestic single-currency organization this is a non-issue. For anyone with multi-entity or multi-currency operations feeding that lakehouse, it is worth deliberately testing a few currency-sensitive questions before general rollout rather than discovering the inference was wrong when a regional forecast number looks off by an exchange rate.

Budgeting for consumption, not just configuration

Access to the agent itself runs through a dedicated Sales Research Agent Reader security role, which is a clean, familiar Dataverse-style control and easy to scope correctly. What is less familiar is that every question run through the agent consumes Copilot Studio credits, so a rollout to an entire sales organization without any usage guardrails or monitoring can turn into a licensing conversation nobody budgeted for, especially once people realize they can ask it anything rather than just the handful of predefined insights it ships with. Treat the credit consumption model as part of the initial deployment plan, not an afterthought discovered on next quarter’s invoice.

None of this makes the Fabric integration a bad design. A pass-through model that never elevates permissions is the right security posture for a tool that reasons across finance and CRM data simultaneously, and the alternative, a broadly privileged service account with its own access to everything, would be a much worse outcome from a governance standpoint. But the security model only works as intended when the access review happens before launch. Organizations that have gone through this rollout carefully, treating the Fabric permission audit as a real workstream rather than a footnote, are the ones whose first week of feedback is about the quality of the answers rather than a flood of tickets asking why the agent can’t see obviously available data. That is the pattern we walk clients through at Routeget when a Sales Research Agent deployment is on the table: get the access model right first, and the rest of the rollout tends to go quietly.

#SalesResearchAgent #FabricLakehouse #Dynamics365Sales #DataGovernance #CopilotStudio #EnterpriseAI

Copilot Studio Data Governance Dynamics 365 Sales Enterprise AI Fabric Lakehouse Sales Research Agent