Dataverse Long-Term Retention Can Cut Your F&O Storage Bill in Half. It Doesn’t Keep Your Encryption Key.

IT and finance leaders reviewing a Dataverse storage capacity dashboard in a boardroom

A CFO reviewing next year’s Power Platform renewal usually finds the same line item growing faster than anything else on the invoice: Dataverse database capacity. For a Dynamics 365 Finance and Supply Chain Management customer with a few years of general ledger, tax, inventory, and sales order history behind it, that growth is not a mystery. Transactional tables in F&O apps do not shrink on their own, and every fiscal year adds another layer of records that almost nobody queries but that the platform still has to store, index, and back up at full price.

IT’s answer to that problem usually arrives as a single line in a capacity review deck: turn on Dataverse long-term retention and archive the old transactions out of the live database. It is a real fix, and Microsoft’s own numbers back it up. But the conversation tends to stop there, before anyone asks the question a security or compliance lead should be asking, which is what happens to the encryption key protecting that data once it moves.

Why F&O Capacity Grows Faster Than the Budget Assumes

Dataverse long-term retention, sometimes shortened to LTR, lets an organization move inactive records out of live application tables into a separate, read-only retention layer that still lives inside Dataverse and is still governed by Microsoft Entra ID. For Finance and Supply Chain Management specifically, Microsoft currently supports archiving general ledger transactions, tax transactions, inventory transactions and journals, sales orders, and Commerce transactions this way. Attachments are explicitly excluded for now.

The financial case is straightforward once you see the compression numbers. Microsoft states that data moved into Dataverse long-term retention consumes roughly half the capacity of the same data sitting in a live table, and when the F&O-specific archive process goes a step further and migrates that data into history tables rather than leaving it only in retention, the history-table footprint can run closer to 30 percent below the original. At a commonly cited list price of roughly 40 dollars per gigabyte per month for Dataverse database capacity, an organization sitting on several hundred gigabytes of aging general ledger and inventory history is not looking at a rounding error. It is looking at a five- or six-figure annual number that a straightforward archive policy can meaningfully cut, without touching a single report a controller actually runs day to day.

That is the pitch that gets this feature onto a roadmap. It is also, on its own, an incomplete pitch.

What Dataverse Long-Term Retention Actually Does, and How Long It Takes

The mechanics matter for planning purposes, not just for understanding the technology. Microsoft’s documentation describes the F&O archive process as a sequence of stages: replication of records into Dataverse long-term retention, marking of records that meet the retention policy’s criteria, reconciliation to confirm every record made it across intact, and finally migration, where the data is moved into history tables and removed from the live application tables. Only after that full sequence completes does the capacity reduction actually show up in reporting, and Microsoft’s own timeline for that is seven to fourteen days depending on data volume, with archival jobs deliberately run at lower priority than normal application workloads.

There is a detail buried in that same documentation that tends to surprise architects who assume large-scale platform jobs run in parallel by default: they do not, here. Microsoft states plainly that the stages of the F&O archival process “run sequentially in the background.” If you are planning to archive several years of general ledger, tax, and inventory history in the same cycle, that sequencing, not the compression ratio, is what actually determines how long your capacity relief takes to land. A rollout plan built around a single “flip the switch and wait a week” assumption is usually wrong by a factor of several weeks once multiple table types and several years of backlog are involved.

None of that is disqualifying. It is simply the kind of operational detail that belongs in a project timeline, not a surprise a program manager discovers in week three.

The Encryption Question That Actually Changes the Decision

Close-up of a compliance professional reviewing an encryption key management interface on a laptop

Here is where the conversation should slow down before a decision gets made, particularly for regulated industries such as financial services, healthcare, government contracting, or any organization with a contractual or regulatory commitment to control its own encryption keys.

Microsoft Power Platform has moved through two generations of customer-controlled encryption. The older mechanism, generally referred to as bring your own key or BYOK, is now explicitly positioned by Microsoft as a legacy predecessor to the current customer-managed key, or CMK, model. That distinction is not cosmetic. Microsoft’s own migration guidance states that environments still running the legacy BYOK encryption model are locked out of a specific list of newer Dataverse capabilities until they migrate to CMK, and Dataverse long-term data retention is on that list, alongside elastic tables, Dataverse search, AI Builder, and several others. An organization that has not made the BYOK-to-CMK move simply cannot turn retention on yet.

For organizations evaluating the F&O-specific archive path directly, Microsoft’s own archive documentation adds a second, sharper detail. It states that customers using the legacy BYOK model should be aware that data moved into Dataverse long-term retention is encrypted with a Microsoft-managed key rather than the customer’s own key, and it recommends migrating to customer-managed key as a result. Read carefully, that is Microsoft telling its own customers that the encryption custody model can change the moment data crosses from a live table into the archive, unless the tenant has already completed the CMK migration first. It is worth noting that the guidance itself is not fully explicit about whether this applies only to tenants still on the older model or to every tenant regardless of current key configuration, and a security team relying on this feature for a compliance commitment should confirm the current behavior for their specific tenant and encryption configuration directly with Microsoft before treating archived data as covered by the same key custody guarantee as their live data.

For a business that markets its own data handling on the strength of customer-held encryption keys, whether to a regulator, an auditor, or a customer contract, that is not a footnote. It is a governance gap that needs to close before the capacity-savings project starts, not after an auditor asks where the archived general ledger data actually lives and under whose key.

Sequencing the Decision Correctly

The organizations that get this right treat Dataverse long-term retention as a governance initiative with a cost-savings side effect, not the other way around. That means confirming current encryption status first: whether the tenant is still on legacy BYOK, already on CMK, or using Microsoft-managed keys by default, since only the first case actually creates a conflict. It means building the CMK migration, if one is needed, into the project plan ahead of the retention policy rollout rather than in parallel with it, since Microsoft’s own guidance describes CMK migration as something that can happen without contacting Microsoft support, which removes one common excuse for delay. And it means setting expectations with finance leadership that the capacity savings materialize over a multi-week sequential process per table type, not overnight, so the budget conversation is not built on a timeline the platform cannot actually deliver.

We at Routeget Technologies have walked F&O customers through exactly this sequencing, and the pattern holds consistently: the technical archive configuration itself is the easy part. The harder, more valuable conversation is the one between IT, finance, and compliance about what “the data is still in Dataverse” actually means once the key protecting it is no longer necessarily the one the organization chose.

The capacity savings on a Dataverse long-term retention rollout are real, and for an F&O environment with years of transactional history, they are often large enough to justify the project on cost grounds alone. But the encryption question is not a technicality to resolve after the fact. It is the first question a CIO or CFO should ask before the retention policy goes live, and the answer determines whether this is a two-week configuration task or a multi-month project that starts with a key migration.

#DataverseRetention #CustomerManagedKey #BYOKMigration #DynamicsFinanceOps #ERPCostOptimization #CloudArchitecture

Power BI Copilot’s Bill Isn’t a License. It’s Fabric Copilot Capacity You Share.

IT and finance leaders reviewing an enterprise Fabric capacity billing dashboard for Power BI Copilot usage

A CFO at a manufacturing group running Dynamics 365 Finance and Supply Chain recently signed off on an F64 Fabric capacity so the FP&A team could start using Power BI Copilot to draft variance commentary and summarize demand forecasts. Three weeks later, an IT director flagged something the approval memo never mentioned: two hundred report viewers across the business no longer needed Power BI Pro licenses at all. That wasn’t a bug or a surprise discount. It was a separate Fabric licensing rule that happens to kick in at the exact same capacity size Copilot is often recommended for, and the two get conflated constantly in vendor pitches and budget spreadsheets alike.

That conflation is the real problem for anyone trying to budget a Power BI Copilot rollout against a Dynamics 365 reporting program. Copilot in Power BI is not a per-seat add-on the way Microsoft 365 Copilot is. It is billed against Fabric capacity consumption, measured in capacity units, and organizations can even designate a specific Fabric Copilot capacity purely to centralize that billing. Whichever capacity ends up holding that designation is shared with every other Fabric workload your organization runs on it. Getting the cost model wrong in either direction, assuming it is included in your existing Pro licenses, or assuming it behaves like a fixed monthly fee, leads to budget requests that are either laughably low or defensively padded past what the workload actually needs.

IT and finance leaders reviewing an enterprise Fabric capacity billing dashboard for Power BI Copilot usage

What Copilot Actually Consumes, and Why the Rate Card Looks Strange

Microsoft’s own Fabric documentation describes Copilot consumption in capacity unit seconds, priced per 1,000 tokens, and the input and output rates are not the same. Input prompt tokens consume 100 CU seconds per 1,000 tokens, cached input tokens (system instructions, schema context, and conversation history that Fabric automatically caches without any configuration) consume only 10 CU seconds per 1,000 tokens, and output tokens, the actual generated text, consume 400 CU seconds per 1,000 tokens. That four-to-one gap between input and output pricing matters in practice: a Copilot-generated narrative summary of a Dynamics 365 SCM inventory report produces far more output tokens than the prompt that requested it, so output pricing dominates the bill.

Take a request with 2,000 input tokens and 500 output tokens, a reasonably typical size for a Copilot-drafted commentary on a Power BI report built over Dataverse or F&O entity data. The math works out to (2,000 × 100 + 500 × 400) ÷ 1,000, which is 400 CU seconds, or roughly 6.67 CU minutes. On its own that number means nothing to a finance leader. What it means in context is the second thing worth understanding: how that consumption gets classified against your capacity.

Background Job Smoothing Changes the Real Exhaustion Risk

Microsoft classifies Copilot operations as background jobs rather than interactive ones, and background jobs get smoothed over a 24-hour window instead of the 5-minute window used for interactive report rendering. Throttling only begins once the capacity has already committed all of its available CU budget for the next 10 minutes. Microsoft’s own documentation walks through this with an F64 example: an F64 SKU carries 64 × 24, or 1,536, CU hours in a single day. A single Copilot request consuming roughly 6.67 CU minutes works out to about 0.11 CU hours, which means an F64 capacity could theoretically absorb well over 13,000 such requests before exhaustion, assuming nothing else on that capacity is consuming CU budget at the same time.

That last clause is where the real governance risk sits, and it’s a genuinely different risk than “Copilot is expensive.” When capacity is exhausted, Microsoft’s documentation is direct about the consequence: all operations shut down, not just Copilot. If your Dynamics 365 reporting workspace, your dataflows, your semantic model refreshes, and your Copilot usage all live on the same Fabric capacity, and a finance analyst runs an unusually large batch of Copilot-assisted narrative generation during month-end close, everyone else’s scheduled refreshes and interactive reports can stall on that same capacity at the same time. This is an argument for isolating Copilot consumption onto its own designated capacity rather than an argument against adopting it at all, and Microsoft built a specific mechanism for exactly that.

Financial analyst working at a dual-monitor desk with Power BI analytics dashboards

The Fabric Copilot Capacity Designation Is Not the Same Thing as F64

Since April 2025, Microsoft has allowed organizations to designate any capacity of F2 or larger, not just F64 and above as originally required at the January 2025 preview launch, as a dedicated “Fabric Copilot capacity.” A Fabric admin enables Copilot for the organization, authorizes a capacity admin to make that designation, and the capacity admin then assigns user groups whose Copilot usage should bill there instead of wherever their content happens to be hosted. Once that’s done, no further action is needed. Users assigned this way can be on Pro, PPU, Trial, Premium capacity, or Fabric capacity license modes, though Embedded is explicitly not supported.

This solves a specific budgeting problem: without it, Copilot costs get spread across whatever capacity holds each user’s content, which makes centralized cost tracking nearly impossible for an IT Director trying to build a clean Copilot line item. With a designated Copilot capacity, every dollar of Copilot consumption lands in one place on the bill, separate from your Dynamics 365 reporting workspace’s own capacity consumption for refreshes and interactive use. Worth noting for architects planning this out: Fabric Copilot on other workloads (Data Factory, Data Engineering, Data Warehouse, Data Science, Real-Time Intelligence, and Activator) is only available on capacities smaller than F64, while Power BI Copilot specifically remains available regardless of capacity size. If your organization runs Copilot across multiple Fabric experiences, not just Power BI, that asymmetry affects which capacity size you actually want for the designation.

Why the F64 Threshold Gets Conflated With Copilot Pricing, and Why That Matters for Your Budget

Separately from anything Copilot-related, Microsoft’s Fabric licensing model has long included a straightforward rule: on any F SKU smaller than F64, every person viewing Power BI content needs a Pro, PPU, or individual trial license. At F64 or larger, a user with only a free Fabric license can view content, provided they hold a viewer role on the workspace. This rule exists independent of Copilot and predates Copilot’s current billing model by a wide margin. It’s an artifact of how Microsoft licenses Power BI content consumption at scale, not a Copilot feature.

The reason this matters for a CFO’s budget conversation is that vendors and consultants routinely present F64 as “the tier where Copilot gets cheap,” when the more accurate framing is that F64 is where per-viewer Pro licensing gets cheap, and Copilot’s own cost is a completely separate, consumption-based line that scales with usage regardless of which SKU size you land on. An organization with two hundred report viewers and modest Copilot usage might genuinely benefit from an F64 capacity purely for the license consolidation, independent of whether Copilot ever gets turned on. An organization with heavy Copilot usage across a small number of power users, finance analysts drafting narrative variance reports all day, might be better served by a smaller designated Copilot capacity and leaving Pro licensing exactly where it is. These are two different decisions being made to look like one decision, and separating them is the actual budgeting exercise.

What This Means for a Dynamics 365 Reporting Rollout

For an IT Director or CFO evaluating Power BI Copilot against Dynamics 365 Finance, Supply Chain, or Customer Engagement reporting, start by quantifying how many people will actually draft Copilot-assisted narratives, distinct from how many simply view the resulting reports, since those two populations drive different cost levers entirely. From there, model consumption using the token rates above against your actual reporting cadence rather than a vendor’s generic estimate, since output-heavy use cases like automated commentary generation consume capacity differently than short, targeted Q&A against a semantic model. Finally, decide separately whether an F64-or-larger capacity makes sense for license consolidation, and treat that as independent from whichever capacity you designate for Copilot billing.

Fabric’s list pricing follows the capacity unit count linearly, so an F64 capacity costs roughly thirty-two times an F2 capacity’s pay-as-you-go rate, and Microsoft’s own reservation pricing page states that a one- or three-year commitment can reduce that rate by roughly 41 percent compared to pay-as-you-go. Given how directly usage scales with cost here, that reservation discount is worth pricing into any multi-quarter Copilot rollout plan rather than treating it as an afterthought once the pilot succeeds.

None of this makes Power BI Copilot a bad investment for a Dynamics 365 reporting program. It makes it a capacity planning exercise with its own governance questions, closer to provisioning compute than provisioning software seats. Organizations that treat it as the latter tend to either under-budget it or, more commonly, over-provision a capacity size for reasons that had nothing to do with Copilot in the first place. It’s the kind of distinction our team at Routeget Technologies walks clients through before a single dollar of Fabric capacity gets provisioned, since separating the licensing decision from the consumption decision up front is what keeps a Copilot rollout from turning into an unplanned line item six months later.

#PowerBICopilot #FabricCapacity #CopilotCostGovernance #DynamicsFinanceOps #EnterpriseAI #FinanceTransformation

The Power Pages Enhanced Data Model Migration Tool Reached GA. The Four Templates That Couldn’t Move Now Can.

Solution architect reviewing data migration dashboards on a dual-monitor workstation in a modern office

The Migration That Kept Getting Delayed

If you have maintained a Dynamics 365 Customer Self-Service, Partner, Community, or Employee Self-Service portal since before the Power Pages rebrand, you have almost certainly run into this wall: everything Microsoft has shipped for Power Pages application lifecycle management over the last three years, solutions support, Power Platform pipelines, environment variables, faster provisioning, has applied only to sites built on the enhanced data model. Your site, built on the standard data model with its familiar adx_ prefixed tables, has been sitting outside that perimeter the entire time. You could read every announcement, watch every demo, and still not be able to touch any of it, because the migration tooling that was supposed to bring your site along explicitly excluded the four Dynamics 365 portal templates. That changed on September 7, 2026, when Microsoft moved the standard-to-enhanced data model migration utility in the Power Platform CLI to general availability and, for the first time, extended it to Customer Self-Service Portal, Employee Self-Service Portal, Community Portal, and Partner Portal sites.

This is not a small technical footnote. For a lot of organizations running production portals on these templates, it is the first realistic path off a data model that Microsoft has been quietly deprecating in practice, if not in name, since 2023.

What the Standard Data Model Was Actually Costing You

The distinction between the standard and enhanced data models is not cosmetic. On the standard data model, website configuration lives in a set of legacy adx_ entities: adx_webpage, adx_webrole, adx_weblink, and so on. Those tables were never built for the deployment discipline that modern ALM assumes. Configuration changes get made directly against a live environment, promotion between environments means manually reconciling records or wrestling with unmanaged solution exports, and Microsoft has to maintain backward compatibility with a table structure that predates Dataverse solution awareness altogether. The enhanced data model consolidates that configuration into the newer powerpagecomponent table structure, which is solution-aware, supports environment variables, and plugs directly into Power Platform pipelines. Sites on the enhanced data model also provision faster and pick up feature and security updates automatically, rather than waiting on package installs that someone on your team has to remember to schedule.

None of this was news. What was missing, until this month, was a supported way to get an existing site there without rebuilding it from scratch. Microsoft’s own documentation was blunt about the gap as recently as March 2026, stating outright that sites created with the four Dynamics 365 templates could not be migrated and that only new sites on those templates would land on the enhanced data model. If you were running a production Partner Portal from 2021, your only two options were live with the limitation indefinitely or replatform the entire site.

What the Enhanced Data Model Migration Utility Shipped at GA

The migration utility itself is not new. Microsoft first previewed pac powerpages migrate-datamodel back in April 2024, and it worked reasonably well for the templates it supported: starter layouts, application processing, blank page builds, program registration, and scheduling sites. What reached general availability on September 7 is both a maturity milestone and a scope expansion. The scope expansion is the four Dynamics 365 templates finally being added to the supported list, which is the headline for most technical teams reading this. The maturity milestone is three specific capabilities that were not reliable enough to trust in preview: a genuinely useful customization dependency report that tells you what will break before you commit to anything, a status-check command so you are not guessing whether a large migration job is still running or has stalled, and a formal rollback path if validation turns something up after the data has moved.

Running the migration itself still follows the same sequence architects who piloted the preview will recognize. You authenticate against the target environment, generate a customization report scoped to a specific website ID, and read that report closely before doing anything else, since it is the tool telling you exactly which of your customizations depend on tables that will not exist in the same form once you move. From there, you migrate configuration data and, separately, transactional data referencing that configuration, using mode flags that let you split the work rather than attempting a single all-or-nothing pass. A status-check command lets you monitor long-running jobs on sites with meaningful data volume, and only once you are satisfied do you run the command that actually switches the site over to serve from the enhanced data model record. The CLI now requires Power Platform CLI 2.11.2 or later, along with updated Dataverse base portal and Power Pages core packages, so confirm your tooling versions before you start rather than discovering a version mismatch mid-migration.

Close-up of a developer typing CLI migration commands with terminal windows and a data flow diagram in the background

The Five Things That Will Actually Break

The customization report is useful precisely because most Dynamics 365 portal implementations that have been running for several years have accumulated customizations the original template never anticipated, and those are where the real work lives. Five categories come up consistently. Custom columns added directly to the legacy adx_ metadata tables have no equivalent in the enhanced schema, so you will need to stand up a new custom table, add a lookup back to powerpagecomponent, and migrate the data across rather than expecting an automatic mapping. Relationships built between your custom tables and the old adx_ tables need to be recreated against their powerpagecomponent equivalents, which means auditing your solution for every such relationship before you migrate, not after. Liquid code that references entities directly, something like assigning a variable from entities[‘adx_weblinks’], needs to be rewritten to use the corresponding Liquid object instead, since the enhanced data model does not expose those legacy entity names the same way. FetchXML embedded in Liquid templates that queries adx_ entities by name has to be rewritten against powerpagecomponent with a componenttype filter, and getting that filter value wrong is a common source of queries that silently return nothing rather than failing loudly. Finally, any custom plugins or classic workflows registered against the old tables need to be re-registered against their enhanced equivalents, which is easy to forget if that logic was written by a developer who has since moved on and the automation itself has been running quietly in the background for years.

None of these are migration blockers on their own. They are the reason the customization report exists, and the reason this gets treated as a project with a real test phase, not a command run against production on a Friday afternoon.

How to Actually Run This

Start on a full copy of the production environment, not a shared sandbox someone else is also using that week. Run the customization report first and treat it as your scope document: every item it flags becomes a line in your migration plan, and if it flags nothing, that itself is worth double-checking against a manual review of your solution, since undocumented customizations from years back do not always get picked up cleanly. Migrate configuration data and configuration data references as separate, deliberate steps rather than reaching for the combined mode on a first attempt, since separating them gives you a natural checkpoint to validate before moving transactional data. Watch your table sizes going in: the migration processes records in batches of five thousand, so a site with a large volume of case records, form submissions, or forum content tied to configuration should expect the migration job to take real time, and you should plan your maintenance window accordingly rather than assuming it finishes in minutes. Once the migration completes, work through the five customization categories above methodically against your report before you consider the environment production-ready, and only then schedule the actual cutover during a low-traffic window given that end users will be locked out or degraded while the switch happens.

Treat this as a two-track modernization rather than folding it into the separate Bootstrap 5 template migration Microsoft made generally available for these same four templates back in June. One is about the underlying data model and ALM story, the other is about front-end markup and CSS, and combining them multiplies your testing surface for no real benefit. Sequence the data model migration first, stabilize, then take on Bootstrap as its own scoped effort.

Why This Is Worth Prioritizing Now

Every enhanced-data-model-only feature Microsoft has shipped since 2023 stays out of reach until you make this move, and the pace of that list is not slowing down. In our work at Routeget Technologies with legacy Dynamics 365 portal environments, we have consistently seen operational overhead trace back to being stuck on manual package management and unmanaged solution exports, simply because migrating never had a supported path for the specific template a client was running. That excuse is gone now. The work is not trivial, and the five customization categories above are real effort, not boilerplate. But for a portal your organization depends on, closing that ALM gap and getting onto a data model Microsoft is actively investing in is a better use of a sprint than continuing to work around a limitation that no longer needs to exist.

#PowerPages #EnhancedDataModel #PowerPlatformALM #DynamicsPortalMigration #LowCodeGovernance #PowerPlatformCLI

The Sales Close Agent Retirement Isn’t a Feature Swap. It’s a Platform Move.

Solution architect reviewing AI sales agent configuration dashboards on a dual-monitor workstation

A Dynamics 365 Sales architect who spent March configuring the Sales Close Agent for a client’s inside sales team is about to find out that work has an expiration date. September 30, 2026 is the last day anyone can stand up a new instance of the agent. October 30 is the day every existing instance, configured playbooks and all, gets pulled from every environment where it runs. Neither date has gotten much attention outside Microsoft’s own deprecation notes, and the Sales Close Agent retirement comes with a single sentence of guidance: create an instance of Sales Development Agent instead. For a solution architect who built engagement rules, email cadences and knowledge sources around the old agent, that sentence undersells how different the replacement actually is.

Solution architect reviewing sales automation agent configuration on a dual-monitor workstation

What the Sales Close Agent actually does today

Sales Close Agent, still labeled a production-ready preview, was built to run high-velocity, low-complexity deals without a seller touching them until something goes wrong. It works against accounts, contacts, leads and opportunities that match target-customer criteria an admin defines during setup, then sends templated outreach email pulled together from a configured profile, product catalog and a set of knowledge sources. Everything about the agent lives inside Dataverse and Copilot Studio: admins configure it through a settings page inside the Sales Hub, security is granted through custom or out-of-the-box Salesperson roles, and every run is tracked as a record in the msdyn_salesagentrun entity, filterable by status (active, completed, failure) and viewable through standard model-driven views like “Opportunities from Sales Close Agent.”

The mechanics underneath are more rigid than most admins expect once they read past the marketing description. The agent caps outreach at 20 emails per ten-minute window, specifically to control AI credit consumption rather than deliverability. Follow-up cadence is fixed at up to four emails over three weeks and isn’t configurable without a support ticket to Microsoft. If a customer goes quiet, the agent auto-closes the record as lost; if it detects an objection past its comfort level, it escalates to a human seller with full interaction history attached to the record’s timeline. None of that is unreasonable for a first-generation automation feature. It’s also all going away in a matter of weeks, and unlike most Dynamics 365 retirements, this one comes with no in-product migration wizard.

The Sales Close Agent retirement doesn’t come with a migration path

Sales Development Agent, the named successor, doesn’t live in Dynamics 365 Sales at all. It’s a Microsoft Agent 365 offering, deployed and configured from inside Microsoft Teams, currently gated behind the Frontier preview program and requiring an organization to have opted into Microsoft 365’s Targeted Release track for the relevant users, or the whole tenant. That single prerequisite is worth checking before anything else, because an architect who assumes the replacement will simply appear in the Power Platform admin center the way Sales Close Agent did will instead find nothing there to configure. The agent is deployed from the Teams Store or the Microsoft 365 Copilot agent store, and every bit of its setup happens conversationally: you tell it, in a Teams chat, to define a playbook, share sample emails so it can match your tone, upload product documentation as PDFs or Office files, and set a send window such as weekdays between nine and five Pacific.

That configuration model is a real structural difference, not just a change of interface. Sales Close Agent’s behavior comes from admin console pages: profile, product details, target customers, email delivery, email content, knowledge sources, each with its own screen and its own “avoid edits after publishing” warning. Sales Development Agent’s behavior comes from four looser components (playbook, guidelines, product knowledge, and settings) assembled through natural-language instructions inside a chat thread, then validated by uploading a test prospect list and running simulated conversations before typing “go live.” An architecture team used to documenting agent configuration as a set of screenshots from admin pages will need a different documentation approach entirely, since there’s no settings UI to screenshot.

Reconnecting it to Dynamics 365 isn’t automatic either

If Dynamics 365 is the system of record, Sales Development Agent doesn’t sync with it by default. Connecting the two is an explicit, multi-step process: assign the agent a Sales license in the Microsoft 365 admin center, add it to the Dynamics 365 Sales instance with a Salesperson role through the Power Platform admin center, enable the Dataverse Model Context Protocol server in that environment, publish that MCP server using VS Code or the Agent 365 CLI, and then wait for a Global Administrator or AI Administrator to approve the resulting server request before the agent can pull prospect lists from Dataverse or write engagement history back to lead records. That approval step alone means CRM integration for the new agent isn’t something a Sales Hub admin can finish alone; it requires a security decision from someone with tenant-level access, on a timeline that doesn’t care whether your old agent is a week from deletion.

Team collaborating around a Teams-based AI agent configuration screen with sales pipeline data

What this means for a migration plan

Treat this less like a version upgrade and more like standing up a new integration on a deadline. There is no data or configuration carryover: target-customer criteria, product catalog mappings and knowledge source references built into Sales Close Agent don’t transfer, because the two agents don’t share a configuration schema. Prospect data for the new agent needs to arrive as a CSV or Excel file with specific column requirements (email, company name, product, first name, with optional language and country columns for its 22 supported languages), which is a different intake format than anything the old agent’s target-customer configuration expected. And because the replacement currently sits behind Frontier and Targeted Release enrollment, the realistic first step for most teams isn’t configuration at all, it’s confirming with the Microsoft 365 admin whether that enrollment exists yet, since a tenant that isn’t enrolled has no path to the replacement on October 30 regardless of how well the rest of the migration is planned.

Worth flagging to any CFO or IT Director signing off on this work: Sales Development Agent, as documented today, runs without a per-action approval step once it’s live, replies only to email threads it personally started, and has no visual reporting dashboard, with campaign and prospect summaries delivered as answers inside a Teams chat instead. None of those are dealbreakers for a lead-qualification workflow, but they are a materially different governance posture than a Dataverse-native agent whose every run is a queryable, reportable Dataverse record. A rollback plan matters here in a way it usually wouldn’t for a routine feature update, since the source system disappears on a fixed date whether or not the destination is ready.

The narrow window that actually matters

Ten days separates today from the last date to create a new Sales Close Agent instance, and forty days separates it from the date every existing instance disappears regardless of migration status. Neither Microsoft’s release-plan entry nor its deprecation notice describes a bridge between the two agents beyond that single line of guidance, which leaves the actual migration work, mapping old configuration intent to new playbook language, resolving the Frontier and Targeted Release prerequisite, and running the MCP server approval chain, entirely on the implementation team. Routeget Technologies has walked several clients through comparable agent-to-agent platform moves inside the Dynamics 365 ecosystem this year, and the pattern holds here too: the teams that treat this as infrastructure work, with its own project plan and its own risk review, come through it in better shape than the teams who wait for the in-product banner to remind them.

#SalesCloseAgent #SalesAIAgents #Agent365 #CRMGovernance #AgentMigration #DataverseMCP

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