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

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

Customer Insights’ Real-Time Web Tracking Reaches GA. The Unification Still Runs on a Schedule.

Marketing operations analyst reviewing a unified customer journey dashboard blending anonymous and known visitor data

A prospect spends eleven minutes on your pricing page, adds a plan to a cart, then leaves without filling out a form. Three days later, that same person emails your sales team asking a specific question about the enterprise tier. In most Dynamics 365 environments today, those two events live in different universes: an anonymous session in Google Analytics or a marketing tag manager, and a fresh lead record with no browsing history attached to it. Without real-time web tracking tying the two together, the sales rep who picks up that email has no idea the prospect already compared pricing tiers three times last week.

That gap is what Microsoft’s new real-time web tracking and personalization capability in Dynamics 365 Customer Insights – Data is built to close, and it reaches general availability this month. For CMOs, sales operations leaders, and the CIOs who own the Dynamics 365 platform underneath them, the feature is worth understanding in some detail, because the way it actually works has a nuance that the “real-time” label in the release notes doesn’t fully convey.

What the Feature Actually Does

Customer Insights – Data now tracks website visitors, known and anonymous, through a script deployed on the site. The moment an unknown visitor lands on a page, they’re assigned a persistent tracking identifier stored in a cookie, and their behavior (pages viewed, products browsed, elements clicked) streams into Dataverse. Within roughly thirty seconds, that visitor shows up as an “unknown” customer profile inside Customer Insights, carrying a real activity history even though nobody knows their name yet.

When that same visitor eventually identifies themselves, by submitting a form, registering for a webinar, or creating an account, the system doesn’t discard the anonymous history. It calls a function that links the tracking identifier to the newly created customer record, and the previously anonymous browsing activity gets attached to a real profile. If that person later returns from a different laptop or a different browser, they get a new anonymous identifier on that device, but once they log in or submit contact information again, that second stream of activity gets tied back to the same underlying identity.

Abstract illustration of an anonymous visitor identity merging into a verified known customer profile

This is, functionally, a customer data platform capability arriving natively inside the Dynamics 365 stack rather than requiring a separate CDP subscription layered on top. Organizations can build personalization logic either through a no-code path using Microsoft’s Optimizely integration, or through a pro-code, API-driven approach for teams that want direct control over what triggers a personalized experience. Either way, the resulting segments and unified profiles are available to Customer Insights – Journeys for campaign targeting, and to any downstream system that queries the Dataverse tables directly.

Why “Real-Time Web Tracking” Needs a Footnote

Here’s the part worth flagging before anyone budgets a Q4 project around it. The anonymous tracking genuinely is real-time: activity streams into Dataverse and shows up in the Customers view within seconds of it happening. But the step that actually matters for revenue, merging that anonymous history into a unified customer profile, does not happen instantly. It runs on Customer Insights – Data’s scheduled unification process, the same batch job that has always consolidated records from multiple sources into a single golden profile.

In practice, a prospect can browse your pricing page today, submit a contact form an hour later, and still not show up in your CRM with their browsing history attached until the next unification cycle completes, which could be same-day or could stretch into the following morning depending on how the environment is scheduled. A rep calling a hot lead within minutes of form submission, still one of the strongest predictors of conversion, may be working from a bare contact record with none of the browsing signal that made the lead worth prioritizing.

None of this makes the feature less valuable. It does mean the operational conversation inside an IT or RevOps organization needs to be about unification frequency and lead-routing timing, not just about turning the tracking script on. Teams that assume “real-time” means “instantly reflected in the CRM record a rep is staring at” will be disappointed the first time a fast-moving lead falls through that gap.

One more wrinkle is worth flagging before anyone treats this as settled: Microsoft’s own step-by-step setup guide for the feature still carries preview-only language and cautions against production use, even though the official release plan lists September 2026 as its general availability date. That kind of documentation lag isn’t unusual right around a GA milestone, but it’s a reason to confirm the feature’s actual status directly in a given tenant, rather than assuming the release plan and the setup documentation are perfectly in sync on day one.

The Business Case Underneath the Feature

Set the timing nuance aside for a moment, because the underlying capability solves a problem that has quietly cost sales and marketing organizations money for years. Every enterprise running Dynamics 365 Sales alongside a separate web analytics tool has faced the same reconciliation problem: marketing can see anonymous traffic and behavioral signal, sales can see named leads and opportunities, and connecting the two requires either an expensive third-party CDP, a custom integration project, or accepting that a huge amount of buyer intent simply never reaches the people having sales conversations.

Bringing that unification natively into Dataverse changes the calculus in two ways. First, it removes a licensing and integration cost that many mid-market and even large enterprise customers had been avoiding entirely, leaving sales teams working blind on digital engagement signal even when marketing had the budget to capture it. Second, and more subtly, the browsing data now lives in the same platform as pipeline, opportunity, and service history, which is what actually makes predictive lead scoring and next-best-action recommendations useful rather than theoretical. A scoring model is only as good as the signal feeding it, and “this account viewed the enterprise pricing page four times in two weeks” is a materially stronger signal than anything derived from firmographic data alone.

The revenue argument holds up without inventing statistics to dress it up: faster identification of high-intent anonymous traffic lets marketing trigger nurture sequences sooner, lets sales prioritize outreach based on actual behavior instead of form-fill recency, and gives the handoff between the two functions real context instead of just a name and an email address. Organizations that have approximated this with tag-manager exports and manual CRM enrichment know exactly how much reconciliation work that replaces.

What a CIO or CMO Should Actually Evaluate

Before greenlighting a rollout, a few questions deserve real answers rather than assumptions carried over from the release notes. The first is privacy and consent: cookie-based tracking of anonymous visitors sits squarely inside regional privacy regulation, and the feature’s technical documentation does not, on its own, resolve consent banner integration, cookie retention policy, or a right-to-be-forgotten workflow for a visitor who was never formally identified. That work belongs to legal and privacy teams, not to the admin flipping the feature on.

The second is unification cadence, covered above but worth a concrete decision rather than a default setting left unexamined. Sales operations leaders should know, in hours or minutes, how long a browsing session actually takes to appear on a contact record in their environment, and should decide whether that cadence fits how their team works leads.

The third is the build decision between the no-code Optimizely path and the pro-code API approach. Organizations already running Optimizely for web experimentation will find the no-code route genuinely reduces lift. Everyone else should treat the pro-code path as a real development project rather than a configuration exercise, since it means deploying and maintaining a tracking script, standing up the customer tracking table in Dataverse, and building the logic that calls the identity-linking function at the right moment in a session.

Finally, multi-device identity resolution has a real limit worth setting expectations around: a visitor gets a new anonymous identifier on every new device or cleared browser, and reconciliation only happens once they identify themselves again there. For B2B buying committees browsing from several laptops across an account, the “unified” view stays an approximation built from whatever identification events actually occurred, not a complete picture of every stakeholder’s activity.

Where This Leaves the Rollout Decision

None of these considerations argue against adopting the capability. They argue for treating it as what it is: a genuine, natively integrated CDP function that closes a real gap between marketing’s view of a prospect and sales’ view of a lead, arriving with the operational fine print that any capability touching customer data and real-time expectations tends to carry. Organizations paying for a bolt-on customer data platform specifically to solve this unification problem now have a reason to reevaluate that spend, and organizations that had written the problem off as unsolvable inside their existing Dynamics 365 investment have a genuine option they didn’t have a year ago.

The teams that get the most value out of this will treat the September GA date as the start of a scoping conversation, covering consent workflows, unification timing, and the no-code versus pro-code build decision, rather than as a switch to flip and assume will behave exactly as its name implies. Firms that have already worked through CDP unification problems in Dynamics 365 environments, Routeget Technologies included, tend to see the same pattern: the technology answers a real business need, but the value only shows up once the operational details around timing and consent get resolved deliberately rather than left to default settings.

#DynamicsCustomerInsights #CustomerDataPlatform #LeadScoring #SalesMarketingAlignment #DigitalTransformation

Dynamics 365 Copilot Capacity Budgeting Just Lost Its Calendar

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

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

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

What Microsoft actually changed

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

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

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

Why Sales Qualification Agent makes this concrete, not abstract

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

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

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

What changes in Dynamics 365 Copilot capacity budgeting

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

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

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

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

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

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

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

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

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

What a Sales Research Agent Fabric Lakehouse connection actually is

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

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

The permission layers people forget

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

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

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

Getting the rollout right

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

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

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

Budgeting for consumption, not just configuration

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

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

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

Microsoft Agent 365 Governance Is GA. Is Your Copilot Studio Fleet Ready?

IT director reviewing an AI agent governance dashboard on a large office monitor

When a mid-market manufacturer’s IT Director asked her Power Platform administrators for a simple headcount this spring, how many Copilot Studio agents actually exist across the organization, the answer took three weeks to assemble and still arrived with an asterisk. Some agents had been built by finance analysts using maker licenses nobody remembered granting. A handful had default connections into Dataverse tables holding customer payment history. Nobody could say with confidence who owned any of them once the person who originally built them changed teams or left the company. That scramble is becoming a familiar story across Dynamics 365 and Power Platform shops, and it is exactly why Microsoft Agent 365 governance has become a live budget conversation since the platform reached general availability on May 1, 2026.

IT director reviewing an AI agent governance dashboard on a large office monitor

Agent 365 is Microsoft’s control plane for observing, governing, and securing AI agents across an enterprise, regardless of where those agents were built. It applies to prebuilt Microsoft 365 Copilot agents, agents built in Microsoft Foundry, and, most relevant to this audience, agents built in Copilot Studio. For IT Directors and CIOs who have spent the last eighteen months watching Copilot Studio adoption spread from a handful of IT-sanctioned bots into dozens of business-unit-built agents, Agent 365 is the first serious attempt at a single inventory and policy layer that sits over all of it. Whether it is worth the licensing commitment depends less on the feature list and more on how much organizational work a rollout actually requires, which is the part vendor briefings tend to gloss over.

What Agent 365 governance actually covers

The platform’s job splits into three functions: observing agent activity across apps, endpoints, and cloud services; governing agents through policy-based controls and lifecycle management, meaning admins can install, publish, block, or reassign ownership of an agent directly from a central registry; and securing agents against threats such as over-privileged actions or misuse of connected data sources. Microsoft Defender now assesses the security posture of Foundry and Copilot Studio agents specifically, flagging risky configurations, including agents wired up to Model Context Protocol tools that could open a path to privilege escalation, and surfacing prioritized recommendations rather than a raw vulnerability dump.

The governance layer also introduces a formal approval and publication flow. Before an agent built in Copilot Studio reaches end users, an admin can review its data access, permissions, and security posture from the registry, rather than relying on the maker’s own judgment about what the agent should be allowed to touch. For any IT Director who has inherited a Copilot Studio environment where publication controls were an afterthought, this is the feature that closes the gap between having a data loss prevention policy on paper and actually enforcing it before an agent goes live.

One capability worth flagging separately is shadow AI discovery. Agent 365 uses Microsoft Defender and Intune to identify locally running agents on Windows endpoints that were never provisioned through any sanctioned platform. At GA, this covers agents built on the OpenClaw framework, with support for GitHub Copilot CLI and Claude Code agents promised to follow. It is a genuinely new capability, since most governance conversations to date have focused on what happens inside Copilot Studio or Power Platform, not on the coding agents developers are quietly running on their own laptops. That said, it is worth treating Microsoft’s framing of how widespread this problem actually is with some skepticism. The prevalence figures behind the “agent sprawl” narrative are Microsoft’s own positioning, and no independent study has confirmed how common unmanaged local agents really are on a typical enterprise fleet. Before budgeting for this specific control, it is reasonable to ask your own security team whether they have actually observed it as a problem.

The licensing math is per person, not per agent

Agent 365 is priced at $15 per user per month as a standalone add-on, or bundled at no additional cost inside Microsoft 365 E7, which lists at $99 per user per month and also includes the Entra Suite. The billing model is worth understanding precisely: one Agent 365 license covers every agent that person owns, sponsors, manages, or interacts with, so deploying more agents does not by itself increase the license count. You are licensing the humans accountable for agents, not the agents themselves, which is a more forgiving model than the per-seat-per-bot pricing some competitors use.

The complication is prerequisites. As of June 1, 2026, Agent 365 requires a specific underlying license foundation: Microsoft 365 E5 on its own, or E3 combined with both the Defender and Purview suites, with equivalent tiers defined for frontline, SMB, and education licensing. For an organization still running E3 without the add-on security suites, the real cost of Agent 365 is not the $15 line item. It is the E5 upgrade, or the Defender and Purview additions, that have to happen first. Run the math both ways before presenting a number to finance: E5 plus Copilot plus Agent 365 lands around $105 per user, while E7 covers the same ground at $99. For organizations already leaning toward E5 or E7 for other reasons, Agent 365 is close to free. For organizations still on E3, it is a licensing tier change dressed up as a governance purchase, and that distinction changes who needs to sign off on it.

Abstract illustration of a network of AI agents protected within a security shield, representing agent governance

Governance is an operating model, not a toggle

Microsoft’s own internal rollout, described in its IT organization’s implementation notes, is the most useful data point for what a realistic deployment looks like. Microsoft Digital currently manages more than 500,000 agents across its environment, and the team is candid that its operating model is still incomplete. Their starting point was not turning on policy enforcement. It was building an accurate, centralized inventory, capturing each agent’s name, lifecycle status, type, ID, owner, creation platform, and where it is actually used, with the registry auto-ingesting metadata from Copilot Studio, Power Platform, SharePoint, and Azure AI Foundry.

Just as significant is the administrative structure Microsoft settled on. Rather than assigning agent governance to a single owner, the organization split responsibility across an AI administrator role overseeing the full tenant inventory and lifecycle, an Agent Identity administrator managing identities through Entra Agent ID, and security and compliance teams defining the actual guardrails and approval thresholds. Internally, Microsoft describes agent governance as needing a cross-functional weekly rhythm among IT, security, identity, product, and business unit stakeholders, framing it explicitly as a team sport rather than a single admin’s checklist. Notably, the company also acknowledges that much of its own approval and escalation workflow is still manual, and that programmatic automation is an ongoing engineering effort rather than something that ships finished on day one.

For a CIO evaluating Agent 365, the practical takeaway is to separate the licensing decision from the operating model decision. The license question is a spreadsheet exercise: check your current Microsoft 365 tier against the June 2026 prerequisite list, and compare standalone Agent 365 pricing against an E7 upgrade if you are close to that threshold anyway. The operating model question is harder and cannot be solved by procurement. It requires naming an accountable owner for the agent inventory, deciding who plays the Agent Identity administrator role, and establishing the recurring cross-team review Microsoft itself says was the actual unlock, before the count of Copilot Studio agents in your tenant grows past the point where anyone can govern it from memory.

Routeget Technologies has walked several Dynamics 365 and Power Platform clients through exactly this kind of governance stand-up, usually starting with the same inventory exercise that surprised the IT Director in the opening example. The tooling question tends to resolve quickly once the organizational one is answered honestly.

#Agent365 #CopilotStudio #AIGovernance #ShadowAI #AgenticAI #EnterpriseAI

The Dynamics 365 Sales MCP Server Isn’t the Whole Picture

Solution architect reviewing a Dynamics 365 Sales AI agent integration architecture diagram on a monitor

A solution architect on a recent Dynamics 365 Sales engagement did what the documentation told him to do: he pointed a GitHub Copilot session in VS Code at the newly GA’d Dynamics 365 Sales MCP server, asked it to pull up a stalled opportunity, and watched it come back with a clean summary and a suggested outreach email. Then he asked it to update the opportunity’s close date. Nothing happened. No error, no record change, just a polite explanation that the tool wasn’t available. He had connected the right server. He just hadn’t connected both of them.

That gap trips up more than one team standing up agent access to Dynamics 365 Sales for the first time, because the Dynamics 365 Sales MCP server, which reached general availability in February 2026 after a preview that started in mid-2025, was never designed to be the only door into the system. It is a purpose-built layer that exposes a narrow set of sales-specific actions: retrieving a lead summary, qualifying a lead into an opportunity, generating an outreach email, listing leads assigned to a seller. Anything that looks like ordinary create, read, update, or delete work against Dataverse records sits behind a separate, general-purpose Dataverse MCP server. Architecting AI access to Sales properly means treating these as two components of one system, not as interchangeable options.

What the Dynamics 365 Sales MCP server actually exposes

The Sales MCP server groups its tools into three functional clusters that mirror existing Copilot experiences inside the app: Sales Qualification Agent tools, Sales Opportunity Agent tools, and the broader Copilot in Sales tool set. In practice this means an MCP client authenticated against this server can list a seller’s leads, pull a structured summary of a specific lead or opportunity, move a qualified lead into an opportunity record, and draft or send an outreach email using the same generative logic that powers Copilot inside the Sales workspace. These are opinionated, workflow-shaped actions. They encode the same business rules a seller would hit clicking through the UI, which is exactly the point: an external agent gets sales-process guardrails for free instead of raw table access.

What it deliberately does not expose is a general write path. There is no “update any field on any opportunity” tool here, and that is not an oversight so much as a design choice that keeps the blast radius of an agent request contained to well-understood sales actions.

Where Dataverse MCP fills the gap

For anything outside that workflow shape, whether it’s a custom Power Apps process reading a related quote table or an agent that needs to write directly to a Dataverse entity, the connection point is the separate Dataverse MCP server, reachable at https://<OrgURL>/api/mcp. It exposes four core operations: read_query, create_record, update_record, and describe, the last of which lets a client inspect table and column schema before it attempts a write, which matters a great deal in a Dataverse environment where customizations can mean the “standard” schema an agent expects has drifted from what is actually deployed.

One detail worth building into any design review: the Dataverse MCP server is enabled by default for Microsoft Copilot Studio but disabled by default for every other client. If a team is connecting GitHub Copilot, a custom agent, or any third-party MCP-compliant tool, an admin has to go into the Power Platform admin center, open the target environment’s Settings, navigate to Product > Features, and turn on “Allow MCP clients to interact with Dataverse MCP server,” then explicitly allow-list each client under Advanced Settings. Nothing connects by accident, which is a reasonable default for a capability that can write to production data, but it also means a “why isn’t this working” support call is often really a “did anyone flip this switch” question.

Abstract illustration of two connected server nodes representing the Sales MCP server and Dataverse MCP server architecture

Configuring both servers side by side

For a VS Code or other mcp.json-driven client, the practical setup is two separate server entries pointed at two different endpoints rather than a single unified connection string. The Sales server entry targets the Agent 365 service path scoped to the environment and the Sales MCP server registration, something like https://agent365.svc.cloud.microsoft/mcp/environments/<EnvironmentID>/servers/msdyn_SalesMCPServer, while the Dataverse entry targets the organization’s own API surface directly. Both are declared as HTTP-type MCP servers. Getting an agent to feel like it has coherent access to “Dynamics 365 Sales” as a single system is really a matter of configuring both endpoints correctly and letting the client route each request to the appropriate one, which most MCP-aware clients handle transparently once both connections are live.

It’s worth noting explicitly for architects scoping this work that Claude Desktop is not on Microsoft’s list of supported clients for the Sales MCP server as of this writing; Copilot Studio, GitHub Copilot in VS Code, and other MCP-compliant clients are. That’s a constraint worth confirming before a client commitment gets made in a statement of work.

Security enforcement isn’t a separate layer, it’s the same one

The question every security-conscious stakeholder asks first is whether an AI agent connected through MCP can see or touch more than the person who authorized it could. Microsoft’s own documentation is direct on this point: the Dataverse MCP server respects existing Dataverse security roles and row-level security, meaning a connected agent can only access the tables and records that the authenticated user’s security role already permits. There is no parallel permission model to reason about, no separate access control list to maintain for agent traffic. The security model an organization has already built for its human users through business unit hierarchies, field-level security, and role-based table access extends automatically to MCP-connected agents acting on that user’s behalf. That’s a meaningfully simpler governance story than a lot of teams expect walking into this, and it’s worth stating plainly to a CISO who assumes agent access requires a whole new access-control project.

What isn’t yet documented in detail is rate limiting or granular audit logging specific to MCP calls, and that’s a fair gap to flag rather than paper over. Teams putting this into production should validate logging behavior in their own tenant and treat detailed throttling behavior as something to test empirically rather than something to design around from a published number that doesn’t exist yet.

The licensing detail that changes the cost conversation

Since December 15, 2025, Dataverse MCP tool calls made by AI agents built outside Microsoft Copilot Studio are billed against Copilot credits, unless the organization already holds qualifying Dynamics 365 Premium licensing or a Microsoft 365 Copilot User Subscription License, in which case that usage is included. Agents built inside Copilot Studio are exempt from this particular charge model. The Sales MCP server has its own credit consumption structure layered on top, with different tool categories, such as basic text and generative AI tools versus generative answer tools, billed at different Copilot Studio credit rates. For an architecture that mixes a Copilot Studio-native agent with a custom VS Code-based developer tool hitting the same environment, that means two different cost models are running in parallel, and a licensing conversation that used to be a single line item now needs to account for which client is making which call.

What to check before this goes into a proposal

Confirm which specific tools a client actually needs before assuming both servers are required. A workflow that only needs lead qualification and outreach drafting may never need Dataverse MCP write access at all, which simplifies both the security review and the licensing conversation considerably. Where write access genuinely is required, treat the admin center toggle and client allow-listing as a discrete deployment step with its own change ticket, not an assumed side effect of installing an MCP client. And build the Copilot credit cost of both servers into a pilot’s budget from day one, since credit consumption for generative tools scales with usage in a way that a fixed per-seat license does not.

Teams at Routeget Technologies have walked several clients through exactly this two-server design decision over the past few months, mostly because the documentation, while accurate, spreads the full picture across three or four separate Learn pages that don’t obviously reference each other. Getting the architecture right the first time saves a rework cycle that otherwise shows up a few weeks into a pilot, right around the point someone asks the agent to actually change a record instead of just describing one.

#DynamicsSalesMCP #DataverseMCP #AIinCRM #CopilotStudio #EnterpriseAI #D365SalesArchitecture

The Business Central SOAP Retirement Deadline Is Closer Than It Looks

IT director reviewing a systems integration architecture diagram on a monitor in a modern office

The Business Central SOAP Retirement Deadline Is Closer Than It Looks

An IT director doing an annual vendor risk review recently found an integration nobody on her team remembered building. A bank feed connector, installed years earlier by a consultant who has long since moved on, was quietly pulling transaction data into Business Central through a SOAP endpoint pointed at a standard Microsoft page. It had run without incident since before her tenure started. The discovery only mattered because of one line buried in a Microsoft release note: that endpoint, and every other SOAP connection built the same way, stops working the moment Business Central version 29 reaches general availability in the first week of October 2026.

That is the practical shape of the Business Central SOAP retirement. It is not a single dramatic cutoff so much as the final step in a multi-year phase-out that a lot of IT teams filed away as a developer’s problem and never revisited. Microsoft introduced a feature key called “Disable SOAP web services on Microsoft UI pages” in the 2025 release wave 1 update, version 26, and it has been switched on by default ever since, blocking any new attempt to publish a standard Microsoft page as a SOAP endpoint. What made that default setting survivable for older integrations was the fact that an administrator could still go into Feature Management and turn the key back off, keeping the legacy behavior alive. Version 29 removes that feature key entirely. Once it is gone, there is no setting left to flip back on, and any integration still pointed at a Microsoft UI page over SOAP simply stops receiving responses.

The Business Central SOAP Retirement Only Touches Microsoft’s Own Pages

The scope here matters more than the deadline itself, because it is easy to overreact or underreact depending on how the news reaches you. What is actually being removed in version 29 is narrower than “SOAP support in Business Central.” Microsoft’s own justification, stated plainly in its developer documentation, is that a UI page was never designed to function as a stable API contract: a field can move, a control can be renamed, and none of that counts as a breaking change from Microsoft’s perspective, even though it can silently break an integration built directly against that page’s SOAP surface. So the retirement targets exactly that pattern: standard, out-of-the-box Microsoft pages exposed as SOAP web services.

Two other patterns are not affected by this particular change. SOAP endpoints built on codeunits keep working, since a codeunit is intentionally structured as a stable interface rather than a UI surface. SOAP endpoints built on custom, per-tenant extension pages also continue to function, because your organization controls that page’s schema and accepts responsibility for changes to it. If your integration inventory turns out to be built entirely on one of those two patterns, version 29 will not touch it. Many organizations, though, will find that at least one long-running integration, often the oldest one, was built the simple way: pointing directly at a Microsoft page because that was the path of least resistance when someone set it up years ago.

Abstract illustration of a legacy data connector being replaced by a modern API connector

The Stopgap That Isn’t a Real Exemption

Microsoft’s own migration guidance includes an option that looks like an easy out: copy the source of the affected Microsoft page into a per-tenant extension, republish that copy as your own page, and expose the copy as a SOAP endpoint instead. Technically, this works, and it buys time without touching whatever consumes the integration on the other end. It is worth treating as exactly what it is, a stopgap, and not as a long-term architectural decision.

Two things argue against leaning on it permanently. First, you now own and maintain that copied page yourself, including any future logic changes Microsoft makes to the original that you will need to track and replicate by hand, which is precisely the maintenance burden the API-first approach was designed to avoid. Second, this is not the only deprecation moving through the same pipeline. Microsoft has already issued the equivalent warning for exposing Microsoft UI pages as OData endpoints, with removal currently targeted for the 2027 release wave 1 update, version 30. The pattern is consistent: UI-page-based web services of any protocol are being phased out in favor of purpose-built API pages and queries. A team that spends its 2026 budget re-platforming a SOAP integration onto a per-tenant extension, rather than onto a proper API page, is likely to be back doing similar work again in 2027 for the same underlying reason.

What This Means for Your Integration Portfolio

For a CIO or IT director, the practical risk is less about any single connector breaking and more about not knowing how many connectors exist in this pattern in the first place. SOAP-based integrations against Microsoft pages tend to cluster in a few high-value, low-visibility categories: bank statement and payment feeds set up early in an ERP implementation, EDI order intake with a long-standing trading partner, warehouse scanning or shop-floor tools built from an older sample or tutorial, and ISV add-ons purchased years ago from a vendor who may or may not have modernized their own connector since. None of these show up on a typical application inventory unless someone specifically goes looking for the transport protocol underneath them, which is exactly why this kind of deprecation tends to surface as an incident rather than as a planned project.

The financial exposure is concentrated, not diffuse. A broken bank feed means a manual reconciliation process returns overnight, right when finance least wants to discover it. A broken EDI intake means orders stop flowing from a partner who is unlikely to be sympathetic to an internal software upgrade as an excuse. Compare that to, say, a reporting dashboard built the same way, where a short outage is an inconvenience rather than a revenue event. Triage should follow that same logic: not every SOAP endpoint deserves equal urgency, but the ones tied to cash and order flow deserve attention well before the October deadline, not the week of it.

A Practical Sequence Before October

The starting point is visibility, not migration. Business Central logs incoming web service requests, and that telemetry can be pulled to show exactly which endpoints are being called, how often, and by page or codeunit type, before anyone commits engineering time to fixing something that may not even be at risk. From there, the sequence is straightforward in outline even if the execution takes real effort: separate the SOAP calls hitting Microsoft UI pages from those hitting codeunits or per-tenant extensions, since only the first category is on the clock; rank the affected integrations by business impact rather than by ease of fixing them, so a low-effort reporting connector does not quietly jump the queue ahead of a bank feed; and for anything ranked high, start the conversation with whoever owns the other end of the integration; internal developer, systems integrator, or third-party vendor, well before the release actually lands, since REST API pages or OData V4 endpoints for the same data may already exist and simply were never adopted when the integration was first built.

For integrations tied to a purchased ISV app, it is worth a direct question to the vendor rather than an assumption either way: ask specifically whether their connector talks to Business Central over SOAP against a standard page, and if so, what their own migration timeline looks like. A vendor who has not addressed this yet is effectively asking your organization to inherit their technical debt on their schedule, not yours.

Treat This as a Cleanup Project, Not a Fire Drill

The organizations that come out of this in good shape are the ones that treat the Business Central SOAP retirement as the forcing function for an integration inventory they should have had anyway, rather than as an isolated ticket to close before a deadline. We have seen the alternative version of this play out with prior Business Central deprecations: a scramble in the final weeks, a rushed fix that solves the immediate protocol problem without addressing the underlying design, and the same conversation repeating itself at the next deprecation cycle. Version 29 is a good moment to ask the larger question once, properly, rather than answering the narrow one twice.

#BusinessCentral #SOAPRetirement #ERPIntegration #APIModernization #IntegrationGovernance #DigitalTransformation

The Warehouse App V3 to V4 Migration Is an Infrastructure Project, Not an App Update

Warehouse worker scanning a barcode with a handheld mobile device in a distribution center

A distribution center running a fleet of Zebra handhelds on the Warehouse Management mobile app got a call from the floor supervisor in late July: barcode scans on inbound receiving were suddenly failing on about a third of devices, right after an over-the-air Android update pushed through despite the fleet being enrolled in Intune with update deferrals configured. The IT team opened a support ticket. The answer that came back wasn’t a patch. It was a reminder that the app on those devices, version 3, had been out of support since May, and the fix wasn’t going to be a hotfix to V3. It was going to be the V3 to V4 migration the team had scheduled for “sometime in Q3” and then quietly let slide.

That scenario is playing out at more distribution operations than Microsoft’s release notes would suggest, because the framing around this migration has made it sound smaller than it is. Under the hood, this isn’t a UI refresh. Microsoft rebuilt the Warehouse Management mobile app from scratch, moving it off Xamarin, a framework Microsoft itself retired from general support back in 2024, and onto React Native. That single architectural fact explains almost everything else about why this migration behaves differently from a normal app update, and why solution architects planning a fleet rollout need to treat it as an infrastructure project rather than an app-store bump.

Why This Isn’t a Simple App Update

Xamarin’s own end of life is the real driver here, not a desire to add dark mode. A framework built on Mono and .NET for cross-platform mobile development, Xamarin stopped receiving Microsoft support in May 2024, which put every product still built on it, including the warehouse app, on a clock. React Native gets Microsoft a modern, actively maintained foundation, and it shows up concretely in the release cadence: since V4’s staged rollout completed in early 2026, point releases have shipped roughly monthly, each carrying real functional changes rather than just security patches.

The rewrite also changed the authentication stack, replacing legacy libraries with MSAL and OneAuth, and that change has consequences that have nothing to do with barcode scanning. On Windows, the redirect URI registered in Azure AD app registrations needs to include ms-appx-web://microsoft.aad.brokerplugin/{clientId} for the broker flow to work. For on-premises deployments authenticating through AD FS, both Windows and Android need new redirect URIs registered before a single device can sign in to V4, which means this migration touches identity configuration owned by a different team than the one running the warehouse floor, and that handoff is where a lot of rollouts stall.

Abstract visualization of a mobile device platform migration on a handheld scanner screen

What Actually Breaks During a V3 to V4 Migration

Three things trip up fleet migrations that the high-level release notes gloss over, and all three are worth budgeting time for before a rollout window opens rather than during it.

The first is device eligibility. V3 supported Android 5 and later, while V4 requires Android 7. Any handheld still running Android 5 or 6, which is not unusual in a warehouse fleet with a five-to-seven-year hardware refresh cycle, simply cannot run V4 and has to keep running V3 until it’s replaced. That forces a mixed-fleet reality during the transition window: V3 and V4 can run side by side on different devices without conflict, but they cannot coexist on the same device, so the migration has to be planned and executed per device, not as a single global cutover.

The second is the iOS experience, which behaves noticeably worse than Android or Windows during migration. On those two platforms, connection settings carry over automatically from V3 to V4 as long as the device was already on V3 version 3.0.8 or later before the switch. On iOS, none of that carries over. Every connection has to be manually reconfigured after installing V4, and Device Code authentication, which a lot of iOS deployments relied on, isn’t supported in V4 at all; iOS is limited to username and password. The practical workaround worth building into a migration plan is generating QR codes or JSON configuration files ahead of time for each site or device group, so floor staff aren’t hand-typing server URLs and warehouse codes on a phone screen during a go-live window.

The third is the support-window structure itself, which changed again after V4 launched. Starting with version 4.1.1.0, Microsoft introduced a rolling twelve-month support window, effective May 2027, meaning only V4 releases published within the previous twelve months are eligible for support at any given time. A fleet migrated to V4 in early 2026 and left untouched will fall out of that support window well before 2027 arrives, so the actual deliverable of this project isn’t “get to V4.” It’s “get to V4 and keep a patch cadence going,” which is a different kind of ongoing commitment than most IT teams budget for an app migration.

A Practical Migration Sequence

The sequence that has worked cleanly across the fleet migrations worth learning from starts with an inventory, not an install. Pull every device’s current OS version and current app version before scheduling anything, because that inventory determines three separate migration paths: devices already eligible for direct upgrade, devices that need a V3 update to 3.0.8 or 3.0.9 first to preserve their configuration, and devices that need hardware replacement before they can run V4 at all.

For the Android and Windows devices in the first two paths, the upgrade itself is close to routine: push the V4 install through Intune or another MDM tool without uninstalling V3 first, since choosing the in-place upgrade path is what preserves the existing connection settings. Stage this in waves by site or by shift rather than as a single fleet-wide push, because the one-time reauthentication requirement per device means a help desk fielding sign-in questions from three hundred devices simultaneously is a bad night for everyone involved, whereas fifty devices at a time is manageable.

For iOS, treat it as its own project inside the larger migration rather than an afterthought. Confirm every affected user has username and password credentials provisioned before the cutover, since Device Code won’t be available as a fallback. Build the QR code or JSON configuration files in advance, and consider disabling auto-update on iOS devices until those configuration artifacts are ready, so a device doesn’t land on V4 mid-shift with no way to reconnect.

Keep the rollback path in mind but don’t lean on it as a safety net for the whole fleet. Individual devices can be downgraded to V3.0.9 if V4 surfaces a blocking issue during testing, which is useful for a pilot group, but Microsoft has been clear that once a region has fully migrated, that region-level rollback isn’t available. Pilot on a genuinely small, representative slice of the fleet, not just the devices sitting on IT’s desk.

Closing the Loop After Go-Live

The migration doesn’t end when the last device reports in on V4. Recent point releases have shipped capability that’s worth actively adopting rather than ignoring once the fleet is stable: a ProGlove arm scanner bridge for hands-free scanning workflows, editable client settings that let enterprise environments enforce TLS 1.2 and forced sign-in policies centrally, and expanded barcode format support including GS1 batch number separators that some receiving workflows depend on. None of that shows up automatically; it requires staying inside that rolling twelve-month support window Microsoft built into the V4 support model, which means assigning someone ownership of the update cadence the same way a team would own patch management for any other production system.

Routeget has run this exact device-inventory-first sequencing for several clients moving mixed Android and iOS fleets this year, and the pattern holds: the migration itself is mechanical once the inventory and identity prerequisites are sorted out. What actually determines whether it goes smoothly is whether someone treated it as an ongoing operational commitment from the start, rather than a one-time app-store update to check off a list.

#WarehouseManagementApp #DynamicsSCM #MobileFleetMigration #XamarinToReactNative #ERPGovernance #SupplyChainAutomation

Copilot Studio Harness Billing: The Free Pilot Period Just Ended

Finance director reviewing cost dashboards for Copilot Studio agent billing

A finance team at a mid-size distributor spent the summer letting two developers experiment with autonomous agents in Copilot Studio: one to triage vendor invoices, another to reconcile shipping exceptions against purchase orders. Nobody logged the hours. Nobody tracked the credits, because there were none to track. Then, on September 1, 2026, Copilot Studio harness billing changed for exactly this kind of pilot, and both agents started drawing against the tenant’s Copilot Credit pool without a single line of configuration having moved. The invoice for October will look different than the one for September, and the person who approves it may have no idea why.

This is not a hypothetical. Microsoft’s own admin guidance for this change tells organizations to go looking for agents they may have forgotten existed, which is a reasonable ask only if someone already knows to look. For CIOs, CFOs, and IT directors who greenlit a handful of “let’s just see what this can do” pilots earlier in the year, the practical question is no longer whether Copilot Studio’s most capable harness is worth adopting. It is whether the agents already running under it are quietly becoming a budget line nobody planned for.

What Copilot Studio harness billing actually changed on September 1

Copilot Studio ships three distinct harnesses, and the distinction matters more than most licensing conversations acknowledge. A harness, in Microsoft’s own framing, is the runtime layer that sits between an agent’s design and the underlying model: it decides when to call the model, what to hand it, how to interpret what comes back, and which tools to invoke on the agent’s behalf. The Standard harness is deterministic. It follows predefined topics and prompts and behaves the same way every time, which is exactly what you want for a help desk bot answering a known set of questions. The Copilot Chat harness is narrower still, built to ground Microsoft 365 Copilot Chat in an organization’s own content for internal, employee-facing scenarios.

The GitHub Copilot harness is a different animal entirely. It reasons autonomously toward a goal rather than following a script, breaks a task into steps on its own, retries and reroutes when something fails, and can read, edit, and reason over Word, Excel, PowerPoint, and PDF files as part of completing a task. It also supports skills and persistent memory, and runs in a secure sandbox designed for multi-step business processes: an accounts payable agent that reads an invoice, matches it to a purchase order, and routes an exception is the kind of thing Microsoft built this harness to handle. It reached general availability on August 3, 2026, and from that date forward, the billing model was unambiguous: authoring, testing, and evaluating an agent all consume Copilot Credits, not just its published, end-user traffic. The meter starts the moment someone starts building.

What was less obvious is what happened to agents and workflows that existed before that date, built during an earlier preview window when this kind of usage did not consume credits at all. Microsoft’s answer arrived on September 1: those pre-GA agents and workflows, including anything sitting in a Dev or Trial environment, now consume Copilot Credits too, for both the ongoing authoring work a maker does on them and their runtime execution. Standard harness and Copilot Chat harness agents are unaffected. This is specifically about closing the gap between agents that got a free head start during preview and the GA billing model everyone built after August 3 has already been living under.

Why this is a governance problem before it is a cost problem

The credit economics themselves are not exotic once you understand them. Copilot Credits can be drawn from prepaid capacity, priced at roughly $200 per month for 25,000 credits, or purchased pay-as-you-go through an Azure subscription at $0.01 per credit, a rate that runs about 25 percent higher than the prepaid tier. Microsoft’s admin tooling in the Power Platform admin center lets you set a monthly consumption ceiling per agent, with two guardrails: a notification as usage approaches the limit, and a hard stop that disables the agent once it’s reached. Overages beyond an agent’s allocation can either draw from a shared tenant pool or bill against a linked pay-as-you-go plan, and a monitoring dashboard shows month-to-date billed credits per agent alongside a twelve-month trend.

Laptop screen showing an administrative usage and credit consumption dashboard

None of that is the hard part. The hard part is that the September 1 change makes cost visibility retroactive for a category of agent that, by design, was never supposed to need it. A pilot built in July to test whether autonomous reasoning could handle exception routing was, at the time, a genuinely low-stakes experiment. Nobody assigned it an owner with a mandate to monitor consumption, because there was nothing to consume. That agent may still be running today, quietly reprocessing the same exceptions it was built to test, and as of this month it is drawing against the same credit pool as anything built deliberately for production. Multiply that by however many “quick pilot” agents a mid-size enterprise typically accumulates across finance, HR, and operations teams over six months, and the exposure is not a single line item. It is an unknown number of them, some of which may not even have an active business owner anymore.

What to check before the next invoice arrives

Microsoft’s own recommendation is a reasonable starting point: pull historical, non-billed Copilot Credit consumption data from the Power Platform admin center to understand what these agents were actually doing before billing applied to them, and use that history to identify which GitHub Copilot harness agents and workflows exist across every environment, including the Dev and Trial environments that pilots tend to live in and get forgotten in. That inventory step matters more than it sounds like it should, because Dev and Trial environments are exactly where governance attention typically does not reach; they are treated as sandboxes precisely because nothing in them used to cost money.

Once that inventory exists, the decision for each agent is binary and should be made deliberately rather than by default. An agent that proved its value during the pilot period should be formally adopted: given an owner, a consumption ceiling with both guardrails enabled, and a place in whatever ALM process governs production agents. An agent that was built to answer a question that has already been answered, or that nobody has looked at since July, should be retired outright rather than left running under the assumption that “it’s probably fine.” The cost of leaving a stale pilot alive is no longer zero, and the credit allocation and access controls that make sense for a small number of intentional, production-grade autonomous agents do not scale gracefully to an undefined number of forgotten ones.

There is a broader lesson in how this rolled out. Microsoft made the GA billing model clear from day one for anything built after August 3, and it gave organizations a full month, not a surprise cutover, before extending that model backward to preview-era agents. That is a fair way to manage a transition. But it also means the responsibility for knowing which agents exist and what they’re doing sat with each tenant the entire time, and plenty of tenants were not positioned to carry it. As autonomous, credit-metered agents become a bigger part of how Dynamics 365 and Power Platform environments get extended, the organizations that treat agent inventory and consumption governance as a standing discipline, not a one-time reaction to a billing announcement, are the ones that won’t be surprised by the next change like this one. Routeget Technologies has been walking clients through exactly this kind of Copilot Studio environment audit over the past several weeks, and the pattern holds: the agents nobody remembers building are almost always the ones costing the most to leave running.

#CopilotStudio #AgenticAI #GitHubCopilotHarness #CopilotCredits #ITCostGovernance #EnterpriseAI