Dataverse Plugin Packages Are Code-First Now. Your Azure DevOps Pipeline Still Has to Script Around Them.

Solutions architect and developer reviewing a Dataverse deployment pipeline diagram on an office monitor

A solutions architect on a mid-size D365 F&O implementation recently ran into a problem that had nothing to do with business logic. Her team had finally moved their plugin assemblies into proper NuGet-based Dataverse plugin packages, the newer code-first model that the Power Platform CLI now supports directly. The build worked. The package generated correctly. And then the pipeline stalled, because nobody could answer a simple question: how do you tell Azure DevOps to actually deploy the thing you just built, when Microsoft’s own build tools extension has no task for it?

That gap is worth understanding in detail, because it sits at the exact point where Dataverse plugin development is genuinely improving and where its ALM tooling has not caught up.

Solutions architect and developer reviewing a Dataverse deployment pipeline diagram on an office monitor

From Manual Registration to Code-First Packages

For most of the last decade, deploying a Dataverse plugin meant compiling a class library in Visual Studio, opening the Plugin Registration Tool, and manually selecting an assembly to register or update. It worked, but it kept plugin deployment outside the discipline that governs everything else in a mature ALM pipeline: predictable artifacts, versioned builds, and a repeatable path from commit to environment.

The Power Platform CLI changes that equation with two commands: pac plugin init, which scaffolds a plug-in class library project, and pac plugin push, which imports the resulting artifact into Dataverse. The output of a build is no longer a loose assembly file. It is a NuGet package, generated automatically in the bin\outputPackages folder on every build, containing the plugin assembly and its dependencies bundled together. That single change, treating the plugin as a proper package rather than a file you happen to compile, is what makes plugin code finally look like the rest of a modern .NET pipeline.

What Dataverse Plugin Packages Actually Solve

The practical win is dependency handling. Under the old model, any third-party or shared library your plugin referenced had to be merged into the assembly or registered separately, and both approaches created their own headaches around versioning and duplication across solutions. A plugin package bundles dependent assemblies inside the same NuGet artifact, so the whole thing deploys and updates as one unit.

Signing works differently here too, and it is worth getting the policy decision right early rather than discovering it mid-project. Microsoft’s own guidance is explicit that signing is all-or-nothing: if the primary plugin assembly is strong-name signed, every dependent assembly in the package must be signed as well. Most teams find this impractical once they start pulling in third-party libraries they do not control, which is why pac plugin init exposes a --skip-signing flag, and why it has effectively become the default choice for anyone using dependent assemblies rather than a single self-contained plugin.

The Immutability Trap

Here is where the model’s real character shows up, and where a team can get burned if nobody flags it in advance. Once a plugin package is created in Dataverse, its name and version are fixed. An attempt to change either afterward, including through the API, simply fails. Every build produces a package with a new version embedded in its filename, which means there is no such thing as “redeploy the same package again.” Each build is a new, uniquely identified artifact from Dataverse’s point of view, whether you intended that or not.

That has two consequences that matter for pipeline design. First, if a plugin update removes an assembly or a type that is still referenced by an active plugin step registration, Dataverse rejects the update outright. You have to go remove or repoint those step registrations first, then update the package, not the other way around. Second, you cannot unregister a package at all while any of its assemblies still have active step registrations attached to them. Both rules are sensible from a data-integrity standpoint, but they mean plugin retirement has to be sequenced deliberately: deregister the steps, confirm nothing else depends on the assembly, and only then remove or replace the package.

One independent practitioner account, documented on the .NET Dust blog in 2024, captured how disruptive the versioning behavior can be during ordinary iterative development, well before any pipeline is involved. Because pac plugin push has no built-in notion of “the current build,” the developer had to script around it: an MSBuild target increments the file version before compilation, a post-build event persists that value into the project file through a small helper utility, the NuGet package picks up the new version automatically, and only then does an automated pac CLI call push the exact resulting filename. What should be a single command turned into a four-step workaround, built by one engineer, to get a repeatable local deployment loop. That is a reasonable thing for an individual developer to solve on their own machine. It is not something you want reinvented independently by every team building a Dataverse ALM pipeline.

The Build Tools Gap

That last point is the one worth taking to whoever owns your ALM strategy. Microsoft’s Power Platform Build Tools extension, the standard toolkit for Dataverse pipelines in Azure DevOps and GitHub Actions, covers an extensive set of operations: importing, exporting, packing, and unpacking solutions, applying upgrades, managing environments, running the Power Platform Checker, and even a preview set of catalog-submission tasks. Reviewing the current task reference, plugin packages and pac plugin push are not among them. There is no first-class, Microsoft-supported pipeline task for deploying a plugin package, in contrast to the mature tooling that already exists for solutions.

In practice, that means every team adopting code-first plugin packages has to write its own pipeline stage: typically a script task that installs a pinned version of the PAC CLI, authenticates against the target environment (a service principal, not a personal login, for anything beyond a developer sandbox), locates the build output, and issues the push. None of that is exotic engineering. It is, however, unsupported custom scripting sitting next to a set of Microsoft-maintained tasks that get security updates, documentation, and predictable behavior across CLI versions. That asymmetry is easy to miss until a CLI update quietly changes an argument name and a script that nobody has looked at in eight months starts failing in production.

Developer typing on a laptop with a monitor showing an abstract NuGet package deployment graphic

Building This Into an ALM Pipeline Properly

A few decisions are worth making explicit rather than leaving to whichever developer happens to write the first plugin deployment script. Pin the PAC CLI version in the pipeline definition itself, not just on developer machines, so a CLI upgrade cannot silently change push behavior in production. Treat the plugin push step as its own reviewed pipeline stage with the same environment gating and approval flow as solution deployment, rather than a script someone bolted on during a sprint to unblock a release. Decide the assembly-signing policy at the team or center-of-excellence level, since the all-or-nothing signing rule effectively locks in a convention for every future package once dependent assemblies enter the picture.

Sequence retirements carefully. Before removing or consolidating an old plugin package, confirm which step registrations still point at it and clear those first, since Dataverse will otherwise block the change regardless of what your pipeline script assumes should happen. And build the versioning logic into the pipeline itself, following the pattern the .NET Dust workaround demonstrated, rather than trusting a developer’s local environment to produce a consistently versioned artifact that a shared pipeline can then find and deploy.

None of this makes the code-first plugin package model a bad idea. It is a genuine improvement over registering assemblies by hand through a desktop tool, and it brings plugin code closer to how the rest of a .NET codebase is built and shipped. The catch is that Microsoft shipped the authoring half of that story before the deployment half, and the gap between them is exactly where implementation teams are currently improvising. Firms that have already built Dataverse ALM pipelines from the ground up, Routeget Technologies among them, have generally closed that gap with a small, explicitly maintained script stage rather than an ad hoc one, which is the difference between a pipeline that survives a CLI version bump and one that quietly breaks the next time someone updates it.

#Dataverse #DataversePlugins #PowerPlatformALM #AzureDevOps #ExtensibilityAndProDev #EnterpriseArchitecture

Power Automate API Request Limits Are Losing Their Grace Period. Most Dynamics 365 Integrations Aren’t Ready.

IT solutions architect reviewing a Power Automate integration flow dashboard on a large screen in an enterprise operations center

A finance operations lead watching a month-end close dashboard notices something odd: a batch of vendor invoices has been sitting in “waiting” status for eleven minutes. No error message, no failed run in the flow history, just silence. The Power Automate flow pulling records from Dataverse and pushing them into a document management system hasn’t crashed. It has been throttled, and almost nobody on the team knows that’s a distinct condition from a broken flow, let alone what triggers it or how long it lasts.

That gap in understanding is about to matter a lot more. Microsoft has spent the better part of the last two years quietly running Power Automate’s API request limits in what it calls a transition period: real entitlements exist on paper, actual enforcement is loose, and most tenants are running well past their official limits without consequence. That period has a stated end point, tied to when Power Platform Request usage reporting in the admin center reaches general availability, plus roughly six months. Teams that built integration flows assuming today’s permissive behavior is permanent are going to have an uncomfortable conversation with their CIO when enforcement tightens.

What Actually Counts Against Your Limit

The mental model most consultants carry around, that a “request” means one API call your flow makes to an external system, undersells how quickly limits get consumed. Every action in a flow run generates a request, whether it succeeds or fails. An action sitting inside an Apply to Each loop generates one request per item processed, not one request for the loop as a whole. Pagination counts separately too, so a flow that queries a Dataverse table with 50,000 rows and pages through results in batches of 5,000 will burn ten requests just retrieving data it hasn’t done anything with yet.

This is where a lot of Dynamics 365 integration flows get into trouble without anyone noticing during development. A flow built and tested against a sandbox environment with a few hundred sales order records behaves completely differently once it hits production volume. The loop that ran fine at fifty iterations in UAT becomes five thousand iterations against the live sales order table, and each of those iterations might trigger two or three downstream actions: a lookup, a field update, a notification. What looked like a lightweight automation in testing turns into a five-figure daily request count in production.

Developer typing on a laptop with a blurred Power Automate cloud flow diagram visible on a monitor in the background

The Power Automate API Request Limits That Actually Matter

Most teams that have heard of Power Automate throttling think of it as a single ceiling. In practice there are three separate mechanisms stacked on top of each other, and hitting any one of them produces the same frustrating symptom: a flow that stops making forward progress without a clear error.

The first is the 24-hour rolling entitlement, calculated per user for licensed accounts and pooled at the tenant level for application users and service accounts. A user with a standard Power Automate per-user or Dynamics 365 base license carries a 40,000 request allowance in any trailing 24-hour window. That window doesn’t reset at midnight. It slides continuously, so a burst of activity at 9 a.m. today is still being counted against the limit at 9 a.m. tomorrow, and any requests left unused simply expire rather than carrying forward.

The second is a five-minute burst cap of 100,000 requests, which applies independently of how much daily entitlement remains. A flow with a per-flow Process license carrying 250,000 requests per day can still get throttled mid-run if it tries to push too many of those requests through in a short burst, which is exactly what happens when an integration flow processes a large batch without pacing itself.

The third, and the one with the sharpest teeth, is continuous throttling over time. A flow that stays in a throttled state for 14 consecutive days gets turned off automatically. It can be reactivated, but if the underlying request pattern hasn’t changed, it cycles back into the same state. For a scheduled integration that runs nightly, two weeks of silent throttling is enough time for a genuinely broken process to look, from the outside, like nothing more than a slow week.

Architecting Integrations to Survive Enforcement

None of this means Power Automate is a poor choice for high-volume Dynamics 365 integration work. It means the flows need to be built with request budgets in mind from the start rather than retrofitted after a production incident.

Batching is the highest-leverage change available to most teams. Dataverse supports native batch operations that bundle multiple create, update, or delete operations into a single request rather than issuing one request per record. A flow rewritten to batch 100 record updates into a handful of batch calls instead of 100 individual actions can cut its request footprint by well over ninety percent for that segment of the process. This is worth doing even on flows that aren’t currently near any limit, because the same restructuring also improves run time and reduces the blast radius of a partial failure.

Child flows deserve more architectural attention than they usually get. Breaking a single monolithic flow into a parent that orchestrates and several children that each handle a bounded chunk of work makes it possible to apply concurrency control and pacing at a granular level, rather than trying to throttle an entire end-to-end process as one unit. Concurrency control settings on the trigger, often left at their defaults, are one of the more overlooked levers here: capping how many instances of a flow can run in parallel directly controls how fast it can burn through the five-minute burst allowance.

Trigger conditions matter more than most teams treat them. A flow that fires on every Dataverse row update and then checks conditions inside the flow body has already consumed a trigger execution and started accumulating requests before it decides the record doesn’t actually need processing. Moving that filtering logic into the trigger condition itself, evaluated before the flow run even starts, is free request savings that costs nothing to implement.

For flows that are genuinely high-volume by design, such as a real-time integration syncing order status between D365 Finance and Operations and an external logistics platform, the right answer may simply be licensing rather than architecture. A per-flow Process license carries a 250,000 request daily allowance on its own, and multiple Process licenses can be stacked on a single flow inside a solution, each one adding another 250,000 to that flow’s dedicated entitlement. For tenants not ready to change licensing, the Power Platform Request Capacity add-on adds 50,000 requests per 24 hours per pack and can be layered onto existing entitlements as a stopgap.

Get Ahead of the Reporting Gap

The Power Platform admin center’s usage reports are still catching up to the complexity of the limits themselves. Current reporting covers Power Automate API requests reasonably well but doesn’t yet give a clean picture of Dataverse, Copilot Studio, or Power Apps consumption in the same view, which means a team relying solely on the admin center dashboard is working from an incomplete picture of its actual request footprint. Until that reporting matures, the more reliable approach is instrumenting flows directly: logging request counts per run, watching for 429 responses in run history, and treating a spike in run duration as an early warning sign rather than waiting for a flow to get switched off.

Organizations we’ve worked with on Dynamics 365 and Power Platform integration architecture are increasingly building request budgeting into the design review for any flow expected to process more than a few thousand records a day, the same way they’d review a database query plan before it goes to production. That habit is worth adopting now, while the transition period still offers room to fix a poorly architected flow before enforcement makes the fix urgent instead of optional.

#PowerAutomate #APIRequestLimits #DynamicsIntegration #PowerPlatformGovernance #IntegrationArchitecture #EnterpriseAutomation

Business Central Expense Management Reaches GA in October. The License-Free Path Isn’t Actually Free.

Finance director reviewing an expense report approval dashboard in a modern office

If your Concur or Expensify renewal is sitting in front of your CFO this quarter, the timing is inconvenient. Microsoft is about to ship native Business Central expense management, a module inside Dynamics 365 Business Central that had been dismissed by practitioners as a minor, checkbox-only feature when it first appeared on the 2026 release wave 1 plan back in April. It no longer looks minor. Between the original release plan entry and the general availability date now set for October 2026, Microsoft quietly attached an AI-driven Expense Agent to the module that covers most of the ground people assumed only a dedicated T&E platform could handle: receipt scanning, mobile capture, email submission, mileage calculation, and policy compliance checks that flag violations before an expense report ever reaches a manager. For an IT Director or finance leader weighing whether to sign another year of a third-party contract, that changes the question from “does Business Central do expenses now” to “is it ready enough to consolidate onto, and what will it actually cost.”

Finance director reviewing an expense report approval dashboard in a modern office

What changed since Business Central expense management was first announced

When Business Central’s expense reports feature first showed up on the release plan, at least one well-known practitioner in the ecosystem publicly predicted it would fall flat. His reasoning was straightforward: without receipt capture, mobile submission, or corporate card integration, a native module was never going to pull organizations away from Concur or Expensify, tools built around exactly those capabilities. That skepticism was reasonable at the time, because the initial description of the feature read like a manual, form-based expense report tool bolted onto the general ledger.

What shipped alongside it in preview is a different story. The Expense Agent, which Microsoft documents as a production-ready preview feature, performs the parts of the workflow that used to require a third-party app: it reads a receipt image or PDF, extracts merchant, amount, date, and category, calculates mileage reimbursement against a configured company rate, and groups related expenses into a report automatically. Submission works through a dedicated web app, a mobile app with camera capture and offline support, direct email to an organization’s expense mailbox, or a Copilot chat interface inside Microsoft Teams. None of that requires opening Business Central at all. What Microsoft’s current documentation does not describe, at least not yet, is automatic reconciliation against corporate card statement feeds, a feature dedicated expense platforms have offered for a decade and that larger organizations in particular tend to depend on. That gap is worth watching, not dismissing; it may simply not have been documented yet ahead of GA.

The workflow, and who actually needs a Business Central license

The module organizes expenses through a status flow that will look familiar to anyone who has used a modern expense tool: Open, Pending Approval, Released, Approved, Rejected, Processed for Payment, and Completed. An employee can enter mileage, add participants to a shared expense, itemize a single receipt into multiple categories, or split a hotel bill into refundable and non-refundable lines when part of it (the minibar, say) falls outside policy. A manager reviews and approves or rejects from within that same flow, and an accountant posts approved reports to generate Expense Ledger Entries and drive reimbursement, with posting accounts controlled through Expense Categories and Expense Posting Groups an administrator sets up in advance.

Employee capturing a paper receipt with a smartphone for expense report submission

The detail that deserves the most attention from a finance leader is licensing, because it does not follow the pattern most Business Central features do. An employee who only submits expenses, whether through the web app, email, or the Copilot chat interface, does not need a Business Central license at all. That sounds like a straightforward cost win until you read the next line: that access method draws on Copilot Credits instead. Anyone who needs to open Business Central itself to manage or approve reports needs at minimum a Team Member license, and posting the reports and processing payment requires Essentials or Premium. So the module has effectively three separate cost levers rather than one: a consumption-based charge for expense-only submitters routed through Copilot Credits, a per-user subscription cost for anyone touching the module inside Business Central proper, and the underlying Essentials or Premium tier required to post anything at all. None of that is disclosed as a flat number in Microsoft’s documentation, which does not publish a specific Copilot Credit consumption rate for expense processing the way it has for some AI Builder scenarios.

Why that licensing structure matters more than the feature list

A CFO comparing this against a Concur or Expensify renewal is not just comparing feature checklists. They are comparing a predictable per-seat SaaS cost against a hybrid model where the cost of casual expense submitters scales with Copilot Credit consumption, a metric most finance teams have no historical baseline for. An organization with 40 people who occasionally submit an expense report and five people in finance who approve and post them will have a very different cost profile than one with 400 field employees submitting receipts weekly through the mobile app, even though both fit inside the same license categories. Before treating this as a straight replacement decision, it is worth actually modeling that consumption, not estimating it, because Copilot Credits behave differently from a fixed per-user fee and can move with usage in ways a traditional T&E contract does not.

There is also a timing consideration that is easy to overlook. As of this writing, the module and its Expense Agent are still labeled a production-ready preview, meaning Microsoft considers it stable enough to run in production but reserves the right to change it, and it operates under supplemental preview terms of use rather than Business Central’s standard product terms. October 2026 is the stated general availability date, but Microsoft’s own release plan documentation carries the standard disclaimer that projected functionality and delivery timelines may change. Organizations with a Concur or Expensify contract expiring in the next renewal cycle should treat October as a target to validate against, not a date to build a migration plan around before it actually happens.

What to do before the next contract renewal

The practical path for a finance or IT leader facing this decision now is a short, deliberate evaluation rather than an early commitment in either direction. Set up the module in a sandbox environment, route a real slice of a month’s expense volume through the Expense Agent’s mobile and email submission paths, and track how many receipts require manual correction after the AI extraction step, since the documentation itself notes that users should expect to review and correct results rather than trust them blindly. In parallel, ask your Business Central partner or internal admin to estimate Copilot Credit consumption against your actual expense submission volume, not a generic average, since that number is the one piece of this decision Microsoft has left for each organization to work out on its own. If your current Concur or Expensify agreement has a shorter renewal term available, or a month-to-month bridge option, that flexibility is worth paying for this cycle specifically so the decision isn’t forced before GA lands and the Copilot Credit math has a real quarter of data behind it.

None of this means the module isn’t a legitimate option. For organizations with straightforward expense policies, modest transaction volume, and no dependency on corporate card feed reconciliation, native Expense Management removes a genuine integration cost and keeps expense data inside the same ledger as everything else. Routeget Technologies has walked several Business Central clients through exactly this kind of licensing and consumption modeling ahead of a platform consolidation decision, and the pattern holds: the module’s capability gap has closed faster than the ecosystem expected, but the cost model needs its own diligence before it replaces a contract that already works.

#BusinessCentral #ExpenseManagement #ERPLicensing #CopilotCredits #FinanceTransformation #SMBERP #DynamicsBusinessCentral

Case Management Agent Shadow Mode Won’t Save You From the Credit Bill

Customer service operations analyst reviewing AI case prediction dashboards

A Dynamics 365 Customer Service admin at a mid-size insurer recently asked a reasonable question in a planning meeting: if Case Management Agent can draft responses and reclassify inbound support email on its own, why not just turn it on for one team and watch what happens? The answer, as it usually is with autonomous case handling, is that “watching what happens” after the agent has already sent a reply or changed a case status is not watching, it’s cleanup. Case Management Agent shadow mode exists specifically to close that gap, and it reached general availability in May 2026. What it does not do is make that validation free, and the fine print around it is messier than the release notes suggest.

Shadow mode lets a case update rule generate everything Case Management Agent would normally act on: the identified customer intent, a drafted response, proposed field updates, and a recommended resolution path, without sending a single email or writing a single change to a live case. Administrators and CSR managers get a dedicated shadow results view where they can open a case, see what the agent would have done, and compare it against what a human agent actually did. That comparison is the entire point: it turns “we think the AI is ready” into a defensible, case-by-case answer before anyone flips the switch on autonomous handling for a whole queue.

Customer service operations analyst reviewing AI case prediction dashboards

What Case Management Agent Shadow Mode Actually Validates

The mechanics matter more than the marketing description. Shadow mode is enabled per case update rule, not per agent, per queue, or per line of business. On the Case creation and update page, under Case update by AI agent (any channel), you select an individual rule and choose Shadow mode from the toolbar; the rule’s status changes accordingly. That granularity is a feature and a trap in the same breath. It means you can pilot the agent’s behavior on a narrow slice of traffic, say, billing inquiries routed through one specific rule, without touching anything else. It also means that if your case management setup has a dozen rules covering different email types, languages, or business units, validating the agent properly means walking through each rule on its own rather than assuming one clean test covers the whole configuration.

Once a rule is running in shadow mode, reviewers pull up results through Review shadow runs, which surfaces old and new values side by side, grouped by case, with each case expandable to show every shadow response tied to it. For a technical team, this is genuinely useful data: you can see not just whether the agent’s classification matched reality, but whether its drafted response tone, its proposed field updates, and its resolution recommendation would have held up. That level of visibility is a meaningfully higher bar than most organizations apply before turning on any AI-driven automation, and it’s worth using deliberately rather than as a two-day formality before go-live.

The Cost Nobody Budgets For

Here is the detail that gets lost between the release plan bullet point and the actual rollout plan: shadow mode consumes Copilot or AI credits in exactly the same way live predictions do. Running a rule in shadow mode for three weeks across a meaningful volume of cases is not a free dry run, it is a second production workload layered on top of whatever else is drawing from the same consumption pool. Teams that budgeted AI credits for the automation itself, and treated validation as a rounding error, are the ones who get an uncomfortable surprise on the Azure bill partway through a pilot.

There’s a licensing prerequisite tied to this that’s easy to miss during a proof of concept. Shadow mode, like the broader autonomous case agent framework it belongs to, requires the Power Platform pay-as-you-go plan with Azure subscription consumption-based billing already configured. If your organization is running Dynamics 365 Customer Service on a standard licensing model without PAYG enabled, shadow mode is not a checkbox you flip in an afternoon. It’s a procurement and finance conversation that needs to happen before the technical team can even start the guided setup for Case Management Agent, which is itself a prerequisite for shadow mode to appear as an option at all.

Technology professional reviewing side-by-side data validation comparison on screen

A GA Feature Microsoft’s Own Documentation Still Calls Preview

This is the part worth flagging directly rather than glossing over. The 2025 release wave 2 plan lists shadow mode’s general availability date as May 2026, and it has been publicly available since then. But the current administrator documentation for enabling it states plainly that shadow mode “is a preview feature and isn’t meant to be used in production environments,” and ties usage to Microsoft’s supplemental terms of use for preview features rather than standard product terms. That is not a minor wording inconsistency. For a regulated organization (an insurer, a bank, a healthcare provider) the difference between a GA feature and a preview feature governs what a compliance or vendor-risk team will actually sign off on, and which support commitments apply if something goes wrong.

There are two ways to read this gap. One is that Microsoft’s release-plan GA date refers to the feature’s availability in the product, while the standing administrator guidance simply hasn’t been updated to match, which would not be the first time a fast-moving Copilot feature outpaced its own documentation. The other is that shadow mode genuinely still carries preview-level support and terms regardless of what the release plan says, and the GA label refers only to it no longer requiring a preview opt-in toggle. Neither interpretation is confirmed by anything Microsoft has published, and a team relying on shadow mode’s output to justify a production automation decision should treat that ambiguity as a real governance question, not a documentation typo to shrug off.

Pairing Shadow Mode With the New Classification Features

Shadow mode is most useful right now paired with the classification capabilities Microsoft shipped alongside it. Email classification into administrator-defined categories reached general availability on April 10, 2026, letting Case Management Agent tag inbound email based on subject and body content before anything downstream (unified routing, Automatic Record Creation rules, Power Automate flows, or reporting) ever touches it. That expanded into a full taxonomy of categories and subcategories on August 21, 2026, giving organizations a hierarchical structure instead of a flat list.

The practical implementation sequence follows from how much of the platform now depends on that category value. Because routing rules, ARC logic, and reporting all key off the classification attribute, a wrong category assignment doesn’t just mislabel one email, it can misroute a case, trigger the wrong automation, or quietly skew the metrics a supervisor is using to staff a queue. Running the classification rule in shadow mode first, and specifically checking whether the predicted category and subcategory match what a human agent would have assigned, is a more honest test of readiness than checking whether the agent’s drafted response reads well. A well-written response built on a wrong classification is still a routing failure waiting to happen.

What to Check Before You Rely on This

Before treating shadow mode results as sufficient sign-off, confirm three things. First, that the security role doing the review actually has CSR Manager or Customer Service Representative access, since the shadow results view isn’t exposed to every role by default. Second, that the guided setup for Case Management Agent has been completed correctly upstream, because shadow mode inherits whatever intent recognition and field-update logic that setup produced; a poorly configured agent will look exactly as unreliable in shadow mode as it would in production, which is the point, but only if the setup itself was done right. Third, that whoever owns the Azure consumption budget knows shadow mode is running and for how long, since a validation period with no defined end date is how credit consumption quietly becomes a permanent line item instead of a bounded pilot cost.

None of this argues against using shadow mode. It’s a genuinely better validation mechanism than most organizations had access to a year ago, and comparing predicted actions against real agent behavior on live cases is a far more honest test than a sandbox demo with curated examples. The point is that GA here does not mean settled. It means the feature works as described, the cost model is real rather than theoretical, and the documentation hasn’t caught up to tell you clearly which rules apply. Teams that have gone through a Dynamics 365 Customer Service rollout before recognize this pattern: the technical capability usually arrives before the governance conversation around it is finished, and treating the two as separate workstreams from the start avoids finding out the hard way which one was actually the bottleneck. This is the kind of gap Routeget Technologies typically catches during a pre-rollout technical review, before a client’s compliance team finds it first.

#CaseManagementAgent #DynamicsCustomerService #ServiceModules #AIGovernance #CopilotCredits #EnterpriseAI

Same-Batch Enforcement Arrives in Dynamics 365 Production. It Doesn’t Close the Compliance Gap Alone.

Quality assurance manager reviewing a batch record on a tablet on a regulated manufacturing production line

A quality director at a mid-size nutraceutical manufacturer got a call last spring that no one wants to take: an FDA investigator, working through a customer complaint, asked for the full batch genealogy on three months of production runs. The paperwork technically existed, but tracing which raw material lots had actually gone into which finished-goods batches meant cross-referencing warehouse pick lists against production order consumption records by hand, because nothing in the ERP had stopped a warehouse worker from grabbing a partial pallet from one lot and topping it off from another when the first one ran short. That gap, mixed-batch consumption slipping past the system simply because nothing technically prevented it, is exactly what Microsoft’s new same-batch enforcement capability in Dynamics 365 Supply Chain Management was built to close. It reached general availability on September 11, 2026, as part of the 10.0.49 release, and for manufacturers operating under FDA, cGMP, or ISO quality regimes, it deserves more than a passing glance. What it actually enforces, what it still leaves to manual process, and what needs to happen internally before a CFO or quality VP approves flipping the switch are three separate questions, and they don’t all have the same answer.

How Same-Batch Enforcement Actually Works

The mechanics are narrower, and more deliberate, than the feature name suggests. Product designers and production engineers set a same-batch requirement at the released-product level, which becomes the default wherever that item shows up in a bill of materials or formula. From there, individual BOM or formula lines can override that default where a different rule genuinely applies, since not every raw material in a recipe needs the same level of control. Once that configuration is in place, the enforcement itself happens at the point production planners and warehouse staff reserve raw materials for a production order or batch order: the system restricts the available on-hand inventory to a single batch per line, rather than letting someone pull partial quantities from two or three lots to fill one requirement. Both discrete manufacturing (production orders) and process manufacturing (batch orders) are covered, which matters because a lot of regulated manufacturers run a mix of both on the same instance.

It’s worth noting the feature spent two months in public preview, from July 2026, before reaching GA in September. And “generally available” here means available through feature management, not switched on for every customer automatically. An admin, maker, or analyst still has to decide to turn it on and configure which products it applies to, which is a meaningfully different rollout posture than a change that just appears in everyone’s environment overnight.

Why This Lands Squarely on Regulated Manufacturers’ Radar

This isn’t an isolated feature. It arrived in the same 10.0.49 release where Advanced Quality Management, the suite Microsoft has been building out since version 10.0.44, became mandatory, permanent functionality rather than an optional module manufacturers could choose to skip. Advanced Quality Management is aimed squarely at pharmaceutical, food and beverage, and chemical producers operating under FDA Quality System Regulation, 21 CFR Part 11 electronic-signature requirements, current Good Manufacturing Practice, and ISO frameworks. It brings electronic batch records, corrective and preventive action tracking with e-signature closure, approved customer lists for controlling who can receive specific lots, and flexible sampling plans for quality inspection, all things an FDA or ISO auditor will ask to see evidence of during an inspection.

Same-batch enforcement fits into that picture as the piece that governs actual physical consumption rather than paperwork. An electronic batch record can faithfully document what a work order was supposed to consume, but until now, nothing stopped the gap between the documented plan and what a warehouse worker actually picked when inventory ran short mid-shift. For a CFO or operations leader, the value isn’t abstract: fewer hours spent reconstructing batch genealogy by hand during an audit or a recall investigation, and a materially lower chance that an inspector finds a discrepancy between what the system says was consumed and what physically was. Recall investigations in particular tend to be measured in days of staff time when traceability records are clean, and considerably longer when they aren’t.

What the Toggle Doesn’t Cover Yet

Here’s where the caution belongs. Microsoft’s own release documentation lists two related capabilities explicitly as future work, not part of this release: same-batch enforcement during master planning allocation, and execution validation during picking and consumption. In plain terms, that means the planning engine can still generate a supply plan today that would require splitting a raw material requirement across multiple batches, since the rule governs reservation and picking behavior rather than the planning proposal itself. It also means there’s no described hard validation step at the moment of physical pick or consumption confirmation that would catch a batch mismatch if one somehow occurred despite the reservation restriction.

None of that makes the feature not worth adopting. It does mean it should be positioned internally as one control layer added to an existing set of controls, not a replacement for the standard operating procedures, warehouse management system discipline, and internal audit sampling a regulated manufacturer already relies on. A quality team that tells its auditors “the system enforces single-batch consumption” without the caveat about planning and execution-time gaps is setting up a conversation nobody wants to have during the next inspection. The honest version of that sentence is that the system now prevents a specific, common failure mode at the reservation step, and the rest of the control environment still has to do its job.

Warehouse worker scanning a raw material batch tracking tag before reservation for a production order

What to Check Before Turning It On

A few decisions are worth working through with production and quality leadership before enabling this in a live environment, rather than leaving it as a configuration exercise for IT alone. First, the product-level default needs input from people who actually understand which raw materials carry regulatory or process risk if mixed, versus commodity inputs where enforcing single-batch picking would just add friction on the floor without a corresponding quality benefit; applying the rule everywhere by default tends to generate exactly that kind of resistance. Second, sandbox testing should specifically include the awkward cases: what happens during reservation when a single batch doesn’t have enough on-hand quantity to cover the full requirement, since Microsoft’s documentation doesn’t spell out whether that blocks the transaction outright or offers a supervised override, and that behavior will shape how disruptive the rollout feels to planners in the first few weeks.

Third, this is a change warehouse and production staff will notice immediately, since it directly limits what they can select during reservation, so it belongs on a floor communication plan before go-live rather than showing up as a surprise restriction mid-shift. Finally, quality SOPs and internal audit checklists should be updated to describe precisely where system enforcement starts and stops, so nobody overstates the control’s scope to an external auditor months from now and has to walk it back.

Same-batch enforcement is a genuinely useful, narrowly scoped addition that closes a real and specific traceability gap, arriving at a moment when Microsoft has made the broader quality management suite around it mandatory rather than optional. Its actual value to a regulated manufacturer, though, depends less on the toggle itself and more on how deliberately it gets rolled into an existing quality program. In our own implementation work with manufacturers running Dynamics 365 under FDA and ISO oversight, the configuration decisions are rarely the hard part; getting the product-level rules, the floor process changes, and the audit documentation aligned before go-live consistently is. A control that isn’t paired with the right procedure change on the ground doesn’t close the gap it was built for, it just moves where the gap sits.

#DynamicsSCM #BatchTraceability #QualityCompliance #ManufacturingCompliance #RegulatedManufacturing #SupplyChainGovernance

Power Automate’s Desktop Flow Version Control Reached GA. It Isn’t the Git Workflow You Expected.

Solution architect reviewing a workflow version comparison on a monitor in a modern office

Last quarter, a client’s unattended invoice-processing bot broke in production after a maker “fixed” a selector on a Friday afternoon and republished without telling anyone. There was no way to see what had changed, no way to diff the working version against the broken one, and no way to roll back except by rebuilding the flow from a screenshot someone had taken three weeks earlier. That is not a hypothetical: it is the normal operating condition for most Power Automate desktop flow estates, and it is the exact gap Microsoft’s new desktop flow version control feature was built to close.

Desktop flow version control reached general availability on May 13, 2026, alongside a companion capability, compare flow versions, released the same day. A related feature, test subflows with test suite, followed in June 2026. Together they represent the most significant governance shift Power Automate for desktop has had since unattended runs first shipped, and for solution architects who have spent years explaining to security and change-management teams why their RPA estate has none of the source-control discipline their .NET or Java pipelines take for granted, this is worth understanding in detail, not just filing away as a changelog entry.

What Desktop Flow Version Control Actually Shipped, and What It Isn’t

The instinct when you hear “version control for desktop flows” is to picture Git: branches, merges, pull requests, a commit graph. That is not what Microsoft built, and treating it as a Git replacement will set you up for a bad rollout conversation with your development team. The underlying storage is Dataverse, not a distributed version-control system. Every draft and published version of a desktop flow is stored there in a compressed format, and Microsoft’s documentation is explicit that there is no configurable cap on how many versions accumulate, though versions older than twelve months are automatically purged, with the exception of the latest published version, which is retained indefinitely.

The model itself is linear rather than branching. A maker saves incremental changes as a draft, which has no effect on whatever is currently running in production. When the maker is satisfied, they publish, which creates an official version available for execution from the console or from a triggering cloud flow. Publish is deliberately disabled until the flow contains at least one enabled action, a small guardrail against accidentally shipping an empty shell. Every prior published version remains accessible as a read-only, previously-published entry, and a maker can restore any of those older versions, which pulls it back in as the current draft rather than silently reinstating it as production. That distinction matters operationally: restoring a version is a deliberate, two-step act, not a one-click rollback that could be triggered by accident.

There is no merge conflict resolution because there is no merging. If two makers edit the same flow concurrently, Microsoft’s guidance is essentially to coordinate manually and avoid overlapping edits, which is a meaningfully different discipline than what a development team accustomed to feature branches will expect. If your organization runs a centralized Center of Excellence model where a small number of makers own each flow, this limitation is mostly academic. If you have distributed ownership across multiple business units touching shared subflows, it is a real constraint you need to design around before you tell anyone this “solves” your governance problem.

Compare Flow Versions: What the Diff Actually Shows

The comparison tool is where this feature starts to feel like genuine engineering tooling rather than a glorified undo button. Selecting any two saved versions opens a read-only comparison view, with the designer locked from editing while the comparison window is open, and the most recent version by timestamp used as the reference baseline. The right-hand pane acts as a change filter: clicking an entry highlights the corresponding element directly in the flow canvas, so you are not scrolling through the whole flow trying to spot what moved.

The scope of what gets diffed is broader than a simple action-by-action list. It surfaces added, removed, and renamed subflows; changes to action configuration and parameters; variable type, name, and value changes; updates to UI element selectors, which is precisely the category of change that silently breaks unattended runs most often; and additions or removals of image assets used for image-based automation. For a team that has ever spent an afternoon trying to figure out why a previously stable flow started failing, having selector changes surface explicitly in a diff view is arguably the single most practically useful part of this release, more so than version control’s headline framing suggests.

Abstract illustration of workflow nodes with a version comparison branch and a passed test checkmark

Subflow-Level Testing Closes a Real Gap

Before this release, testing a Power Automate desktop flow meant running the entire parent flow end to end, because there was no supported way to validate a subflow’s logic in isolation. That forced teams into a familiar bad pattern: either skip meaningful pre-deployment testing because a full run is slow and environment-dependent, or build brittle manual test scripts outside the platform entirely. Test subflows with test suite, which reached general availability in June 2026, extends the existing desktop-flow test framework down to the subflow level, using the same behavior-driven-development structure, defined inputs, expected outputs, and assertions, that the parent-flow test suite already used.

This is not glamorous, but it is the piece that actually makes version control operationally useful rather than just a historical record. A version history without a way to verify that a candidate version behaves correctly before you publish it is an audit trail, not a quality gate. With subflow-level tests, a maker can validate the specific piece of logic they changed, independent of the surrounding flow, and get a pass or fail result recorded in the console and designer before that version ever reaches an unattended runtime. Combined with the comparison tool, you now have a workflow that resembles, even if it doesn’t literally replicate, a real pre-merge review: see exactly what changed, run a targeted test against the changed logic, then publish deliberately.

The Caveats That Change Your Rollout Plan

A handful of details in Microsoft’s documentation will change how you deploy this, and skipping them is how a promising governance feature turns into a support ticket. Self-healing, the capability that lets a desktop flow automatically repair a broken UI selector at runtime, is disabled whenever a flow is running from a saved draft rather than a published version. If your team gets in the habit of testing directly against drafts in a production-adjacent environment, understand that you have also quietly turned off a reliability feature you may be depending on elsewhere.

Enabling the feature requires the prvReadcomponentchangesetpayload privilege, which is included by default for the Environment Maker role but must be added explicitly to any custom security role your organization uses for minimum-permission configurations, a step that is easy to miss if your RPA governance model already deviates from Microsoft’s defaults. Import conflicts are another real-world snag: importing a published flow into an environment that already has an unpublished draft throws an error about an unmodified active context with an existing unpublished row, and the fix is to delete the pending draft before the import runs, which has implications for how you structure ALM pipelines that move flows between dev, test, and production environments. Finally, once version control is turned on for an environment, it cannot be turned off, which argues for enabling it first in a genuinely lower, disposable sandbox rather than directly in whatever environment your team currently treats as “dev.”

What This Means for How You Structure RPA Delivery

None of this makes desktop flow governance equivalent to modern application development practice, and it shouldn’t be sold to a client or an internal stakeholder that way. But it does close the two gaps that have made RPA estates genuinely hard to govern at scale: an unauditable history of what changed and when, and no supported way to test a piece of logic before it reaches an unattended machine. Teams that adopt both capabilities together, disciplined draft-and-publish habits paired with subflow tests run before every publish, will get a meaningfully more defensible answer the next time an auditor or a CISO asks how changes to an automation that touches financial or customer data actually get reviewed. Teams that enable version control and stop there, treating it as a rollback insurance policy rather than a discipline, will find it useful during an incident and largely irrelevant the rest of the time.

Routeget Technologies has been building governance frameworks around Power Automate and Power Platform estates for clients moving from pilot-stage RPA into production-scale automation, and the pattern above, comparison-driven review paired with subflow testing before publish, is close to what we now recommend as a baseline practice rather than an aspirational one. The tooling finally supports it; the discipline still has to be built deliberately.

#PowerAutomate #DesktopFlows #RPAGovernance #ALM #ProcessAutomation #EnterpriseAutomation

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

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

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

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

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

What Actually Changed

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

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

The Power Pages Authentication Provider Choice, in Practice

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

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

The Gap Nobody’s Migration Deck Mentions

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

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

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

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

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

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

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

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

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

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

Business Central’s OData Deprecation Is the Deadline That Actually Matters

Solution architect reviewing integration and API connection status on a monitor, representing Business Central OData migration planning

Every Business Central partner with a client list has spent the last few months triaging one deadline: SOAP web services on Microsoft-authored pages stop working the moment version 29.0 goes generally available on October 1, 2026. It’s a real cutoff, it’s close, and it deserves the attention it’s getting. But teams that treat that project as the finish line are missing the bigger one sitting six months behind it. Business Central’s OData deprecation for Microsoft UI pages lands with version 30.0, the 2027 release wave 1 release scheduled for the first workday of April 2027, and it is going to break far more integrations than SOAP ever did, because OData has been the default, path-of-least-resistance protocol for Business Central reporting since NAV migrated to the cloud.

Here’s the scenario that shows up in almost every environment once you actually go looking: a controller built an Excel workbook years ago that pulls G/L entries through an OData feed on a standard Microsoft page. Nobody remembers who set it up. It isn’t in the integration inventory because nobody classified a spreadsheet as an integration. A Power BI dataset does the same thing against the Customer or Item Ledger Entry pages, refreshing nightly through a service account that predates the current IT team. None of this shows up when you audit “our integrations,” because the people who’d know to look for it moved on, and the connections themselves were never registered anywhere except a connection string buried in a Power Query step. SOAP, by contrast, was mostly used by a smaller set of legacy middleware tools that companies have already been migrating off for years because SOAP has felt dated since well before Microsoft announced its removal. OData never felt dated. It’s still the protocol Microsoft’s own documentation recommends for ad hoc reporting scenarios, right up until version 30 removes the ability to expose a Microsoft-authored page through it at all.

Solution architect reviewing integration and API connection status on a monitor, representing Business Central OData migration planning

What Business Central’s OData deprecation actually removes

The scope here matters, because it’s narrower than the headlines suggest and that narrowness is exactly what makes it easy to underestimate. Starting in version 30, Business Central will no longer allow a page published by a Microsoft-authored app, meaning the Base Application, System Application, or any other first-party extension, to be exposed as an OData endpoint. Custom pages you or a partner built in your own AL extension are unaffected. Standard API pages and API queries, which already use a different endpoint structure under /api/v2.0/, are unaffected. What goes away is specifically OData access to the UI pages Microsoft ships out of the box: the Customer Card, the Chart of Accounts, the Sales Order list, and every other page that a reporting tool or Excel workbook has been happily pointing at for a decade.

Microsoft’s stated rationale is worth understanding because it explains why there’s no reprieve coming. A UI page isn’t governed by the same change-management discipline as an API. Microsoft can add a field, reorder a FastTab, or rename a control on a standard page in a minor update without that counting as a breaking change to the platform, but if your OData integration depends on that page’s exact shape, the same update breaks your feed. Microsoft has effectively decided it can no longer support that implicit contract at scale, and the SOAP removal in version 29 was the first half of enforcing that decision. Version 30 finishes it for OData.

Finding what you don’t know is there

Before any migration plan makes sense, you need an honest inventory, and guessing from documentation or asking the client “what connects to BC” will undercount every time. Business Central’s telemetry to Application Insights already logs this if you have it wired up. Web service requests are recorded under event ID RT0008, and the category custom dimension on that event records whether each call came in as API, ODataV4, ODataV3, or SOAP. Paired with the alObjectName and endpoint dimensions, a straightforward Kusto query against your Application Insights workspace, filtering customDimensions.eventId == "RT0008" and grouping by category and object name, will produce a real list of which Microsoft pages are being called through OData, how often, and from what client. Run that query across a full month rather than a day or two; monthly reports and quarter-end reconciliation jobs won’t show up in a short window, and those are exactly the integrations most likely to have been forgotten.

Abstract illustration of a legacy data connection node fading out as a new API connection node forms, representing migration from OData to API v2.0

Triaging what the audit finds

Once you have the list, not every entry needs the same fix, and treating them uniformly wastes effort on the easy ones while under-resourcing the hard ones. Some OData calls map directly onto an existing standard API entity: Customer, Vendor, Item, and Sales Order OData feeds usually have a clean equivalent already published under API v2.0, and switching the connection string plus adjusting field names is genuinely a low-effort change. Others don’t have a standard API match because they’re pulling something specific, like a custom-shaped join across ledger entries and dimensions that a spreadsheet author built by hand in Power Query. For those, an AL query object is usually the right tool rather than trying to force a page-based API to do the work. Query objects are read-only, they can join across multiple tables the way the old OData feed effectively did through Power Query, and they publish as their own API endpoint with proper OData-style $filter and $select support, without exposing a Microsoft UI page at all. A third category is the genuinely awkward one: integrations built around unbound actions on standard pages, which as of now have no direct equivalent in the REST API surface. Microsoft hasn’t closed this gap yet, so the practical workaround is either wrapping the needed logic in a bound action on a custom API page you control, or moving that piece of orchestration out of Business Central entirely into an Azure Function or a Logic Apps flow that calls the standard API for the parts it can and handles the rest itself.

The option nobody should default to, but should know exists

If a specific OData integration truly cannot be replatformed before April 2027, Microsoft’s own guidance leaves one path open: copy the source code of the standard page into your own extension and publish that copy as the OData endpoint instead. This works because the restriction is specifically on pages published by a Microsoft-authored app, not on OData as a protocol. It should be treated as a last resort rather than a template, though, because it means you now own maintaining a forked copy of a Microsoft page indefinitely, including replicating any future field or logic changes Microsoft makes to the original. For a page that rarely changes, that’s a manageable trade-off for another year or two of runway. For a page tied to core financial posting, it’s a maintenance burden that will outlast the convenience it buys.

Building the plan now

Version 29’s SOAP removal is close enough that most partners already have a project underway for it, and there’s real value in doing the OData audit at the same time rather than as a separate engagement six months from now. The RT0008 telemetry query doesn’t distinguish urgency by protocol, so pulling both SOAP and OData usage in one pass gives you a single, complete picture of every legacy web service dependency in an environment instead of two half-finished ones. Clients who hear “we already checked your integrations for the SOAP deadline” and then get surprised by an OData outage eighteen months later will reasonably ask why the first audit didn’t catch it. It’s a fair question, and the honest answer is that it’s a different telemetry filter and a few extra hours of query classification, not a fundamentally different project. Doing both now, while the environment’s already open on the workbench, is the cheaper version of this work by a wide margin.

Routeget Technologies has been walking clients through Business Central’s SOAP and OData retirement timelines as part of standard health-check engagements, building the telemetry-based inventory first so the migration scope is based on what’s actually running rather than what’s documented.

#BusinessCentralOData #ODataDeprecation #APIv2Migration #BCIntegrations #ERPGovernance #BusinessCentralAPI

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

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