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

Time Zone-Agnostic Resource Planning Fields Reached GA in Project Operations. Extend Booking Still Isn’t Automatic.

Resource manager reviewing a project scheduling timeline with time zone indicators on a large office display

A resource manager in Chicago books a developer in Manila for a two-week sprint starting Monday at 9 a.m. The booking looks correct in the schedule board. Three weeks later, someone extends that booking by a week, and the new segment quietly starts two hours later than anyone intended, because the underlying date fields were interpreted in the resource manager’s time zone, not the resource’s, and the assignment profile that governs the extension only overlapped with the developer’s working day by a narrow window. Nobody notices until the invoice reconciliation shows unbilled hours that don’t match the timesheet. This is not a hypothetical edge case for any organization running distributed delivery teams on Dynamics 365 Project Operations. It is the default behavior the platform has shipped with since resource scheduling first launched, and as of September 2026, Microsoft has finally shipped time zone-agnostic resource planning fields, giving administrators a way to turn off that recalculation for the fields where it causes the most damage.

Resource manager reviewing a project scheduling timeline with time zone indicators on a large office display

What time zone-agnostic resource planning fields actually change

The feature, tracked under Message Center announcement MC1465316 and published in the Dynamics 365 Project Operations 2026 release wave 1 plan, reached general availability in September 2026 (Microsoft’s own release plan lists the month without a specific day, while the Message Center post cites September 30). It lets administrators configure resource requirement and resource booking start and end dates so they are stored and displayed without automatic time zone conversion, rather than being silently recalculated based on whichever user’s personalization settings happen to be active when a record is viewed or edited.

Under the platform’s existing behavior, a resource requirement’s dates are date-time fields, and Dataverse date-time fields carry a time zone behavior setting: user-local, time zone-independent, or date-only. Most of the scheduling entities in Project Operations were built as user-local by default, which is exactly what causes the Manila example above. A record entered by someone in Central Time and viewed by someone in a different zone gets recalculated on the fly to match the viewer’s offset. That is a reasonable default for a calendar invite. It is a poor default for a resource requirement that a project manager in one country, a resourcing specialist in another, and an automated allocation engine somewhere in the middle all need to interpret identically.

Why this has been a real operational problem, not a cosmetic one

The root cause sits in how Project Operations already handles time zones for projects and tasks, and it predates this release. A project’s time zone is inherited from the work hour template applied to it. Dates on the project form are shown relative to the logged-in user’s time zone on every tab except Tasks, where dates always render in the project’s own time zone. That inconsistency alone trips up new administrators. Layer resource bookings on top, and the practical failure mode Microsoft’s own documentation describes is the Extend Booking scenario: a bookable resource needs at least one minute of overlapping work time with the assignment profile used to define the extension, or the extension either fails or lands at an unexpected time. In practice, teams have worked around this by insisting device time zones match Dynamics 365 personalization settings exactly, which is a fragile control to enforce across a distributed workforce and does nothing to fix the underlying data model.

The financial exposure is not abstract. Project Operations bookings feed resource utilization reporting, and utilization numbers feed billing for time and materials engagements. A booking that silently shifts by two hours because of a time zone recalculation does not usually change the total hours booked, but it does change which calendar day or which shift a resource shows as committed, and that mismatch is exactly the kind of discrepancy that turns a routine month-end reconciliation into a multi-hour investigation. For organizations running global delivery models where a single project pulls resources from three or four time zones, this has been a recurring, quietly expensive class of data integrity issue rather than a one-off annoyance.

Solution architect at a dual-monitor workstation reviewing a resource booking schedule board across time zones

What actually changes once you enable it

Enabling time zone-agnostic behavior on resource requirement and booking date fields converts them from user-local to time zone-independent at the platform level. Once that switch is made, the stored value for a start or end date stops being reinterpreted based on the viewer’s personalization settings. Everyone who opens that record, regardless of where they are logged in from, sees the same date and time. This is the same mechanism Dataverse has long supported for other entities; Project Operations is catching up by extending it to the specific tables where resource planning data lives.

Two things are worth flagging before you flip this on for a live environment. First, this is an opt-in configuration change, not a default behavior swap, so existing bookings created under user-local semantics do not automatically reinterpret themselves; plan for a validation pass on in-flight bookings after enabling the feature rather than assuming historical data self-corrects. Second, the Extend Booking overlap requirement between resource and assignment profile working hours does not disappear just because the date fields are now time zone-independent. That constraint is a scheduling logic rule, not a date-storage rule, and it will still reject or misalign an extension if a resource’s working calendar genuinely does not overlap with the profile driving the extension. Time zone-agnostic fields fix the data consistency problem. They do not fix a genuinely misconfigured working calendar.

A practical rollout sequence

Start by auditing which projects and resource pools actually span more than one time zone today; if your delivery model is single-region, this feature is low priority regardless of how appealing it sounds. Where it does apply, enable the setting in a sandbox environment first and pull a sample of active bookings that were extended or modified in the last quarter, then compare their displayed start and end times before and after the change for a handful of test users logged in from different time zones. That comparison is the fastest way to confirm the fields are behaving as time zone-independent rather than assuming the toggle worked from the release notes alone.

Next, reconcile resource calendars against project work hour templates for any team that has triggered Extend Booking issues in the past. Since the overlap requirement is unaffected by this change, this is the moment to fix calendar misalignments you may have been tolerating as a known quirk. Finally, update any Power Automate flows or integrations that read resource booking dates directly, since a flow written to expect user-local conversion behavior will now receive a raw, unconverted value, which is the correct behavior going forward but a breaking change for logic that implicitly depended on the old conversion.

The bigger pattern worth watching

This release is a narrow fix, but it points at a broader gap in how Project Operations was originally modeled for single-region delivery and is now being retrofitted for genuinely distributed teams. Organizations that have built manual device-time-zone-matching policies as a workaround should treat this as an opportunity to retire that policy rather than run both approaches in parallel indefinitely. For firms like Routeget that implement and support multi-region Project Operations deployments, this is exactly the kind of platform change worth validating in a client’s sandbox before it reaches their production resourcing team, since the difference between a correctly configured rollout and a rushed one is measured in reconciliation hours saved every single billing cycle.

Sources: Microsoft Learn, “Overview of Dynamics 365 Project Operations 2026 release wave 1” and the associated planned-features page for “Use time zone-agnostic fields in resource planning” (public preview March 31, 2026, general availability September 2026); Message Center announcement MC1465316; Microsoft Learn, “Manage multiple time zones” (Project Operations resource management documentation) for the Extend Booking overlap requirement and project/task time zone inheritance behavior.

#ProjectOperations #ResourceScheduling #TimeZoneManagement #DynamicsFinanceOps #ProjectBillingAccuracy

The CoE Starter Kit Is Dead. Agentic Center of Enablement Isn’t the Full Replacement Yet.

IT governance director reviewing a Power Platform admin governance dashboard on a large office monitor

If your organization still runs the Power Platform Center of Excellence Starter Kit, you already know something changed this year. The monthly release cadence that used to ship new Power BI dashboards, governance flows, and inventory jobs went quiet in February. By May, Microsoft made it official: the kit is “no longer receiving ongoing feature investments or updates.” For a lot of IT Directors and Power Platform CoE leads, that left a real question sitting on the desk. The DIY governance stack your team spent two or three years building and patching now has no vendor behind it, and the natural next move, moving everything into the Power Platform admin center, only gets you partway there.

That gap just got a little smaller. In September 2026, Microsoft opened public preview on the Agentic Center of Enablement, a set of three AI agents built directly into the admin center that are meant to take over a chunk of what the CoE Starter Kit used to do by hand. It is a meaningful step. It is not, on its own, a like-for-like replacement, and understanding exactly where the line falls matters more than the headline announcement.

What Actually Happened to the CoE Starter Kit

The timeline is worth stating plainly, because a lot of the commentary around this has blurred it. Development on the CoE Starter Kit effectively stopped in February 2026. Microsoft’s public confirmation followed in the spring, framed not as an abandonment but as a redirection of engineering effort: governance capability was moving from a community-maintained accelerator into the product itself. That framing turned out to be accurate, just slower to materialize than the announcement implied. Between May and September, organizations that depended on the kit for environment inventory, maker identification, and license reclamation were largely left running an unsupported toolset with no clear native equivalent for several of its core jobs. The admin center had usage and licensing dashboards, but not the ownership tracking, lifecycle states, or cross-tenant rollups that a mature CoE program actually runs on day to day.

That is the backdrop the Agentic Center of Enablement is stepping into, and it explains why the reaction from practitioners has been cautiously interested rather than celebratory.

IT governance director reviewing a Power Platform admin governance dashboard on a large office monitor

Agentic Center of Enablement: Three Agents, One Governance Loop

The Agentic Center of Enablement is not a dashboard you configure. It is three purpose-built agents that run continuously against your tenant, and each one does a distinct job in what Microsoft is positioning as a closed governance loop.

The Highlights agent produces a daily snapshot of tenant activity with no setup required: new resource creation, capacity consumption shifts, and other changes an admin would otherwise have to go looking for. The Insights agent is the one doing the heavier analytical work. It scans the tenant continuously and surfaces governance issues, ownerless resources, activity happening in the default environment, and security, compliance, performance, and adoption problems, then ranks them by impact so an admin isn’t left triaging a flat list. The Action Plan agent takes whatever the Insights agent surfaces and turns it into a concrete remediation plan with defined steps, which an admin reviews and approves before anything actually executes. Every action any of the three agents takes is logged in a full audit trail, which matters for organizations that need to show a paper trail to internal audit or a regulator.

Access is straightforward by design. It requires at least one managed environment in the tenant and the Power Platform administrator role, and it activates automatically rather than needing a deployment project the way the old kit did. For a CIO comparing total cost of ownership, that alone is worth noting: there is no solution to import, no Power Automate flows to maintain, no Dataverse tables to keep patched against breaking API changes.

Solution architect typing at a keyboard with dual monitors showing governance and application inventory analytics

Picture the scenario the Insights agent is actually built for. A regional sales team spins up a canvas app in the default environment to solve an immediate problem, the maker moves teams six months later, and the app keeps running with nobody watching its connector permissions or its data exposure. Under the old model, that app surfaces only if someone happened to run the right CoE Starter Kit inventory flow and then manually reviewed the output. Under the new model, the Insights agent flags it as default-environment activity with an ownerless resource attached, ranks it against everything else it found that day, and the Action Plan agent proposes reassigning ownership or migrating it into a governed environment before anyone has to go looking. That is a genuine reduction in the manual triage work a CoE analyst used to own.

Where the Gap Still Sits

Here is where the caution comes in. Reviews of the preview from consultants who ran real CoE programs on the Starter Kit have flagged the same handful of missing pieces, and they are not minor ones. The admin center, even with the new agents layered on top, still does not give you shadow IT detection in the sense the kit’s telemetry did, since it inventories what exists inside the platform rather than surfacing unsanctioned use happening around its edges. Lifecycle management, the process of formally retiring an app or flow, reassigning ownership when someone leaves the company, or tracking an asset through draft, active, and deprecated states, is not something the Insights and Action Plan agents currently model. Cross-tenant visibility, relevant to any organization running multiple tenants after an acquisition or a regional split, also is not part of what shipped in September’s preview. And the business context that made the old kit useful to non-technical stakeholders, tagging an app as customer-facing, financially regulated, or tied to a specific business unit, still has to be built and maintained separately, because the agents currently work from platform telemetry rather than organizational metadata.

None of that makes the Agentic Center of Enablement a disappointment. It genuinely automates the parts of governance that used to eat the most analyst hours: finding orphaned resources, flagging default-environment sprawl, and building a first-draft remediation plan instead of starting from a blank spreadsheet. It just is not yet the full replacement that some of the messaging around the CoE Starter Kit’s retirement implied it would be.

What This Means for Your Governance Roadmap

For an organization still weighing what to do with its Starter Kit investment, the practical move right now is not to rip anything out. The kit’s dashboards and flows will keep functioning even without updates, and the specific gaps described above, ownership workflows, lifecycle tracking, cross-tenant reporting, are exactly the pieces worth keeping running in parallel while the native agents mature. Treat the preview period as a chance to pilot the Insights and Action Plan agents in a single managed environment, compare their findings against what your existing telemetry already tells you, and use the overlap to decide which manual processes can retire first. Ownerless resource detection and default-environment cleanup are reasonable early candidates, since those are exactly the categories the Insights agent targets today.

A workable sequence looks like this. Start by enabling the agents in whichever managed environment already has the most mature governance discipline, since that gives you a clean baseline to compare against rather than a noisy one. Spend two or three weeks letting the Highlights and Insights agents run before acting on anything, so you get a real read on how their findings line up with what your team already knew versus what genuinely surprises them. Then hand a small batch of the Action Plan agent’s proposed remediations to whoever currently owns that work by hand, and measure the time saved rather than assuming it. Only after that comparison holds up across a full reporting cycle does it make sense to talk about retiring pieces of the Starter Kit stack rather than just running both in parallel.

It is also worth flagging this to whoever owns license and compliance risk in your organization, since the daily snapshot and continuous scanning behavior changes what “governance coverage” means for audit purposes, even during preview. A feature that is not yet generally available can still become the thing an auditor asks about six months from now.

We have walked several clients through exactly this kind of platform transition at Routeget Technologies, and the pattern holds regardless of which specific tool Microsoft is retiring or introducing: the risk isn’t in adopting the new capability too early, it’s in assuming a preview feature already covers ground it hasn’t gotten to yet. Run the pilot, keep the documentation for what the old system covered that the new one doesn’t, and revisit the gap list when general availability lands, since that is typically when Microsoft fills in the pieces a preview release leaves out.

#AgenticGovernance #CoEStarterKit #PowerPlatformGovernance #ShadowITRisk #EnterpriseAI #LowCodeGovernance

An AI Builder Prompt Inside a Copilot Studio Agent Skips Your AI Builder Credits. It Draws From Copilot Credits Instead.

Solution architect reviewing an AI agent cost analytics dashboard on a large office monitor

A solution architect at a mid-market manufacturer spent the spring building a Copilot Studio agent to triage vendor emails: pull the invoice number, classify the request type, draft a reply for a human to approve. The extraction logic ran through an AI Builder custom prompt, the same kind the finance team had already been using inside a Power Automate flow for months. The architect assumed the agent’s usage would draw from the same AI Builder credits the company had already purchased through a capacity add-on for that flow. It didn’t. Three weeks after the agent went live, the Copilot Credits pool that governed an entirely different project ran dry, and nobody could explain why until someone actually read the fine print on how AI Builder prompts get billed once they leave Power Automate and start running inside an agent.

This is not a hypothetical edge case. It is the direct, documented behavior of how Microsoft splits AI Builder consumption across its two billing meters, and it matters to anyone scoping a Copilot Studio project that leans on AI Builder for extraction, classification, or generative text work. The split is simple to state and easy to miss: AI Builder credits, whether seeded through a license or purchased as a capacity add-on, only ever pay for AI Builder usage inside Power Apps and Power Automate. The instant that same prompt is wired into a Copilot Studio agent, whether through a topic, an agent flow, or an AI plugin, the meter that runs is Copilot Credits, full stop, regardless of how much unused AI Builder capacity sits in the tenant.

How an AI Builder Prompt Actually Gets Into an Agent

There are three distinct ways to wire an AI Builder prompt into a Copilot Studio agent, and they carry different reliability and governance tradeoffs worth understanding before picking one for a production scenario. The first is a Prompt Action, built through Copilot Studio’s own five-step wizard: name the action, write the prompt with its input variables, map inputs and outputs, test it, and publish it as a general availability capability that Copilot for Microsoft 365 can invoke directly. The second is a Topic Node, where a “Call an action” step inside a scripted topic calls a custom prompt built inline, giving a developer explicit control over exactly when the prompt fires within a defined conversation flow rather than leaving invocation to the model’s own judgment. The third, still in preview, is an AI Plugin, where the agent decides on its own whether a user’s phrasing matches the prompt’s description closely enough to invoke it, which is convenient for open-ended agents but introduces a layer of semantic matching that a cost-sensitive, high-volume scenario probably should not depend on without testing it thoroughly first.

Each of these paths has a quirk worth planning around. Newly published actions can take a few minutes to actually appear inside the live agent experience, which has tripped up more than one team mid-demo. And because AI Plugin invocation depends on the model correctly matching a user’s intent to a prompt’s written description, a poorly worded action description will simply never fire, silently, with no error to debug against; the fix is almost always writing a sharper, more literal description of what the prompt does and when it should be used, not adjusting the prompt itself.

Close-up of hands on a keyboard with a dual-monitor setup showing an AI agent builder interface and a billing usage graph

How AI Builder Credits and Copilot Credits Actually Split

Microsoft’s own AI Builder credit management documentation states plainly that AI prompts run on AI Builder credits “in the context of Power Apps and Power Automate flows.” Its companion licensing page, updated as recently as June 2026, closes the loop on the other side: every AI Builder capability used inside a Copilot Studio agent, whether that’s a prompt fired from a topic, an action, or an agent flow, consumes Copilot Credits instead. There is exactly one carve-out, and it is a narrow one: prompts triggered from the agent’s own embedded test panel during development do not consume credits at all. Once that same prompt is live and being called by an actual conversation, real users, real credits.

The rate table behind that consumption is tiered in a way that rewards knowing which tier a given prompt actually needs. Basic text and generative tools run at roughly a tenth of a Copilot Credit per thousand tokens, characters, images, or pages processed. Standard-tier tools run fifteen times that rate, and premium-tier generative models run a hundred times the basic rate. Content processing tools, the category that covers document and image-heavy extraction work, run at eight Copilot Credits per image or page regardless of tier. An architect who defaults every prompt in an agent to the most capable underlying model available, out of an understandable instinct to maximize accuracy, can inflate the agent’s running cost by two orders of magnitude compared to a version that used a standard-tier model for routine classification and reserved the premium tier for genuinely ambiguous cases.

This distinction also reframes how a team should think about the AI Builder seeded-credit removal scheduled for November 1, 2026, when Microsoft strips seeded AI Builder credits out of existing license entitlements and stops selling new AI Builder capacity add-ons to net-new customers entirely. For a team whose AI Builder usage lives mostly inside Power Automate flows, that deadline is a real budgeting event requiring a Copilot Credits purchase to replace lost capacity. For a team whose AI Builder usage lives mostly inside Copilot Studio agents, the deadline changes almost nothing, because that usage was never drawing on AI Builder credits to begin with. Knowing which bucket a given deployment actually falls into, before the deadline rather than after, is the entire point of understanding this split.

Building a Cost Model Before Scaling an Agent

The practical move for a technical team is to treat cost measurement as a required step before an AI Builder-backed agent goes anywhere near production traffic, not an afterthought handled through a monthly invoice review. Run the agent through a realistic volume of test conversations in a sandbox environment first, using the same prompts, the same model tiers, and roughly the same document sizes the production scenario will see, then check the Copilot Credits consumption reported in the Power Platform admin center against the AI Builder consumption reported separately for the same period. The two numbers will not match the way a team accustomed to Power Automate-only AI Builder usage might expect, and that mismatch is the whole exercise.

It is also worth deliberately testing each invocation path’s actual reliability under realistic phrasing before committing to it for anything customer-facing. A Topic Node call is deterministic: it fires exactly when the flow logic says it should, which makes its cost entirely predictable and its behavior easy to audit. An AI Plugin action is probabilistic in comparison: it fires when the model believes it should, based on matching user language to a written description, which means its cost and its behavior both carry a margin of uncertainty that shrinks with better description writing and testing but never fully disappears. For a scenario where getting the wrong answer, or no answer, actually costs the business something, that tradeoff deserves to be a documented decision, not a default nobody examined.

None of this is a reason to avoid combining AI Builder with Copilot Studio; the pairing is genuinely useful, and it is how most organizations will end up bringing extraction and classification capability into a conversational agent without building a custom model from scratch. Routeget Technologies has walked several clients through exactly this kind of agent-cost modeling exercise before a production rollout, and the pattern is consistent: the surprise is never that the technology doesn’t work, it’s that the invoice arrives against a different budget line than the one everyone was watching. Building that visibility in during the design phase, rather than discovering it after a month of live traffic, is the difference between a predictable agent rollout and an uncomfortable finance conversation.

#AIBuilder #CopilotStudio #CopilotCredits #AgenticAI #PowerPlatformLicensing #EnterpriseAI

The Power Apps Canvas Authoring Agent Reached GA. Your Governance Policy Didn’t Come With It.

IT governance analyst reviewing AI-assisted low-code application development activity on a large display

A Power Platform CoE lead at a mid-market insurer found out about the change the way most of these things get discovered: by accident, during a routine environment audit. A developer had connected GitHub Copilot to a production canvas app through Microsoft’s new canvas authoring agent, made a dozen edits to a claims-intake screen over an afternoon, and synced them straight into the live coauthoring session. Nothing in the change log flagged it as unusual. The commit history, if you could call it that, lived in a chat transcript on someone’s laptop. No one had done anything against policy, mostly because no policy addressed it.

That gap is the real story behind Microsoft’s canvas authoring agent plugin, which reached general availability in September 2026. The feature itself is a genuine productivity tool: it lets coding agents such as GitHub Copilot and Claude Code create screens, wire up data sources, and write Power Fx formulas inside an existing canvas app, all through a Model Context Protocol (MCP) server that Microsoft ships as part of its Power Platform Skills toolkit. For organizations trying to close the gap between the number of business problems worth automating and the number of qualified makers available to build for them, this closes real ground. What it doesn’t do is arrive with a governance model of its own, and that distinction matters more than the feature announcement lets on.

IT governance analyst reviewing AI-assisted low-code application development activity on a large display

What the canvas authoring agent actually changes

Canvas apps have always been editable from outside Power Apps Studio in a limited sense, through the pack/unpack tooling that Power Platform admins use for source control. What’s new is that an external AI agent can now read and write that same source format, .pa.yaml files that describe screens, controls, and formulas, while a live coauthoring session keeps Studio in sync in real time. A developer opens an app in Studio, turns on coauthoring, points a coding agent at the Studio URL through a short configuration command, and from that point forward the agent can inspect available connectors, understand a data source’s schema, and start proposing changes that appear in the open Studio tab almost immediately.

Microsoft’s own documentation is fairly candid about what this requires from an organizational standpoint. The plugin authenticates through the Azure Identity SDK rather than managing its own credentials, which is the right design choice, but it also means the agent is operating with whatever permissions the signed-in developer already has. There’s no separate, scoped-down identity for “AI agent editing this one app.” If a developer has edit rights across a solution, so does the agent connected to their session.

Why the timing creates a false sense of coverage

Microsoft also shipped enhanced admin controls for agent security this same month, giving Power Platform administrators the ability to centrally define authentication requirements, block anonymous access, and set sharing restrictions for agents at the environment or environment-group level. It’s a legitimate and overdue capability, and if your team has been tracking the Power Platform release notes, it would be easy to assume it covers this new scenario too.

It doesn’t, at least not based on what Microsoft has published. Those enhanced controls are built around agents deployed and run inside the platform itself, the kind built in Copilot Studio and surfaced to end users. The canvas authoring agent plugin is a different animal entirely: a locally running MCP server, invoked from a developer’s own machine, connected to a live editing session rather than a deployed runtime. Nothing in Microsoft’s release plan for the agent security controls mentions third-party coding agents or MCP connections as being in scope. Microsoft’s canvas apps documentation acknowledges the gap in its own way, noting only that “organization policies may restrict agent plugins, third-party MCP servers, local MCP processes.” That’s a pointer toward policies your organization has to write, not a description of controls that already exist.

For a CIO or IT Director, that’s the operative fact. Two features reached general availability in the same release cycle, one of them creates a new pathway for AI-driven changes to production applications, and only one of them comes with a dedicated administrative control surface. The other one inherits whatever governance already existed around app editing generally: your connector policies, your data loss prevention rules, and whatever review discipline your team enforces on its own.

Developer typing on keyboard with dual monitors showing an AI coding agent editing a low-code application interface

What that means for the controls you actually have

None of this means the feature should be blocked outright. It means the governance conversation has to happen at the level of existing controls rather than waiting for a purpose-built one. A few of those controls do real work here if teams actually use them.

Data loss prevention policies still apply to every connector the agent touches, since the plugin operates through the same connector framework as any other canvas app author; an agent can’t reach a data source that DLP policy already blocks for that environment, which means auditing DLP coverage in development environments (where this tool will see the most use) is worth doing before rollout rather than after an incident. Account scoping matters more than usual here too: because the agent inherits the developer’s own permissions rather than operating under a separate identity, the standard advice to use accounts with minimum necessary access for the target app stops being a nice-to-have and becomes the only real access control in play. A developer testing this plugin with an account that has broad maker rights across a solution has effectively given a coding agent the same reach.

Code review is the other lever, and it’s one many low-code teams have historically underused precisely because canvas apps didn’t produce reviewable source in any conventional sense. That’s no longer true. The .pa.yaml output is plain text, which means it can go through the same pull request and review process a development team would apply to any other code change, if the organization chooses to route it that way. Microsoft’s own guidance is explicit that this is a “best-effort” generation process and that validation against organizational standards remains the developer’s responsibility, not something the tooling guarantees. Teams that already treat canvas apps as governed software assets, with source control and change review, will find this capability drops into that process with minimal friction. Teams that have historically treated canvas apps as disposable end-user tools, exempt from the ALM discipline applied to pro-code systems, are the ones most likely to be surprised later.

There’s a narrower risk worth naming directly for security teams: indirect prompt injection. An agent pulling schema information or sample data from a connected source, whether that’s a SharePoint list, a SQL table, or a third-party connector, can encounter content crafted to manipulate its next action. Microsoft flags this explicitly in its own security guidance for the tool, which is a signal worth taking seriously rather than filing away as boilerplate.

The decision in front of you

The practical takeaway isn’t that this feature is unsafe to adopt. It’s that adopting it responsibly requires deliberately extending existing governance rather than assuming new governance arrived with it. That means reviewing DLP policy coverage for the connectors your canvas app makers actually use, tightening account scoping for anyone testing agent-assisted authoring, deciding explicitly whether .pa.yaml changes require the same review your pro-code changes get, and briefing security teams on the prompt injection surface before, not after, the first incident report.

Organizations that have already invested in Power Platform Center of Excellence discipline, source control for canvas apps, and defined review gates will absorb this well. Those still treating canvas apps as a category exempt from that discipline now have a concrete reason to close that gap, because the tooling connecting external AI agents to production apps has already arrived, whether or not the governance model has caught up to meet it. Routeget Technologies has been helping clients build exactly that kind of CoE discipline into their Power Platform environments, and the teams that treat this as an ALM question rather than a feature-adoption question tend to be the ones who avoid finding out about a change during an audit instead of a change request.

#PowerApps #CanvasApps #AIGovernance #LowCodeGovernance #MCPServers #EnterpriseAI

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

Business Central’s Bank Reconciliation Copilot Went GA in 2024. The Docs Still Call It Preview.

Finance professional reviewing bank reconciliation Copilot matches on a laptop dashboard

A client’s controller asked a straightforward question during a recent Business Central scoping call: is the bank reconciliation Copilot feature safe to turn on for month-end close, or is it still something we should treat as experimental. The honest answer took longer to give than it should have, because Microsoft’s own documentation contradicts itself on this point. The 2024 release wave 2 plan lists general availability for “Complete bank account reconciliation faster with Copilot” as October 1, 2024. The current feature page and its companion FAQ, both carrying a May 2026 update stamp, still put “(preview)” in the title. For a firm advising clients on what they can rely on inside a signed statement of work, that gap between the release-plan record and the live documentation is not a footnote. It changes what you tell a client about support commitments, change-notice expectations, and whether the feature belongs in a production close process at all.

What Bank Reconciliation Copilot Is Actually Doing

Strip away the marketing language and the feature does two distinct jobs inside the Bank Acc. Reconciliation page. First, after Business Central’s standard rule-based automatch runs and leaves a set of unmatched bank statement lines, Copilot inspects the leftovers and looks for matches the deterministic engine missed, weighing transaction dates, amounts, and free-text descriptions together rather than requiring an exact rule hit. The example Microsoft uses in its own documentation is a single lump-sum deposit that actually represents five separate customer payments; automatch sees one bank line and five ledger entries and gives up, while Copilot can propose the one-to-many match. Second, for whatever remains genuinely unmatched, a separate Copilot action suggests a general ledger account to post the difference against, based on how the transaction description compares to your chart of accounts naming. A line that reads “Fuel Stop 24” gets proposed against a Transportation or Vehicle Expense account rather than sitting in a suspense account until someone investigates it manually.

Both actions are additive, not automatic. Nothing posts until a user reviews the proposed matches and explicitly selects “Keep it,” and the G/L suggestions can be saved into the Text-to-Account Mapping table so the same vendor description resolves the same way next month without asking Copilot again. That mapping table is worth building deliberately during rollout rather than letting it accumulate ad hoc, because it is the actual long-term efficiency gain here. The AI matching helps once; the mapping table helps every month after.

The status conflict, and why it matters for how you scope this

The release-plan record and the live docs cannot both be describing the same feature in the same state, so one of two things is true. Either the GA declaration from October 2024 covered only the base matching capability, and the newer G/L suggestion and mapping workflow that shipped afterward is what the current “(preview)” label actually refers to, or Microsoft’s documentation team simply never updated the page title when the feature graduated. Nothing in the current feature page, the FAQ, or the release-plan history explicitly resolves which of those is correct, and that ambiguity is the finding worth passing to a client rather than picking one interpretation and presenting it as settled fact.

Practically, this affects two decisions. The first is whether you commit to this feature working a specific way inside a contract, since preview features in Business Central online can change behavior without the same notice period Microsoft gives to GA capabilities. The second is how you frame it to the client’s audit or SOX-adjacent controls owner, who will reasonably ask whether a “preview” label means the output is less trustworthy. It does not mean that: the matching logic runs the same way regardless of the label, and the mandatory human review step is unchanged either way. But an auditor reading the page directly will see the word “preview” before they see your explanation, so raise it first rather than let them find it.

The entry-count ceiling most rollouts hit without noticing

The feature enforces a hard scan window: it only considers open bank account ledger entries dated between one day before the earliest bank statement line and the latest bank statement line, and it caps how many open entries it will process in that window. On 2025 release wave 1 and earlier, that ceiling sits around 1,000 open entries, depending on how long the description text runs. From 2025 release wave 2 onward, Microsoft raised it to roughly 3,000. Neither number is exposed anywhere in the user interface as a running count, so the first sign a client hits it is usually a reconciliation that used to surface a dozen AI-proposed matches suddenly surfacing none, with no error message explaining why.

For a company reconciling a single operating account monthly, 1,000 to 3,000 open entries is generous headroom. For a client running high-volume accounts payable through a single bank account, or one that has let old unapplied ledger entries pile up instead of writing them off, that ceiling is closer than it looks. Two mitigations are worth building into the rollout rather than discovering during a live close: confirm the client’s release wave version before promising Copilot behavior at a specific volume, and treat unusually old open ledger entries as reconciliation debt to clean up on a schedule, not just a reporting nuisance, since they silently consume slots in that scan window every single month.

Language alignment is a real constraint, not a compliance checkbox

Microsoft’s own guidance states plainly that matching accuracy depends on the G/L account names, ledger entry descriptions, and bank transaction descriptions all being in the same language, and that mixed-language data produces measurably fewer matches and suggestions. For a domestic single-language client this is a non-issue. For a multi-entity client running a shared chart of accounts across a US and a Mexico or Canada entity, where account names might be maintained in English but transaction descriptions arrive from a bank feed in Spanish or French, this is a concrete reason the feature will underperform in exactly the entity where the manual reconciliation burden is heaviest. Check the supported-language list against each legal entity’s actual operating language before setting client expectations, not after the first disappointing reconciliation run.

What the responsible AI documentation actually commits to

The FAQ is more specific here than most feature pages get, and it is worth quoting to a nervous data governance stakeholder rather than paraphrasing. Microsoft does not use company data, prompts, or Copilot responses to train its underlying models. Prompts and responses are retained as diagnostic data for twenty days, within the same geographic and compliance boundary as the rest of the company’s data, and that retained data is accessible only to Microsoft support personnel under existing Customer Lockbox controls. Usage telemetry is anonymized and excludes the actual prompts, responses, and customer data. None of this is unusual for a Business Central Copilot feature at this point in the platform’s maturity, but it answers the two questions a client’s compliance team will ask first, and having the citation ready saves a follow-up call.

Accountant reviewing AI-suggested bank transaction matches on a laptop dashboard

A rollout sequence that avoids the common failure mode

The most common way this feature disappoints a client is not a bad match, it is silence: a reconciliation runs, nothing gets proposed, and the user assumes Copilot is broken rather than assuming they hit the entry ceiling or a language mismatch. Enable the capability through the admin center first, confirm which release wave the client’s environment is on so you know the actual entry ceiling, and run the feature against one account’s real historical statement before go-live rather than a demo company, since Business Central’s built-in demo data is tuned to succeed and will not surface any of the above limits. During that test, deliberately build out the Text-to-Account Mapping entries for the client’s recurring, easily-categorized transactions, since that mapping table is what turns a one-time AI convenience into a permanent reduction in manual coding work. Finally, document the “Post if fully applied” auto-post option as an explicit decision rather than a default: it is convenient for a fully reconciled batch, but a client with a formal month-end sign-off process may want every AI-originated posting to pass through a human approval step regardless of match confidence, and that is a control decision worth having in writing.

Close-up of a bank statement reconciliation screen with matched and unmatched transaction lines highlighted

None of this makes the feature something to avoid. Two years after its stated GA date, the underlying matching logic is mature enough that Routeget now includes it as a standard discovery item on Business Central finance engagements, specifically so the entry-count ceiling and language dependency get surfaced during design rather than during the client’s first live close. The lesson is less about this specific feature and more about a pattern that shows up across the Copilot rollout in Business Central generally: the release-plan announcement and the day-to-day product documentation do not always stay in sync, and the responsible move is to check both before you tell a client what to expect, not just the one that sounds more finished.

#BusinessCentral #BankReconciliationCopilot #ERPIntegrations #FinanceAutomation #DynamicsFinanceOps #ResponsibleAI

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 Platform Pipeline Extensibility Changes Where Your ALM Logic Actually Lives

Solution architect reviewing an abstract Power Platform pipeline deployment diagram with an approval gate on an office monitor at dusk

Every Power Platform admin who has rolled out native pipelines has run into the same wall eventually. The tool is genuinely good at the thing it was built for: letting a maker click “Deploy” and move a solution from development to test to production without learning Azure DevOps YAML or touching a service connection. What it has never let you do, until recently, is put anything of your own between that click and the deployment itself. No custom validation before export. No compliance check before the artifact lands in production. No way to route the actual deployment through a service principal instead of the requester’s own credentials. If your organization needed any of that, the answer was to abandon native pipelines and rebuild the whole thing in Azure DevOps or with the community powerplatform-actions GitHub Action, which meant losing the low-friction maker experience that was the point of adopting pipelines in the first place.

Microsoft’s new Power Platform pipeline extensibility closes that gap, and it is worth understanding closely before you turn it on, because the way it is built shapes what kinds of governance logic actually belong there versus what still belongs in your existing CI/CD stack.

What pipeline extensibility actually adds

The mechanism is Dataverse business events. Power Platform pipelines now emit a defined set of events at each stage of a deployment, and a Power Automate cloud flow sitting in the pipelines host environment can subscribe to those events using the ordinary “When an action is performed” trigger from the Dataverse connector, filtered to the Power Platform Pipelines category. There are seven distinct trigger actions you can hook: OnDeploymentRequested, OnApprovalStarted, OnApprovalCompleted, OnPreDeploymentStarted, OnPreDeploymentCompleted, OnDeploymentStarted, and OnDeploymentCompleted. OnDeploymentRequested fires for every deployment regardless of configuration, and it is also the event a pre-export validation flow hooks into. The approval and pre-deployment pairs only fire at all if you have explicitly enabled the corresponding extension on that pipeline stage, so a flow subscribed to OnPreDeploymentStarted simply never triggers on a stage that hasn’t turned that gate on.

Abstract illustration of a deployment pipeline with connected stage nodes and a glowing approval gate checkpoint

Three gated extension points sit on top of those events, and each one solves a different problem rather than being interchangeable flavors of “add a step.”

Pre-export step required

This is the earliest gate. It runs when a maker submits a deployment request, before the solution is even exported from the development environment, and Microsoft explicitly restricts it to the first stage of a pipeline. That restriction matters more than it looks: once a solution is exported, the pipelines host stores the managed and unmanaged artifacts and promotes that exact same artifact version through every downstream stage. You cannot re-validate or re-export at stage two. Whatever checks you want to run against the source solution, whether that is a naming convention audit, a check for unmanaged customizations, or a call out to an internal change-approval system, have to happen here or not at all.

Is delegated deployment

This extension solves a different problem: identity. Without it, a deployment runs under the requesting maker’s own credentials, which means that maker needs write access to the target environment, something plenty of organizations are uncomfortable granting to anyone below an admin for a production environment. With delegated deployment enabled, the actual deployment executes under a service principal instead, provided the pipeline stage owner is configured as an owner of that service principal in Microsoft Entra ID. A maker can request a production deployment, get it approved, and never hold standing access to production at all. For any organization that has been quietly working around this by granting temporary System Administrator roles before a release and revoking them after, this is the fix that was missing.

Pre-deployment step required

This is the last gate, sitting after approval but before the deployment itself actually runs. This is where a final compliance check, a change-freeze lookup, or a notification to a service desk system belongs, since by this point the deployment has already been approved and you are deciding only whether to let it proceed right now.

Wiring a flow to it

The implementation pattern is consistent across all three extension points. You build a cloud flow, in the pipelines host environment specifically, not in the source or target environment, using the Dataverse “When an action is performed” trigger. You can scope the trigger with a condition against the output parameters, most commonly DeploymentPipelineName or DeploymentStageName, so that a single environment does not end up running every organization’s validation logic against every pipeline. Inside the flow you run whatever logic you need, whether that is a call to an external API, an approval step, or a lookup against a governance table, and then you close the loop with an unbound Dataverse action: UpdatePreExportStepStatus or UpdatePreDeploymentStepStatus, setting the status to 20 for complete or 30 for rejected. A rejected status fails the deployment outright rather than leaving it hanging. Microsoft ships two sample managed solutions, Pipelines Extensibility Samples and Delegated Deployment Samples, that are worth installing into a sandbox before writing anything from scratch, since they cover the trigger and action wiring in a working state rather than leaving you to reverse-engineer the output parameter names from documentation alone.

Where this still falls short

None of this replaces a pro-code CI/CD pipeline, and it is not trying to. The GitHub Actions and Azure DevOps paths for Power Platform still own the things extend pipelines does not touch: source-controlled solution unpacking, automated build artifacts, and static analysis through the solution checker as part of a pull request gate rather than a deployment-time check. What extend pipelines is actually good at is inserting governance and identity control into the maker-facing deployment experience without forcing every citizen developer through a developer-grade toolchain. That is a narrower job, and treating it as a replacement for real CI/CD is the most common mistake I would expect teams to make with it.

The rollout itself is also worth flagging before you plan around it. As of this writing, Microsoft describes the extensibility features as being rolled out gradually across regions, and existing pipelines customers may need to update the Power Platform pipelines application through the admin center before any of these extension points even appear as configurable options. If you check a production tenant and do not see pre-export or pre-deployment settings on a pipeline stage, that is very likely a rollout or update-application issue rather than a misconfiguration on your end, and it is worth confirming with a support ticket before spending time debugging a flow that was never going to fire.

A few operational limits are worth building into your rollout plan from day one. Personal pipelines created inside make.powerapps.com cannot be extended at all, so any governance requirement has to be enforced through admin-managed pipelines rather than personal ones if extensibility is part of the plan. Makers retain the ability to cancel a pending deployment request, but only up until the final deployment step actually begins, so a long-running pre-deployment check is not a safe place to also expect cancellation to work cleanly. And because the exported artifact is immutable across all downstream stages, any pre-export validation logic needs to be strict enough to catch problems before that first export, since there is no second chance to reject the same artifact further down the pipeline.

For architects who have been asking Microsoft for a middle ground between no governance hooks at all and abandoning native pipelines for full Azure DevOps, this is that middle ground. At Routeget Technologies, this is the kind of gap our Power Platform ALM engagements have historically had to close with custom Azure DevOps pipelines, so a native option worth building a proof of concept around is a welcome addition. It is worth testing against a sandbox pipeline now, both to get ahead of the regional rollout and to work out which of the three extension points actually maps to a real control gap in your current deployment process, rather than instrumenting all three reflexively the day they become available in your tenant.

#PowerPlatformPipelines #ALMGovernance #DataverseBusinessEvents #DelegatedDeployment #PowerAutomate #EnterpriseAutomation

Copilot Studio’s Computer-Use Agents Reached GA. The Success Rate Numbers Change the Business Case.

IT director reviewing an automated workflow diagram representing a Copilot Studio computer-use agent on an office monitor

A mid-market distributor recently asked its systems integrator for a quote to build an API bridge between Dynamics 365 Finance and Supply Chain Management and a fifteen-year-old carrier portal that still runs on a browser-only interface with no exposed endpoints. The estimate came back at nine weeks and roughly $160,000, most of it spent reverse-engineering a login flow and a rate-lookup screen that changes its layout every few months. That is the exact situation Copilot Studio’s computer-use agents were built for, and as of May 2026 the capability is generally available rather than sitting in preview. For CIOs and finance leaders staring down a similar quote, the real question is not whether the technology works. It is whether it works well enough, cheaply enough, and safely enough to replace a project that would otherwise sit on the backlog for a year.

What Copilot Studio’s computer-use agents actually shipped at GA

Computer-use agents let a Copilot Studio agent operate a website or a Windows desktop application the way a person would: it takes a screenshot, reasons about what it sees, and performs a click, a keystroke, or a scroll toward a stated goal. Microsoft’s own release announcement frames the GA milestone around three changes from the preview period. Credential handling moved to a more secure model rather than embedding logins in flow definitions. Customers can now choose which underlying model drives the automation, matching cost and capability to the task instead of accepting a single default. And the agents became noticeably more resilient to interface drift, meaning a carrier portal that shuffles a form field or repositions a button is less likely to break the automation outright, which was one of the most common failure modes reported during preview.

The feature also picked up a genuinely useful architectural change: computer-use steps can now be embedded inside a broader workflow, so a single process can call an API where one exists, fall back to UI automation where it does not, and route to a human approver for anything in between. That matters more than it sounds. Most legacy integration problems are not purely API-less. They are mixed: part of the process has a clean endpoint, and the rest lives behind a login screen nobody ever modernized. Treating the whole thing as one workflow, rather than stitching together a separate RPA tool alongside your Power Automate flows, is the actual value proposition here, not the novelty of an AI agent clicking buttons.

Where the economics genuinely hold up

Computer-use agents consume Copilot Credits on a per-step, consumption-based model that behaves differently from the message-based billing most finance teams are used to budgeting for a chatbot or a Copilot assistant. A short, well-scoped task, four or five steps to submit a form and confirm a result, costs relatively little. A long, branching process with dozens of steps run at volume compounds that cost quickly, and it compounds faster than most stakeholders expect the first time they see a monthly bill next to the pilot’s success metrics. Before approving a production rollout, finance and IT should jointly model the cost of the highest-volume scenario at expected transaction counts, not just the demo scenario that sold the project internally.

The honest framing for a CFO is this: computer use is not a general substitute for API integration. It is a tool for the specific and fairly common case where an API genuinely does not exist, the vendor has no near-term plan to build one, and the manual alternative already costs real headcount hours. A carrier rate portal, a government filing site, an old third-party benefits administrator, or an internal legacy application from a prior ERP era are the kinds of targets where the math works. Where an API does exist, even a mediocre one, direct integration through Power Automate or a custom connector will almost always be cheaper per transaction than UI automation, because every additional screenshot and reasoning step adds cost that a direct API call skips entirely. Teams that reach for computer use as a default integration pattern rather than a fallback tend to discover this the expensive way, usually around the second or third month of production volume.

Abstract illustration of an AI agent cursor navigating connected software interface panels

The success-rate numbers that should set expectations

Microsoft’s own documentation is candid about current performance limits, and CIOs evaluating this for anything beyond a narrow pilot should read those numbers before committing a budget line. Web-based tasks succeed at roughly 80 percent, which sounds reasonable until you consider what a one-in-five failure rate means for a process running hundreds of times a day. Desktop application tasks succeed at closer to 35 percent, a gap wide enough that any deployment targeting a legacy Windows client, rather than a browser, should be scoped as an assisted process with human review built in from day one, not a lights-out automation. Dropdowns, date pickers, and custom UI widgets remain a known weak point, along with the tendency for an agent to loop when the screen state does not match what it expected.

None of this makes the technology unusable. It makes it a tool that needs the same production discipline any automation project requires: define what “success” means precisely, measure it against a real baseline rather than a demo, and build an escalation path for the failures you know are coming rather than treating them as edge cases to handle later. Microsoft’s own guidance recommends exactly this, pointing customers toward least-privilege service accounts, restricted execution environments, and human-in-the-loop review for lower-confidence steps as standard practice rather than optional hardening.

Governance decisions to make before the first production run

Three controls matter most for a finance or IT leader signing off on this. First, audit logging: computer-use sessions can send activity to Microsoft Purview under a dedicated operation type, independent of the standard Dataverse logs the agent keeps by default, and that Purview trail is what most compliance teams will want to see before approving a process that touches financial data or customer information. Second, session visibility: every run generates a step-by-step activity map with screenshots, timestamps, and a list of exactly which credentials and which sites or applications were accessed, which gives an auditor something concrete to review rather than a black box. Third, and easy to overlook, the allow-list that restricts which sites an agent can act on does not fully prevent navigation to sites outside that list, only actions on non-allow-listed pages. Organizations with strict data-boundary requirements should layer network-level controls, such as browser policies through Microsoft Intune, on top of the Copilot Studio allow-list rather than treating the allow-list as a complete boundary on its own.

Administrators who decide the risk profile is not yet acceptable for a given environment can disable computer use entirely at the environment level, or disable the hosted browser specifically at the tenant level, through the Power Platform admin center. That toggle is worth knowing about even for organizations planning to adopt the feature, since it gives a clean way to pilot in one environment while keeping it off everywhere else until the governance model is proven.

What this means for the next integration decision

The distributor with the fifteen-year-old carrier portal does not need to choose between a $160,000 custom build and doing nothing. A scoped computer-use pilot against that single portal, with success measured honestly against the current 80 percent web success rate and a human reviewer catching the rest, is a legitimate middle option that did not exist eighteen months ago. The mistake would be extending that same logic to every integration gap on the roadmap without first checking whether each one is genuinely API-less or just under-prioritized. For organizations already running Dynamics 365 Finance and Supply Chain Management or Business Central alongside a Power Platform footprint, the practical next step is an inventory: which manual, screen-based processes actually lack an API path, which have one nobody built yet, and which are high-enough volume that the per-step credit cost changes the calculation entirely. Routeget Technologies has been walking clients through exactly that kind of inventory as computer-use agents move from a curiosity into a line item finance actually has to approve, and the pattern holds across industries: the technology is real, the cost model rewards precision over enthusiasm, and the governance controls exist, but only for the teams who turn them on before the first production run rather than after an incident.

#CopilotStudio #ComputerUseAgents #AgenticAI #RPAGovernance #EnterpriseAutomation #DynamicsFinanceOps