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

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

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

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

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

From Manual Registration to Code-First Packages

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

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

What Dataverse Plugin Packages Actually Solve

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

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

The Immutability Trap

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

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

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

The Build Tools Gap

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

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

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

Building This Into an ALM Pipeline Properly

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

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

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

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

Copilot Studio ROI Measurement: Why Resolution Rate Isn’t Enough Before You Scale

Operations manager reviewing a customer service agent performance dashboard in an enterprise office

A customer service director at a mid-market manufacturer recently walked into a steering committee meeting with a number she was proud of: her Copilot Studio agent was resolving 78 percent of engaged sessions without a human handoff, up from 61 percent three months earlier. The CFO asked one question that stopped the meeting cold. Had customer satisfaction moved in the same direction? It hadn’t. CSAT had drifted down two points over the same period. The agent was closing more conversations. It was not clear it was actually helping more people.

That gap is becoming the central question for any organization running a Copilot Studio pilot with an eye toward production scale. Copilot Studio ROI measurement has matured considerably over the past year, with Microsoft now publishing a formal value framework alongside the platform’s built-in analytics. But the metrics that make a pilot look successful to an internal audience are not automatically the metrics that justify expanding it to every customer-facing channel a company operates. Getting that distinction right, before the budget request goes to the board, is the difference between a scaling decision built on evidence and one built on a single flattering number.

Operations manager reviewing a customer service agent performance dashboard in an enterprise office

What the Monitor Tab Actually Tells You

Copilot Studio’s built-in analytics, accessible from the Monitor tab in the maker portal, track session outcomes across four categories: resolved, escalated, abandoned, and unengaged. Resolution rate is calculated as the share of engaged sessions that end in a resolved state, and Microsoft’s documentation is specific about how “resolved” gets determined. A session counts as resolved either when a user explicitly confirms an answer solved their problem, or, more quietly, when the user simply doesn’t respond after receiving one. That second path, an implied resolution, is where the manufacturer’s numbers started to diverge from reality. A user who gives up on a chatbot and closes the browser tab looks statistically identical, in the resolution rate calculation, to a user who got exactly what they needed.

Escalation rate and abandonment rate round out the core picture: escalation tracks handoffs to a human agent, split into system-intended handoffs (the bot routes on purpose), system-unintended handoffs (something went wrong), and user-requested handoffs. Abandonment tracks sessions that time out without either outcome. Engagement rate measures the share of total sessions that move past a passive greeting into an actual topic or system flow. CSAT, on a straightforward one-to-five scale, is the metric most likely to contradict a rosy resolution number, and it deserves at least as much weight in a scaling decision as the headline resolution figure, not a supporting-cast role beneath it.

The Quality-Versus-Throughput Trap

The pattern the manufacturer ran into has a name among practitioners who implement these agents for a living: the quality-versus-throughput trap. A resolution rate climbing while CSAT falls is a specific, checkable warning sign, not statistical noise. It usually means the agent is getting faster at closing sessions without getting better at actually answering the underlying question, and implied resolution is the mechanism that lets that happen without tripping any alarm in the standard dashboard view.

The fix isn’t complicated, but it does require deliberately pulling two numbers into the same review rather than reporting resolution rate in isolation. Any pilot-to-production decision should require both metrics on the same slide, tracked over the same window, with a defined tolerance for how far they’re allowed to diverge before the rollout pauses for investigation. It’s also worth checking topics with unusually high implied-resolution counts specifically, since a handful of poorly scoped topics are often responsible for most of the gap, and fixing those few topics can move the CSAT number more than a platform-wide tuning pass would.

Two IT professionals reviewing a chatbot conversation on a laptop screen

Microsoft’s Own Framework for Copilot Studio ROI Measurement

Microsoft has published a genuinely useful, if underused, structure for this problem in its Copilot Studio guidance documentation, organized around four value drivers: efficiency, quality, revenue, and strategic value. Each driver comes with its own pricing logic rather than a single blended score. Efficiency is priced as hours returned multiplied by a fully loaded hourly rate. Quality is priced as the change in error rate multiplied by transaction volume and the cost of an error. Revenue is priced as a conversion delta multiplied by volume, unit revenue, and an attribution discount that accounts for the agent not being the only factor in a customer’s decision. Strategic value, the hardest to quantify, folds in things like optionality, talent retention, and organizational resilience.

The most concrete piece of this framework is a formula Microsoft calls Agent Assisted Hours, which converts raw session data into a labor-hours estimate. It weights sessions that cite a knowledge source and sessions that don’t, applies outcome weights of 1.0 for resolved sessions and 0.7 for escalated or abandoned ones, and multiplies the result by a default time-savings assumption of six minutes per reference before dividing by sixty to get hours. Microsoft’s own worked example uses 10,000 monthly sessions, split between sessions with knowledge citations and sessions without, arriving at roughly 1,440 assisted hours per month. At the platform’s default hourly rate of 72 dollars, drawn from U.S. Bureau of Labor Statistics compensation data, that works out to a bit over 100,000 dollars in monthly value and something in the neighborhood of 1.2 million dollars annualized. Whether that specific rate or those specific session ratios apply to any given organization is a separate question, but the formula itself is a far more defensible way to talk to a CFO than “resolution rate went up.”

Where the Numbers Get Murky

Three complications are worth flagging before anyone builds a board presentation around these figures. First, Microsoft’s own documentation is inconsistent on how long a session has to sit idle before it counts as abandoned, with one guidance page citing thirty minutes and another citing an hour. That’s a small detail, but it changes the abandonment denominator enough to matter if two teams are comparing numbers pulled from different reference points.

Second, and more consequential for organizations running both a Copilot Studio agent and a Dynamics 365 Omnichannel contact center, the two systems measure resolution, escalation, and abandonment differently by design. Copilot Studio analytics track only the bot’s portion of an interaction, while Omnichannel analytics track the full lifecycle including the human agent’s part of the conversation. A single customer interaction can register as several distinct sessions in Copilot Studio’s counting logic while showing up as one session in Omnichannel. Microsoft states this plainly in its own guidance. It means a CIO comparing a “before Copilot Studio” baseline against an “after Copilot Studio” number needs to be certain both figures came from the same measurement system, not two systems with similarly named metrics that are quietly counting different things.

Third, the billing model underneath all of this changed in September 2025, when Copilot Studio moved from message-based billing to Copilot Credits. Microsoft’s admin center documentation describes a credit as one user interaction generating one response, a simple one-to-one framing. Partner implementers who have actually run production traffic describe something messier: a single turn that triggers generative grounding plus a connector action can consume well over ten credits, which means historical message-volume estimates from before the change can’t be used to forecast credit consumption after it. Microsoft does publish a Copilot Studio Agent Usage Estimator specifically because the credit math isn’t intuitive from the documentation alone, and any organization sizing a production rollout should run its own traffic patterns through that tool rather than extrapolating from a pilot that ran under lighter, less representative usage.

A Practical Checklist Before the Scaling Decision

None of this argues against scaling a Copilot Studio agent. It argues against scaling on the strength of one number that happens to look good in isolation. Before a pilot moves to production, pair resolution rate with CSAT on the same review cycle and set a divergence threshold that triggers a pause. Pull actual credit consumption from the Power Platform admin center’s agent-level usage view, not a projection based on pilot-stage traffic, since real usage patterns tend to run heavier than early testing suggests. Build a test set using Copilot Studio’s Agent Evaluation feature, which reached general availability in March 2026 and lets makers validate topic reliability against up to a hundred defined cases before exposing a scaled version to live customers. And export feedback comments and transcripts to an external store on a regular cadence, since the native Analytics tab retains free-text feedback for only twenty-eight days, which is not long enough to support a continuous improvement program that spans a full budget cycle.

The organizations getting real value from these agents are the ones treating the Monitor tab as a starting point for questions, not a finished scorecard. Routeget Technologies has walked several clients through exactly this transition, from pilot metrics that looked convincing on their own to a value model that could actually survive a CFO’s second question. That second question is usually the one that matters most.

#CopilotStudio #AgenticAI #CustomerServiceAI #AIGovernance #EnterpriseAI #DigitalTransformation

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

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

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

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

What Actually Counts Against Your Limit

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

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

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

The Power Automate API Request Limits That Actually Matter

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

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

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

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

Architecting Integrations to Survive Enforcement

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

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

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

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

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

Get Ahead of the Reporting Gap

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

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

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

Dynamics 365 Contact Center Playbooks Let Supervisors Write Routing Logic in Plain English. IT Still Has to Govern It.

Contact center supervisor reviewing a live conversation routing and queue dashboard

It is 8:40 on a Monday morning and a contact center supervisor at a mid-size distributor is watching a queue for premium accounts back up past the fifteen-minute mark. Two years ago, fixing that meant opening a ticket with IT, waiting for someone who understands the routing rule builder to free up an afternoon, and hoping the change didn’t collide with three other rules already live on that queue. Today, in a growing number of Dynamics 365 Contact Center environments, that supervisor can type a sentence: if a Gold-tier customer waits more than thirty seconds with no agent available, raise their priority every thirty seconds until someone picks up. The system takes it from there.

What Dynamics 365 Contact Center Playbooks Actually Do

Conversation orchestration, the feature behind this shift, is not simply a rebrand of unified routing’s existing rule engine. Traditional unified routing evaluates a conversation once, at the moment it arrives, against a static classification ruleset and assigns it to a queue. Dynamics 365 Contact Center playbooks instead monitor a conversation across its full lifecycle and respond as conditions change: wait time climbing, an agent signing out, a queue moving from staffed to unstaffed outside business hours. The playbook itself is authored through a guided template rather than a rule-tree editor. An administrator (Microsoft’s documentation specifically calls out System Administrator and Omnichannel Administrator roles, not a developer role) picks a scenario such as dynamic prioritization, overflow handling, or bullseye expansion of the eligible agent pool, attaches up to ten conditions built from context variables like customer tier or region, and writes the logic as a sentence rather than a nested if/then structure.

Underneath that plain-language input, a language model converts the sentence into a structured runtime policy the routing engine can actually execute. That detail matters more than it sounds like it should, and we will come back to it.

The Real Change: Configuration Authority Moves Off IT's Desk

For a Contact Center Director, the operational upside is straightforward to state. Routing changes that used to require a developer familiar with the classification rule syntax, plus a change window, plus regression testing against every other rule on that queue, can now be drafted, tested in draft status, and published by the person who actually owns the queue’s performance. Microsoft’s own framing of the feature leans hard into this: playbooks are meant to be authored and published “within minutes” by operations staff, not routed through an IT backlog. For an organization running twenty or thirty queues across voice and chat, each with its own seasonal patterns and VIP handling rules, that is a genuine reduction in the lag between noticing a problem and fixing it.

It also changes who is accountable for a bad outcome, and that is where the governance conversation needs to start well before rollout, not after the first incident.

Why Dynamics 365 Contact Center Playbooks Need a Governance Layer Before Broad Rollout

Microsoft’s own documentation is candid about a specific limitation worth reading closely: because the system uses a language model to translate a plain-language playbook into structured runtime logic, the converted output might not fully capture what the administrator actually intended, and any deviation can only be identified once the playbook is running against live conversations. In practice, that means a supervisor could write a sentence that sounds unambiguous to a person and have it compiled into routing logic that behaves slightly differently than expected, with no warning until customers start landing in the wrong place. This is not a hypothetical edge case worth dismissing. It is the stated behavior of the feature, documented in the same page that describes how to build a playbook.

That single fact should shape how any organization rolls this out. Treating a published playbook as production logic the moment it goes live, with no observation period, skips the one safeguard the platform actually gives you: the Draft status. A playbook can sit in Draft indefinitely while an administrator reviews it, and Microsoft’s diagnostics tooling for unified routing extends to playbooks as well, giving supervisors a way to watch what a rule is actually doing against real traffic before trusting it unattended. Any rollout plan that skips a monitored soak period on a low-risk queue, in favor of pushing straight to a high-volume VIP line, is accepting a risk the documentation already flagged.

Contact center team configuring routing logic while agents handle live conversations in the background

There is a second governance thread that CIOs and legal or compliance stakeholders should not miss. Microsoft’s supplemental terms for the feature include an explicit disclaimer that conversation orchestration is not intended for, and should not be used to make, decisions affecting an employee’s compensation, rewards, seniority, or other employment-related entitlements, and that organizations remain responsible for complying with employee monitoring and consent laws in their jurisdiction. That guardrail exists because the underlying mechanism, real-time monitoring of live conversations and automated action based on evolving conditions, sits close enough to workforce monitoring that Microsoft felt the need to draw the line explicitly rather than leave it implied. Any organization piloting playbooks for agent-assignment scenarios, where the system is reconnecting customers with representatives they spoke to previously, should have its HR and legal teams review the scope of what is being monitored and why before the first playbook touches a live queue with actual agents on it.

Rollout Considerations Worth Deciding Before the First Playbook Goes Live

A few practical constraints shape how this should actually be piloted. The feature currently supports voice and live chat channels only, so any organization running significant volume through digital messaging channels, social, or SMS will need to keep those on the existing classification ruleset for now. Microsoft has stated plans to expand channel coverage, but has not committed to a date at the time of writing, so it should not be assumed for planning purposes. The platform also enforces validation that prevents publishing two playbooks for the same scenario on the same queue, which forces a useful discipline: one queue cannot end up with silently conflicting logic, but it also means teams need to decide up front which playbook owns a given scenario rather than layering fixes on top of each other the way ad hoc rule trees sometimes accumulate over the years.

Licensing is the other piece worth confirming before a pilot gets too far along. Conversation orchestration carries its own licensing requirement separate from base Contact Center or Customer Service entitlements, and organizations on a pay-as-you-go consumption model need an Azure subscription with billing configured before the feature will run in production. This is easy to miss during a proof of concept built in a sandbox environment and then discover as a blocker when it is time to move to a live queue, so it is worth confirming with a Microsoft licensing specialist as part of the pilot scope rather than after.

Where This Leaves a CIO Weighing the Rollout

The case for conversation orchestration is not that natural-language configuration is a novelty. It is that it collapses the distance between the person who understands a queue’s real-world behavior and the person who can change how it routes, without requiring both of those people to be the same person or to coordinate through a ticket queue. That is a legitimate operational gain, particularly for organizations whose contact center staffing and customer tiers shift with seasonality or promotions. But the platform’s own documentation hands you the risk list: translation drift between what was written and what actually runs, employment-law boundaries around monitoring, and a validation layer that assumes disciplined ownership of which playbook governs which scenario. None of those are reasons to skip the feature. They are the checklist for a rollout plan that treats a published playbook the way any other piece of production logic deserves to be treated, with a review step, an observation period, and a named owner. Organizations that have gone through this kind of change management before, when unified routing itself first replaced manual queue assignment, will recognize the pattern. This is the same shift one layer further along, and it rewards the teams that plan for it rather than the teams that discover the gaps live.

Routeget Technologies has helped clients stage this kind of rollout, pairing the operational speed of self-service configuration with a review process that catches translation drift before it reaches a live queue, and it is the kind of governance work that pays for itself the first time a playbook does not do quite what the sentence said it would.

#DynamicsContactCenter #UnifiedRouting #ConversationOrchestration #ContactCenterGovernance #CustomerServiceAI #ITGovernance

The Business Central Payables Agent Drafts Invoices. It Still Won’t Match a Purchase Order.

Finance professional reviewing an AP invoice matched against a purchase order and receipt on a computer dashboard

A controller at a mid-sized distributor recently described the moment her AP team realized what they’d actually bought. A vendor emailed a PDF invoice to the shared mailbox Business Central was watching, and within a few minutes the Business Central Payables Agent had pulled the vendor, mapped the line items to a G/L account, and dropped a fully drafted purchase invoice into the review queue. It looked like the AP clerk role had been automated away. Then someone asked whether the agent had checked the invoice against the purchase order or the goods receipt behind it, and the honest answer was no. It never does. Purchase order matching sits on Microsoft’s own published list of things the Payables Agent explicitly does not do, right alongside approval flows and anomaly detection.

That gap matters more than it sounds like it should, because Microsoft shipped a separate, unrelated feature in the same Business Central 2026 release wave that does handle order and receipt matching, and the two are easy to mistake for one connected capability. They are not. Understanding where the line actually falls is the difference between a rollout that genuinely reduces AP workload and one that quietly removes a control your finance team assumed was still there.

What the Business Central Payables Agent Actually Automates

The agent’s job starts and ends with turning an inbound PDF into a usable draft. It monitors a dedicated mailbox, pulls unread invoice emails, and runs each attached PDF through Azure Document Intelligence to extract the vendor name, amounts, and line detail. From there it tries to match the sender to an existing vendor record in Business Central; if it can’t do that confidently, it stops and asks a designated supervisor for instructions rather than guessing. When a new vendor genuinely needs to be created, the agent prefills the card from what it read off the invoice, but the record comes in blocked by default until a person reviews and releases it. Only after the vendor question is settled does the agent move to drafting the invoice itself, using historical purchasing patterns and item references to suggest which G/L accounts the line items belong to.

Finance professional reviewing an AP invoice matched against a purchase order and receipt on a computer dashboard

None of that becomes a posted transaction on its own. Every draft lands in a review queue where a human has to confirm, correct, or reject it before it becomes an actual purchase invoice, and Microsoft is direct about why: the agent’s account classifications and vendor matches “can be inaccurate,” and it has no way to evaluate business context the way a person reviewing the invoice would. That’s a reasonable design for what the agent is built to do, which is eliminate the manual keying and re-typing that eats the first half of most AP cycles. It is not built to answer the question of whether what you’re about to pay actually matches what was ordered and what showed up on the dock.

The Three-Way Match Gap Nobody’s Marketing Slide Mentions

Three-way matching, the practice of confirming an invoice against its purchase order and its receipt before payment, is the control most finance organizations rely on to catch overbilling, duplicate charges, and phantom deliveries. The Payables Agent doesn’t perform it. That’s not a bug or an oversight Microsoft is quietly working around; it’s a documented limitation, and as of this writing the agent itself is still labeled a public preview release rather than a finished, generally available feature.

What makes this genuinely confusing for a rollout is that the same 2026 wave 1 release also introduced “Match Purchase Invoices to Multiple Order and Receipt Lines,” a completely separate, non-AI capability built directly into standard purchase order processing. It adds a “Get Order Lines” action that surfaces received-but-uninvoiced or unreceived order lines, a “Matched Order Lines” page for reviewing and adjusting how invoice lines tie back to multiple purchase orders and partial receipts at once, and a “Receipt on Invoice” toggle that can auto-generate the receipt when a linked invoice posts. It reached general availability in April 2026, on its own timeline, with its own set of exclusions that keep it away from prepayment orders, item charges, projects, subcontracting, blanket orders, and intercompany transactions. Nothing in Microsoft’s documentation ties these two features together, and there’s no evidence the Payables Agent hands its drafts off into this matching workflow automatically. They simply shipped in the same release, aimed at the same purchase-to-pay process, and solve two different halves of the problem without talking to each other.

The practical result is that an AP team running the Payables Agent still needs to run invoices through order and receipt matching separately, whether that means the new native matching screens, an existing three-way-match process, or a third-party tool already in place. Treating the agent’s fast, clean drafts as evidence that matching already happened is exactly the kind of assumption that erodes a control environment quietly, one invoice at a time, until an audit or a duplicate payment surfaces the gap.

Consumption Billing Changes How You Budget for This

The licensing model adds a second layer finance leaders need to plan around before anyone flips this on for real volume. Copilot itself is bundled into Business Central’s Essentials and Premium subscription tiers, so the base chat and suggestion features a user sees day to day don’t carry a separate charge. Agents are different. The Payables Agent runs on Copilot Credits, a metered unit purchased through an Azure subscription, and consumption scales with how much work the agent actually does rather than with how many people are logged in. Microsoft’s own guidance is candid that it doesn’t publish a flat per-invoice rate; credit consumption depends on which features get used and what actions the agent performs on a given document, which means the honest answer to “what will this cost us” only comes from watching it run.

Hands comparing a printed purchase order against an invoice on a laptop screen during AP review

That variability lands at an awkward moment for most finance calendars. Invoice volume tends to spike at quarter-end and during seasonal peaks, which is precisely when a consumption-based bill is likely to jump, and precisely when a finance team has the least appetite for a surprise line item. Organizations used to a flat per-seat software cost don’t automatically have a forecasting habit built for variable, usage-driven spend, and marketing language that blurs “Copilot is included” with “the agent is included” doesn’t help anyone build one. There’s also a governance detail worth knowing before you assign ownership: viewing actual billing and consumption detail requires the SUPER or AGENT-DIAGNOSTICS permission set specifically. The narrower AGENT-ADMIN role that would typically administer the agent day to day does not, by itself, grant visibility into what it’s costing, so whoever ends up accountable for the Azure bill needs to be deliberately provisioned, not assumed.

What This Means for a Rollout Decision

None of this argues against adopting the Payables Agent. For an AP team drowning in PDF invoices that arrive by email in a single language, it removes a real chunk of manual entry, and the human-in-the-loop design means it isn’t going to post something wrong without a person signing off first. The documented ceilings are worth checking against your own volume before you commit to it as a strategy rather than a pilot: the agent tops out at 500 processed invoices and 100 monitored emails per day per environment, it’s validated for English only, it only reads PDF attachments up to a handful of pages and a few megabytes each, and it will not touch approval workflows or flag anomalies on its own. A high-volume, multi-language AP operation with heavy PO-based purchasing is going to run into those edges quickly.

The more useful framing for a CIO or CFO evaluating this isn’t “should we turn on AI for accounts payable.” It’s two separate questions that deserve two separate answers: does this reduce the manual work our AP team does today, and does it strengthen or weaken the matching controls we already rely on. The first answer, for the right invoice profile, is genuinely yes. The second, at least for now, is that the agent doesn’t touch that control at all, and the feature that does was built and shipped on its own, waiting to be adopted separately. Firms we’ve worked with on Business Central Copilot rollouts have had the smoothest results when they scoped the agent narrowly, ran it against real invoice volume for a full billing cycle before expanding it, and kept three-way matching exactly where it already lived rather than assuming the new AI layer had absorbed it.

#BusinessCentral #PayablesAgent #APAutomation #CopilotCredits #ThreeWayMatch #ERPGovernance

Financial Tags Finally Cover Purchase Order Invoicing in D365 Finance 10.0.49. Ledger Settlement Still Won’t Match Half of Them.

Finance professional reviewing a general ledger reconciliation dashboard with matched and unmatched transaction indicators

A controller running month-end reconciliation on a clearing account in Dynamics 365 Finance has a specific, recurring headache: the debit side of a transaction carries a purchase order number as a financial tag, the offsetting credit side does not, and the ledger settlement engine treats the two lines as unrelated even though anyone looking at the source documents can tell they belong together. Until version 10.0.49, this was a permanent structural gap rather than an occasional configuration mistake, because financial tags on purchase order invoicing simply did not exist as a supported scenario. Sales order invoicing got tag support years earlier. Purchase orders did not, which meant any finance team using tags to track PO references through the vendor side of the ledger was stuck writing the number into a description field or a financial dimension never designed to hold it. That gap closed with 10.0.49, and the fix is worth understanding in detail, because the parts of financial tags that already worked reasonably well are not the parts that are going to trip up the teams adopting this now.

What Financial Tags Actually Are, and Why the PO Gap Mattered

Financial tags are not a new concept in Dynamics 365 Finance. Introduced in version 10.0.16, they give a legal entity up to twenty user-defined fields that attach supplementary reference data directly to a general ledger voucher line, things like an external invoice number, a customer name, or a payment reference, without that data ever touching a subledger table or a financial dimension. That distinction matters more than it sounds. Financial dimensions were built for reusable, hierarchical, reportable categories: cost center, department, business unit. A purchase order number is none of those things. It is a single-use reference that exists to answer one question later: which document generated this line. Forcing that kind of data into a dimension structure bloats the dimension combination table and adds no analytical value, since nobody is running a financial report grouped by PO number. Tags were built specifically to hold this lower-reusability data cleanly, and by the time sales order invoicing gained tag support, most finance teams using the feature had already built tagging conventions around customer-side transactions. Vendor-side transactions were the obvious next step, and the 10.0.49 release finally delivers it, gated behind a feature called Enable financial tags for purchase order invoicing that sits alongside the equivalent, longer-standing sales order feature in Feature management.

Where the Real Work Starts: Ledger Settlement Matching

The reason this release deserves more than a changelog mention is that financial tags do something beyond passive record-keeping. They can serve as match criteria inside ledger settlement, the process finance teams use to pair debit and credit lines on clearing, prepaid, accrual, and other temporary accounts and mark them as settled. In principle, tagging both the AP-side and AR-side (or intercompany) legs of a transaction with the same PO reference should make settlement close to automatic: the engine finds the matching tag values and clears the pair. In practice, three specific failure patterns show up constantly, and none of them produce an error message that tells you what actually happened.

Close-up of hands reviewing a voucher transaction table with reference and status columns on a laptop

The first is the mismatched-side problem this article opened with. If the debit line carries a tag value and the credit line does not, or the two sides carry different values because they were entered by different people at different points in the process, settlement will not treat them as a match. There is no fuzzy matching here. The comparison is exact, and a trailing space or a different capitalization convention is enough to break it. The second is a timing problem specific to any organization adopting purchase order tagging now rather than at initial go-live: transactions posted before the feature was activated simply have no tag value on the line at all, which means every open item predating the 10.0.49 upgrade needs a separate remediation pass before it can participate in tag-based settlement. You cannot retroactively tag a posted voucher through the transaction UI; the supported path is the internal voucher data edit function, gated behind the Allow edits to internal data on general ledger vouchers feature, and it needs to run as a deliberate cleanup project, not something a settlement clerk discovers mid-close.

The third failure mode is the one that catches experienced admins off guard, because it involves a change that looks harmless. Tag labels can be renamed at any time without affecting already-posted data, which is a genuine convenience when a naming convention needs to evolve. But posted voucher lines retain whatever tag value was in effect at posting time, and if two lines that logically belong together were posted before and after a rename, or against two tags that were later consolidated under one label, the underlying stored values can diverge from what the current tag configuration implies, and settlement compares stored values, not current labels. A team that renamed a tag mid-quarter for good reasons can end up with a batch of open items that look identical in the UI but fail to match, and the only way to find out why is to pull voucher transactions against the general journal account entry table (not the financial tags table, which only exposes generic Tag01 through Tag20 labels and hides which business tag they actually correspond to) and compare raw values line by line.

Configuration Details Worth Getting Right Before You Enable the Feature

Beyond the settlement-matching behavior, a few configuration decisions are easy to get wrong on the first pass and expensive to unwind later. The delimiter used to separate tag values in General ledger parameters cannot be changed once set, so it is worth choosing a character your reference data will never plausibly contain, not just one that looks clean in a demo. Validation is optional by default even for list-type tags; as of 10.0.44, Fixed list and Fixed custom list value types exist specifically to prevent free-text drift, and for any tag that will be used as a settlement match key, that validation should be non-negotiable rather than left at the default. And because tag configuration changes are cached at the user session level, a tag that was just activated or edited will not reliably show up for a user until they sign out and back in and, in stubborn cases, clear the usage data cache under user options; teams that skip this step and conclude a newly enabled tag “isn’t working” are usually looking at a caching artifact, not a configuration bug.

For a finance function evaluating whether to turn purchase order tagging on now, the sequencing that avoids the most rework is to finalize the tag definitions and delimiter first, apply fixed-list validation to anything that will drive settlement matching, activate the feature and confirm both sides of a representative PO-to-payment cycle post with identical tag values, and only then decide how far back to remediate historical open items rather than assuming the feature will somehow reach backward on its own. None of this diminishes what 10.0.49 actually fixes: a real, years-old asymmetry between how sales and purchase transactions could be tagged is gone. What it does not fix, and was never going to, is the discipline required to keep tag values consistent across two sides of a transaction that are frequently entered by different people, in different modules, at different times. Routeget Technologies has helped finance teams build that discipline into their close process rather than discovering the gap during an audit, and the pattern is consistent enough across clients that it is worth planning for before enabling the feature rather than after the first failed settlement run.

#FinancialTags #DynamicsFinanceOps #LedgerSettlement #PurchaseOrderInvoicing #GeneralLedger #ERPReconciliation

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