Copilot Studio Harness Billing: The Free Pilot Period Just Ended

Finance director reviewing cost dashboards for Copilot Studio agent billing

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

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

What Copilot Studio harness billing actually changed on September 1

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

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

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

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

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

Laptop screen showing an administrative usage and credit consumption dashboard

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

What to check before the next invoice arrives

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

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

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

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

Power Automate’s Self-Healing Desktop Flows: What Gets Fixed, and What Still Breaks

IT operations engineer monitoring automated workflow dashboards on multiple monitors

A desktop flow that has run clean for eight months can start failing on a Tuesday morning for reasons that have nothing to do with the flow itself. A vendor portal repaints its login page during a routine update, a button that used to sit at a fixed set of pixel coordinates shifts three rows down, and the automation that finance has relied on for month-end reconciliation throws “Element not found” at 6 a.m. with nobody watching. This is the specific kind of fragility that Power Automate’s newly introduced self-healing desktop flows capability is built to reduce, and it is worth understanding precisely what the feature does before assuming it solves a problem it was never designed to solve.

IT operations engineer monitoring automated workflow dashboards on multiple monitors

Why UI Automation Breaks in the First Place

Desktop flows built around UI and browser automation actions work by capturing a selector, essentially a description of where an element lives inside an application’s structure, and replaying that description at runtime to find the same button, field, or menu again. That approach has always been reliable right up until the moment it isn’t. A web app ships a design refresh. A desktop application renames a control during a patch. A browser update changes how a page renders just enough that the original selector no longer resolves to anything. None of these changes touch the business logic of the flow at all, yet they are historically among the most common reasons a production RPA process stops overnight. They are also the reason RPA teams spend a disproportionate share of their maintenance time on selector repair rather than on building anything new.

What Self-Healing Desktop Flows Actually Do

Self-healing entered public preview on March 31, 2026, as an agentic capability scoped specifically to UI and web automation actions inside Power Automate for desktop, version 2.66 and later. It is not a general reliability feature, and it does not run continuously in the background. It activates only at the moment a specific action throws an Element not found error on the primary or secondary screen, or a Window not found error on the main screen, and only for actions involving a single UI element interaction such as a click or a checkbox selection.

When that failure occurs, the flow’s existing retry policy still runs first. Self-healing sits as a fallback step after retries are exhausted and before whatever error handling rules a maker has configured downstream, things like setting a variable or running a subflow. At that point, the desktop flow captures a screenshot of the missing element’s expected location, the parent window’s title, and a full image of the desktop, then passes that context to two large language models working in combination: GPT-4.1 mini and Claude Sonnet 4.5. The models attempt to identify a UI element that plausibly matches what the original selector was looking for, propose it as a substitute, and let the flow continue. If neither model can produce a confident match, the flow falls through to normal error handling exactly as if self-healing were not enabled at all.

That single design choice, using self-healing purely as a recovery mechanism rather than a permanent correction, matters more than it might first appear. The feature does not rewrite the flow’s stored selector once it recovers. Every future run of that same action will hit the same missing-element error and go through the same self-healing detour again, which means self-healing reduces the visible symptom of a broken selector without eliminating the underlying maintenance debt sitting behind it.

Where the Coverage Actually Stops

Teams evaluating this feature tend to assume it covers more ground than it does, and the gaps are specific enough to matter for planning. Self-healing does not apply to window or screen handling actions, so a flow that fails because an entire application window can’t be located, rather than a single control inside it, gets no help here. It does not extend to multi-element interactions like drag-and-drop, which remain exactly as brittle as before. It has no effect during designer test runs, applying only to console and cloud runs in attended or unattended mode, so a maker debugging inside the desktop flow designer won’t see it engage at all. And because the underlying models work from a screenshot and a window title rather than the application’s actual DOM or object model, self-healing is inherently probabilistic. Microsoft’s own documentation is direct about this: the models can occasionally identify the wrong element, which for a click action on a financial approval screen is not a theoretical risk worth shrugging off.

Close-up of a laptop screen showing a workflow diagram with one error node highlighted

There is also a visibility gap worth planning around before rollout rather than discovering during an incident. The Power Automate portal does not currently surface self-healing activity inside standard action-level run logs. The desktop flow run page shows a rollup of up to three successful self-healing attempts, but anyone who wants a full audit trail has to fall back to a registry setting that writes a repairWithAIInfo property into local log files on the machine running the flow. That is a meaningfully more manual process than most teams are used to for production RPA monitoring, and it is worth building into a rollout checklist rather than assuming the standard portal view will show everything.

Turning It On

Enabling self-healing is not a single toggle, and the chain of prerequisites is easy to get partway through and assume is finished. It starts in the Microsoft 365 admin center, under Copilot settings, where Anthropic has to be enabled as an approved AI subprocessor. This is already the default for most commercial cloud tenants, but it is worth confirming rather than assuming, especially in regulated environments where subprocessor lists get reviewed on a fixed schedule. From there, the same approval has to be granted a second time inside the Power Platform admin center, under Copilot settings, where external models are configured at either the environment or environment group level. A tenant using non-US regions also needs to explicitly allow data to move across regions under that environment’s generative AI features, since the underlying model calls are not necessarily processed in-region otherwise. Only after those three settings are in place does a fourth toggle, Copilot in Power Automate under the same admin settings, need to be switched on before the capability becomes available to makers at all.

At the flow level, the configuration is much simpler by comparison. Inside the desktop flow designer, a maker opens the error handling settings on a supported UI or web automation action and switches on self-healing for that specific action, one action at a time rather than as a flow-wide setting. This granularity is a genuine advantage for a phased rollout. A team can enable self-healing selectively on the handful of actions in a flow that interact with the least stable third-party interfaces, such as a vendor portal outside the organization’s control, while leaving internal, well-governed applications on standard error handling until there is a clearer track record to point to.

Fitting This Into an Error-Handling Strategy, Not Replacing One

The practical risk with a feature like this is not that it fails to work as documented. It is that a maker treats a preview capability with known gaps as a substitute for the selector discipline, monitoring, and testing that RPA has always required, and quietly stops doing that harder work because the flow appears to keep running. The teams getting real value from self-healing so far are treating it as one layer in a broader error-handling stack, sitting below a solid retry policy and above a documented escalation path, rather than as the whole strategy. That means still designing selectors deliberately instead of accepting whatever the recorder captures by default, still monitoring flow run history instead of assuming silence means success, and still budgeting time for the registry-level log review needed to catch a self-healing attempt that quietly picked the wrong element on a screen nobody double-checked afterward.

Used that way, self-healing does what its name suggests for a specific and fairly narrow category of failure: it buys time and reduces the volume of after-hours pages caused by a button that moved six pixels to the left. It does not, and by Microsoft’s own account is not meant to, remove the need for an RPA program that treats maintenance as part of the design rather than an afterthought to it. Routeget Technologies has been walking clients through exactly this kind of phased rollout, piloting self-healing on the least stable external-facing actions in a flow before deciding how far to extend it. That sequencing, more than the feature itself, is usually what determines whether a preview capability like this earns a permanent place in production.

#PowerAutomate #SelfHealingFlows #DesktopFlows #RPAGovernance #PowerPlatform #AutomationReliability

Dynamics 365 Remote Assist Retirement: What Field Service Leaders Do Next

Field service technician wearing a mixed reality headset inspecting industrial equipment

In a field service budget review this quarter, someone is going to ask why next year’s plan still carries a line item for Dynamics 365 Remote Assist. The uncomfortable answer is that it shouldn’t be there at all. Dynamics 365 Remote Assist retirement, alongside its companion product Dynamics 365 Guides, is now official and set for December 31, 2026, a little over three months from today, and new subscriptions or renewals actually stopped being available back on November 1, 2025. Organizations still running technicians through HoloLens-guided repair procedures, or connecting field crews to remote experts through live AR annotation, now have a hard stop on the calendar and, notably, no Microsoft-branded successor waiting on the other side of it.

This is not a routine feature deprecation buried in a release-wave changelog. It is the full retirement of a product category Microsoft spent the better part of a decade building around HoloLens, and it lands squarely on the Service Modules side of Dynamics 365 Customer Engagement, where field service dispatching and remote guidance have quietly become dependent on mixed reality tooling in a way that budget owners do not always track closely. For CIOs, IT directors, and field service operations leaders, the question is no longer whether to plan for this. It is what to do in the next few months before the apps simply stop functioning.

What Dynamics 365 Remote Assist retirement actually shuts down

It helps to separate the two products Microsoft is retiring, because they solve different problems and their replacement paths diverge. Dynamics 365 Guides is the authoring and playback tool for step-by-step, holographic work instructions: a technician wearing a HoloLens sees floating annotations pinned to the actual equipment in front of them, walking through a procedure without needing to hold a phone, a tablet, or a printed manual. Dynamics 365 Remote Assist is the live collaboration layer, letting a field technician share their point of view over a video call while a remote expert draws arrows, circles, and notes directly onto the technician’s real-world field of vision, and, where it is wired into Field Service, pulls booking and work order context directly into that session.

Both applications, along with their supporting Dataverse solution components, reach end of support on December 31, 2026. After that date, Microsoft has been explicit about what stops: no security updates, no bug fixes, no non-security patches, and no technical support. The apps themselves stop working. The one piece of good news is that underlying data, including authored Guides content, remains in the customer’s Dataverse environment rather than disappearing outright, but the applications used to create, edit, and play back that content go dark. Any organization that has not already exported its Guides library through the PC app should treat that as a near-term task rather than something to revisit closer to the deadline.

Mixed reality headset resting on a desk next to a laptop showing a dashboard

Why there is no like-for-like replacement

The retirement traces back to a decision Microsoft made roughly two years earlier and largely outside the Dynamics 365 product conversation: HoloLens 2 production ended, with the company confirming in February 2025 that no further units would be manufactured and no successor headset was in development. Hardware support for existing HoloLens 2 devices continues somewhat longer, into 2027, but the software layer that made those devices useful inside a Dynamics 365 context is being wound down first. That sequencing matters for planning purposes: an organization could, in theory, still have functioning HoloLens 2 hardware in the field well after the Guides and Remote Assist applications that ran on it have been retired.

What replaces the capability is genuinely unsettled, and that is worth saying plainly rather than papering over with reassurance. Microsoft’s own guidance points toward the spatial annotation feature inside Microsoft Teams mobile as the closest first-party option for live remote-assist-style collaboration, letting a remote expert annotate what a technician on a phone or tablet camera is seeing. It is a reasonable fit for lighter-weight scenarios, a quick second opinion on a mechanical issue or a walkthrough of an unfamiliar panel, but it is not a drop-in substitute for hands-free, HoloLens-based guidance on a complex, multi-step repair where a technician genuinely needs both hands free and instructions anchored to the physical equipment. For that heavier use case, Microsoft is pointing customers toward the mixed reality category of the commercial marketplace rather than offering a first-party alternative, which means evaluating third-party vendors, negotiating new licensing, and in most cases paying for a capability that was previously bundled into an existing Dynamics 365 or HoloLens investment.

What this actually costs, beyond the obvious

The immediate financial exposure is the easy part to catch: procurement should already be auditing Dynamics 365 licensing agreements to make sure nobody is still being billed for Guides or Remote Assist seats that will be worthless in a few months, particularly in larger organizations where mixed reality licensing was bundled into a broader Dynamics 365 or Microsoft 365 agreement and easy to overlook during a routine renewal cycle. That is a straightforward cost-avoidance exercise, and it should happen this quarter regardless of what an organization decides to do about replacement tooling.

The harder cost is the one field service leaders tend to underestimate: re-authoring. Any organization with a meaningful Guides content library, holographic work instructions built up over months or years for specific equipment models, safety procedures, or onboarding sequences, is going to need to rebuild that content on whatever platform replaces it, because the format is not portable in any turnkey sense. A 200-guide library built for HoloLens playback does not simply import into a third-party AR tool or a Teams-based workflow. Depending on how content-heavy the current deployment is, that re-authoring effort can rival or exceed the cost of the original build-out, and it is the piece most likely to get underestimated in a budget conversation that focuses only on licensing fees.

A practical response for the next quarter

The first step, before evaluating any specific replacement, is an honest inventory of who is actually using Guides and Remote Assist today, for what scenarios, and how often. Mixed reality tooling has a well-documented pattern of enthusiastic pilot adoption followed by quiet underuse once the novelty wears off, and some organizations will find that usage has already dwindled to a handful of technicians or a single business unit, in which case the retirement is an opportunity to simply stop paying for a capability that was not delivering proportional value rather than a crisis requiring a like-for-like replacement.

For organizations where usage is genuine and operationally important, the decision splits along the same line the capability itself splits on. Lightweight remote collaboration scenarios, a technician needing a second set of eyes on something unfamiliar, can likely move to Teams mobile’s spatial annotation with minimal disruption and no new procurement cycle. Hands-free, instruction-heavy scenarios tied to specific equipment and repeatable procedures need a dedicated evaluation of marketplace alternatives, budgeted as a genuine new software category rather than a lateral move, with enough lead time to pilot, contract, and re-author content before the December cutoff rather than after it.

Routeget Technologies has been helping clients work through exactly this kind of transition assessment, mapping current Guides and Remote Assist usage against actual field service outcomes before recommending whether a replacement is warranted at all. The retirement itself is not really the hard problem. The hard problem is that most organizations have not looked closely enough at how this capability is actually being used to know what they would be replacing, and that assessment is the work that needs to start now, not in November.

#DynamicsFieldService #RemoteAssistRetirement #MixedReality #FieldServiceOperations #ITAssetLifecycle #Dynamics365CE

Configuring Financial Report Packages for Month-End Distribution in Business Central

Finance controller reviewing a bundled financial report dashboard during month-end close

A controller at a mid-market manufacturer spends the first three days of every close cycle doing something that has nothing to do with accounting: assembling a stack of PDFs. The profit and loss statement goes to the executive team. The balance sheet and a G/L detail extract go to the audit committee. A budget variance report goes to department heads, each filtered to their own cost center. In Business Central, every one of those documents has lived as its own Financial Report, generated and distributed on its own schedule, which means close week turns into a sequence of separate print jobs, separate emails, and separate chances to send the wrong version to the wrong list.

That specific problem, bundling several financial statements into one coherent, schedulable output, is what Financial Report Packages address in Business Central 2026 release wave 2. The feature landed in the update 29.0 public preview in September 2026, and it is worth understanding now, while it is still confined to sandbox environments, so that the rollout plan for general availability in October is already written by the time the feature reaches production.

Finance controller reviewing a bundled financial report dashboard during month-end close

What changed, and what didn’t, in wave 1

It helps to be precise about what already existed before this. Business Central 2026 release wave 1 (BC28) gave Financial Reports scheduling for the first time. Before BC28, a Financial Report could only be printed on demand; there was no way to have it generate and land in an inbox automatically. Wave 1 fixed that at the level of a single report: from the Financial Reports page or the Financial Report Card, the Schedules action let you configure a code, a description, an “Export to PDF” or “Send Email” option, a list of recipients pulled from User Setup email addresses, a Next Run Date/Time, and a Recurrence Run Date Formula. Each scheduled run created a Financial Report Export Job entry in Job Queue Entries, and you could stack multiple schedules against the same report if different audiences needed it at different cadences.

That was genuine progress, but it left the packaging problem untouched. A controller with five statements to distribute still needed five schedules, five separate emails landing in five separate messages, and no guarantee they arrived in a sequence or format anyone downstream found usable. Wave 1 solved recurrence. It didn’t solve composition.

How Financial Report Packages work

Financial Report Packages, new in the 29.0 preview, introduce a container object that sits above individual Financial Reports rather than replacing them. You reach it either through Tell Me by searching “Financial Report Packages” or via a Packages action on the Financial Reports page itself. Creating a package starts with a header record (the Financial Report Package table, internally table ID 8371) where you set a name and description, the same way you would name any reusable configuration object in Business Central.

The substance of the package lives in its lines, stored in the Fin. Report Package Report table (ID 8372). Each line points to an existing Financial Report, and this is where the design gets genuinely useful for anyone who has fought with one-size-fits-all reporting: every line can carry its own custom filters and its own date formula, independent of the other reports in the same package. A P&L line might use a “-CM” to “CM” formula to lock onto the current month, while a companion cash flow line in the same package uses a trailing twelve-month range. You’re not forcing every statement in the bundle onto identical dimensions or identical periods just because they’re shipping together.

Once the lines are configured, two actions do the actual work. Print generates the combined output immediately, useful for testing a package before you trust it to run unattended, or for the occasional ad hoc request from a board member who wants “everything” right now. Schedules is where the recurring value shows up: you can set multiple schedules per package, each with its own Next Run Date/Time and Recurrence Run Date Formula, and each capable of emailing multiple recipients whose addresses come from their User Setup records. Every run is tracked in a log, so when someone asks whether the March package actually went out, there’s a record rather than a guess.

The output itself still surfaces through the Report Inbox, the existing Business Central page that lists reports generated by scheduling rather than by the Print action, and that also supports pushing files to OneDrive or sharing them with a link. Packages don’t bypass that infrastructure; they feed it a combined file instead of a single-report one.

Close-up of a laptop showing a bundled financial report configuration next to printed statements during month-end close

Setting this up without recreating the wave 1 mess

The mistake to avoid is treating a package as a folder you drop existing schedules into. It isn’t. If you already built individual report schedules under the wave 1 model, plan to retire the redundant ones once a package covers the same distribution, or you’ll end up with both the old single-report emails and the new bundled PDF landing in the same inboxes, which is a worse experience than the one you started with.

Design packages around who receives them, not around how the reports happen to be organized in the Financial Reports list. An executive package might combine the P&L and a cash position summary. An audit-committee package might combine the balance sheet with a G/L detail extract and nothing else, since that audience doesn’t want departmental variance noise mixed in. A department-head package might need per-line filters set to each recipient’s cost center dimension, which is exactly what the line-level custom filters are built to handle. Because each line’s filter and date formula are independent, you can serve genuinely different audiences from the same underlying report definitions without maintaining duplicate report objects just to vary the scope.

One prerequisite is easy to miss until it breaks a scheduled run: every recipient needs a valid email address on their User Setup record. If it’s missing, the system doesn’t fail silently; it throws an explicit error stating the User Setup does not exist, which is at least diagnosable, but it’s worth confirming recipient setup as a checklist item before you go live with any package schedule rather than discovering the gap on the first missed delivery.

Why this matters more than it looks like it should

The same 29.0 preview also introduced G/L account usage tracing for financial report authors, letting you identify uncategorized accounts and preview a report’s calculations before publishing changes to its definition. That capability matters more once packages exist than it did when every report shipped alone. A calculation error or an uncategorized account sitting quietly in one standalone report is a problem for one audience. The same error sitting inside a package that bundles three statements into a single PDF for the executive team turns one mistake into a credibility problem across every report in the bundle, delivered in one shot. If you’re adopting packages, adopt the account tracing discipline alongside them, particularly for any report line feeding a package that goes to leadership.

It’s also worth being honest about timing. Everything described here is currently a preview feature, available only in Business Central online sandbox environments as of the September 2026 update, with Microsoft’s own documentation cautioning that preview features aren’t intended for production use and may carry restricted functionality until general availability, expected in October 2026. That’s a reasonable amount of time to build and test packages against a real close cycle in a sandbox before betting a live month-end on them. Treat October as the date you flip the switch in production, not the date you start figuring out how packages should be structured.

For an organization that has been assembling a five-document close package by hand every month, that lead time is the useful part. There’s no reason to wait for general availability to define which reports belong in which package, which filters each line needs, and which schedules match your actual close calendar. Doing that groundwork in the sandbox now means the October rollout is a configuration change, not a redesign, and Routeget Technologies typically structures exactly this kind of preview-to-production pilot as a parallel run: the new package alongside the existing manual process for one full close cycle, so any gap surfaces before it reaches an executive inbox.

#BusinessCentral #FinancialReportPackages #MonthEndClose #ERPReporting #FinanceAutomation

Dynamics 365 Project Operations Adds a Fix for Cash Advance Exchange Rate Variance

Finance controller reviewing a multi-currency expense reconciliation dashboard in a modern office

A controller at a global engineering firm closes out Q2 and finds forty-one employee vendor accounts sitting at small nonzero balances, a few cents here, a few dollars there, all tied to cash advances issued in one currency and expensed in another. None of it is fraud. None of it is even really an error. It is simply what happens when a consultant draws a 500 EUR travel advance in Frankfurt, spends it against invoices priced in EUR three weeks later, and the accounting system converts both legs to USD using two different exchange rates. That gap is cash advance exchange rate variance, and for years in Dynamics 365 Project Operations, closing it has meant a manual journal entry, a write-off, or a permanently open subledger line that audit eventually asks about.

For finance leaders running project-based businesses across borders, that is not a rounding error problem. It is a data quality problem that quietly distorts two things CFOs actually rely on: the accuracy of project margin reporting and the integrity of the month-end close. When exchange rate noise gets buried inside project cost lines instead of isolated as a currency gain or loss, a project that is performing exactly to budget can appear to be overrunning, or vice versa, purely because of when and where an employee happened to spend an advance.

Finance controller reviewing a multi-currency expense reconciliation dashboard in a modern office

Why This Has Been Hard to Fix Cleanly

The mechanics explain why this has persisted. A cash advance in Project Operations is tracked in the currency it was requested in, and the system has long supported reducing that advance automatically as expense reports are submitted against it. That part works fine when the advance and the expense are denominated in the same currency and settled close together. The trouble starts when they are not: an advance drawn in EUR against expenses ultimately reported in a mix of currencies, or an advance settled weeks or months after it was issued, during which the exchange rate has moved. Historically, the system had no dedicated mechanism to isolate that movement as its own transaction. The employee’s vendor account either carried a residual balance indefinitely or someone in accounts payable manually calculated and posted the variance by hand, entity by entity, advance by advance.

For a firm with a handful of international projects, that manual step is an annoyance. For one running hundreds of consultants across a dozen currencies, it becomes a recurring close-cycle task that scales with headcount and travel volume, and it is exactly the kind of manual, judgment-based adjustment that internal and external auditors tend to flag when they see it repeated month after month.

Close-up of an international business traveler's desk with foreign currency, receipts, and a laptop showing an expense dashboard

How the New Cash Advance Exchange Rate Variance Fix Works

Microsoft’s cash advance exchange rate adjustment capability, released to public preview on July 31, 2026, is built specifically to close this gap. Rather than settling a cash advance purely against accounting currency, the feature bases settlement on transaction currency and automatically detects, calculates, and posts the resulting realized foreign exchange gain or loss. The stated design goal is straightforward: an employee’s vendor account should net to zero once a cash advance is fully settled, with any currency movement broken out as its own recognized amount rather than absorbed silently into the balance.

A simple illustration makes the mechanism concrete. An employee draws a cash advance of 100 EUR, recorded at 140 USD under the exchange rate in effect that day. Three weeks later, the employee submits an expense report for the same 100 EUR, but the rate has moved and the accounting equivalent is now 150 USD. Under the new capability, the system recognizes a 10 USD realized foreign exchange gain, posts it to the configured FX gain account, and closes the vendor balance out to zero. No residual line, no manual calculation, and critically, no distortion of the project’s actual cost lines, since the currency movement is captured separately rather than folded into expense cost.

The feature also builds in the kind of traceability that finance and audit teams specifically ask for during control reviews. Each adjustment carries navigation back through related vouchers, from the original cash advance to the expense report that triggered settlement to the specific FX variance transaction, so a reviewer can trace the full chain rather than reconstructing it from disconnected general ledger entries.

What This Actually Changes for Finance Leaders

The practical benefit is less about the accounting mechanics themselves and more about what they stop contaminating. Once currency variance on cash advances is automatically isolated, project profitability reporting gets meaningfully cleaner, because cost lines reflect actual project spend rather than a blend of spend and unrelated exchange rate movement. That matters more than it sounds, particularly for firms that price fixed-fee international engagements and rely on margin data to make staffing and pricing decisions on the next similar project. A margin figure that has been quietly absorbing FX noise for two years is not a small reporting inconvenience; it is a data integrity problem sitting underneath real business decisions.

There is also a straightforward labor and close-cycle argument. Every manual FX variance calculation that a firm’s shared services or accounts payable team performs by hand is time that does not scale, and it is exactly the category of adjustment most likely to be done inconsistently across regions or entities when it is left to individual judgment rather than a system-enforced rule. Automating it does not just save hours, it removes a source of inconsistency between how one controller in one country handles a variance and how another controller in a different entity handles the same situation.

Rollout Considerations Before Enabling It

This is a preview capability as of this writing, which carries the usual caveat that behavior may still change before general availability, and CFOs evaluating it should treat that as a real constraint on timing rather than a formality. Two prerequisites matter before the feature can even be turned on: the “mapping cash advances to expense lines” capability must already be enabled in the environment, and there can be no partially mapped cash advances outstanding at the time the new feature is activated. That second condition is not trivial for an organization with a large volume of open advances; it effectively requires a cleanup pass through existing cash advance records before flipping the switch, which is worth scoping as its own short project rather than assuming it happens automatically. The feature also requires a minimum platform version, Dynamics 365 Finance release 10.0.49 or later, so version currency is a gating question worth confirming with IT before this goes anywhere near a finance steering committee agenda.

There is a policy conversation worth having alongside the technical rollout, too. Realized FX gains and losses need to land in accounts that align with how corporate accounting already classifies currency movement elsewhere in the business, and treasury or corporate accounting should confirm that mapping rather than leaving it to whichever team configures the feature. For organizations operating under both GAAP and IFRS reporting in different entities, it is worth a direct conversation about whether the automated posting behavior matches existing policy for realized versus unrealized FX treatment before this runs against live cash advances rather than after.

The sensible sequencing looks like a pilot in one entity with meaningful cross-currency travel volume, ideally one that has visibly struggled with recurring FX write-offs, run in parallel with the existing manual process for a full close cycle before cutting over more broadly. That gives finance leadership a real before-and-after comparison rather than a leap of faith, and it surfaces any gaps in how the automated posting interacts with an organization’s specific chart of accounts before the feature is relied upon across every entity at once. Firms that have worked with implementation partners such as Routeget Technologies on other finance automation rollouts tend to find the same pattern holds here: the capability itself is straightforward, but the sequencing around data cleanup, policy alignment, and a genuine pilot period is what determines whether it lands as a quiet improvement or a source of new reconciliation headaches six months from now.

Currency variance on cash advances was never a large dollar figure on its own. Its real cost has always been the noise it introduces into numbers that finance leaders use to make decisions, and the manual effort spent chasing it down every close. Closing that gap cleanly is a small technical change with an outsized effect on how much confidence a CFO can place in project-level financial data.

#ProjectOperations #CashAdvanceReconciliation #ExchangeRateVariance #ExpenseManagement #ProjectAccounting #FinanceTransformation

Configuring Parallel Archive Processing in Dataverse Long-Term Retention

IT operations team reviewing data processing and capacity dashboards in a modern operations center

A solution architect running Dynamics 365 Finance and Operations across forty legal entities kicks off an archive job for General Ledger transactions on a Friday afternoon, then checks back a week later to find eleven entities still sitting in the queue. Each job runs start to finish before the next one begins, so a single line of sequential processing does all the work no matter how much idle capacity sits behind it. That queue is a direct consequence of how Archive with Dataverse Long-Term Retention was originally built: one job in flight per scenario, and everything else waits. Microsoft’s March 2026 private preview changes that constraint, and it does so through one new configuration concept worth understanding before requesting access: the job criteria key that makes parallel archive processing possible.

Why Dataverse Archive Jobs Queue Up Today

Archive with Dataverse Long-Term Retention moves data through three stages: active, historical but retained for compliance, and eventually deleted. Getting a record from the first stage to the second is a six-step background process: replication into Dataverse, marking the source record as eligible, updating its retention status, reconciling that the copy landed correctly, migrating it out of the live table, and finally exposing it to inquiry pages that can still read history. Depending on data volume, that full cycle runs seven to fourteen days, and it runs at a deliberately low priority so it doesn’t compete with transactional workloads during business hours.

The scenarios supported today span general ledger and tax transactions in Finance, inventory transactions, inventory journals, and sales orders in Supply Chain Management, and commerce transactions in Commerce, with more expected in future releases. None of that changes with parallel processing. What changes is how many of those seven-to-fourteen-day cycles a tenant can have running at once. Until this preview, the answer was one, regardless of whether an organization operates three legal entities or three hundred. A multi-entity deployment with a genuine general ledger archiving need could watch a backlog grow for months simply because the platform had no concept of running two independent jobs side by side, even when the two jobs touched completely unrelated data.

What Parallel Archive Processing Actually Requires

The mechanism Microsoft introduced is narrower than “run everything at once.” It hinges on a job criteria key, a partition identifier assigned when an archive job contract is created. When the scheduler sees two jobs with different criteria key values, it checks whether they target non-overlapping sets of records, and if they do, it lets both run concurrently instead of forcing the second to wait. If they don’t, or if the system can’t establish that they don’t, the original sequential behavior still applies.

That non-overlap condition is stated as an absolute in Microsoft’s own documentation: each job with a different criteria key value must process a completely distinct set of records, with zero overlap. There is no partial-credit version of this feature where jobs run concurrently and reconcile conflicts afterward. DataAreaId, the field that already partitions Finance and Operations data by legal entity, is the criteria key Microsoft is leading with in preview, and it’s an obvious starting point precisely because it satisfies that zero-overlap requirement by construction. Two legal entities never share a General Ledger transaction, so keying parallel jobs off DataAreaId is close to a free performance win rather than a configuration exercise with real risk attached, provided the archival scenario itself doesn’t reach across entity boundaries somewhere a solution architect hasn’t accounted for.

Solution architect reviewing a parallel data partition and processing pipeline diagram

Configuring the Job Criteria Key

The scenario itself doesn’t change; the contract does. When an archive job contract is created, the criteria key value is set alongside the usual scope of tables and date ranges, and it’s this value the scheduler reads to decide whether two in-flight jobs can share the pipeline. In practice, that means an implementation planning parallel General Ledger archiving across, say, twelve legal entities creates twelve contracts, one per DataAreaId value, rather than a single contract configured to somehow fan out internally.

Once jobs are running, the Archive with Dataverse Long-Term Retention workspace is where the criteria key earns its keep operationally. It surfaces each job’s key value alongside its status, so an administrator can confirm at a glance that the jobs actually running in parallel are the ones intended to run in parallel, rather than discovering after the fact that two jobs quietly targeted overlapping data. For organizations building custom archival scenarios against custom tables, the sequencing matters here specifically: those custom scenarios and their criteria key logic need to be defined and validated before the first parallel job runs against them, not adjusted afterward, because the zero-overlap guarantee has to hold from the first concurrent execution onward.

Where This Can Go Wrong

The zero-overlap requirement is also where the risk concentrates. A criteria key that looks like a clean partition on paper, a custom dimension that’s supposed to map one-to-one with a business unit, for instance, can turn out to have edge cases where two values legitimately touch the same record, particularly in customized environments where table relationships have been extended past their original design. Because the preview enforces zero overlap by requirement rather than by runtime detection of every possible conflict, the burden of proving that a custom criteria key is safe sits with the team configuring it, not with the platform.

Two other details are easy to miss because they don’t show up until after a job finishes. First, capacity reporting lags the actual archival work: history table capacity reductions from automatic tuning can take up to seven days to appear, and Dataverse’s own capacity figures take up to a day to catch up. Running four jobs in parallel instead of one doesn’t make that lag disappear, so finance and IT stakeholders expecting an immediate storage win on the day parallel jobs complete need that timeline set correctly in advance. Second, organizations that use customer-managed encryption keys should know that long-term retained data lands under Microsoft-managed keys regardless of how many jobs move it there in parallel, which means a CMK migration for that retained data is a separate project, not something parallel processing resolves as a side effect. Finance and operations attachments still aren’t supported in any configuration, and while data that hasn’t yet been archived can be handled through normal processes, data that has already made the trip into Dataverse long-term retention cannot be pulled back to live tables.

Piloting Before You Commit

Because this is a private preview, access starts with an enrollment request rather than a feature flag, and the honest advice for anyone requesting it is to have a specific backlog problem in mind rather than general curiosity about the feature. Organizations with dozens of legal entities and a General Ledger or inventory transaction archive that has been queuing for weeks are the clearest fit. A three-entity organization archiving a modest transaction volume is unlikely to notice much difference between sequential and parallel processing, since the queue was never the real bottleneck to begin with.

IT and finance team reviewing a data storage capacity and governance chart

Once enrolled, the safer rollout path is to pilot parallel jobs against two or three legal entities in a sandbox first, confirm through the workspace that the criteria keys behaved as expected and that no overlap issues or data inconsistencies surfaced, and only then scale up to the full legal entity list in production. Given that archived data can’t be moved back to live tables, a misconfigured criteria key is not a mistake worth discovering at production scale. Treat the capacity reporting lag and the CMK migration question as items to raise with finance and security stakeholders during that same pilot, not after the first production jobs complete, so nobody is caught explaining an unexpected reporting delay or an encryption gap after the fact. For organizations already running Archive with Dataverse Long-Term Retention against a multi-entity Finance and Operations deployment, this preview is worth requesting now. Routeget has been helping clients sequence long-term retention rollouts around exactly this kind of phased validation, and parallel archive processing is a natural next step for any environment where the backlog, not the archive design itself, has become the actual problem.

#DataverseArchive #ParallelProcessing #LongTermRetention #DynamicsFinanceOps #DataCapacityPlanning #CloudArchitecture

Power Apps Offline Profiles Just Got Easier to Build, Not Easier to Govern

Field service technician using a mobile tablet app in a low-connectivity industrial environment, representing Power Apps offline mode for field workers

A regional field service operation gave its dispatch team the green light to build a canvas app for technicians working in cellular dead zones: rural service calls, basement mechanical rooms, warehouses with concrete walls that killed every signal. The maker who built it, an operations analyst with no formal development background, had the app running offline in an afternoon. No ticket to IT, no admin center request, no waiting on a platform team’s sprint capacity. Three weeks later, a technician’s equipment inspection notes from a Friday afternoon call never made it into Dataverse. The app had been minimized on his phone all weekend while he checked email and texted his dispatcher, and Power Apps only syncs when it is actually running in the foreground. The data was not corrupted or lost outright, but it sat unsynced long enough that a compliance audit flagged a two-day gap in a safety inspection record that mattered.

That scenario is becoming more common, and it traces directly back to a change in how Power Apps offline profiles get created in the first place, a shift most IT organizations have not caught up to yet.

Field service technician using a mobile tablet app in a low-connectivity industrial environment, representing Power Apps offline mode for field workers

Power Apps Offline Profiles Move to Maker Studio

Until December 2025, configuring an offline profile for a Dataverse-backed canvas app meant a trip to the Power Platform admin center. A system administrator or system customizer had to define which tables synced, set filters to control data volume, and manage relationships, all through an admin-only surface that kept offline configuration inside IT’s field of view almost by accident. That friction was never framed as a governance control, but it functioned like one: nothing went offline without someone with elevated permissions touching it first.

Microsoft’s 2025 release wave 1 changes removed that checkpoint. Offline profile creation moved directly into Power Apps Studio, reaching general availability on December 12, 2025. A maker building a canvas app can now toggle “Can be used offline” in the app’s settings, generate a new profile from the app’s existing data sources, and publish, without ever leaving the maker experience or requesting elevated access. Microsoft’s stated rationale is reasonable on its face: reduce dependency on admin resources, shorten the path from idea to working field app, and let the people closest to the operational problem build the solution. For a citizen developer with a genuine business need and no admin relationship to lean on, that is a meaningful unblock.

The Governance Question Nobody Configured

The trade being made here is not really about ease of use. It is about who decides that a given business process is allowed to run detached from the server for hours or days at a time, and who is accountable when that detachment causes a problem. Under the old model, an admin reviewing an offline profile request had at least the opportunity to ask whether a given table should sync offline at all, whether the data involved needed tighter access controls, or whether the use case justified the storage and sync overhead. Under the new model, that opportunity does not exist unless an organization builds a replacement for it.

This is not a hypothetical concern specific to one industry. Any Dynamics 365 or Power Platform environment with field technicians, warehouse staff, inspectors, or delivery personnel is a candidate for exactly the pattern described above: a well-intentioned maker solves a real connectivity problem, and the governance layer that used to exist by default is simply gone unless someone rebuilds it deliberately. Organizations that have invested in a Center of Excellence practice are better positioned here, but a CoE toolkit built around monitoring app creation and DLP policy does not automatically extend visibility into offline profile configuration specifically, since that setting lives inside the app rather than as a separate governed artifact.

IT director reviewing a data synchronization and governance dashboard, representing oversight of Power Apps offline profile configuration

Where the Ceiling Actually Sits

Setting governance aside, the built-in offline engine that now powers this has real technical boundaries that a maker moving quickly can hit without realizing it. Dataverse enforces a hard cap of three million total records synced per offline profile, counting hidden system tables the platform uses internally to support offline mode, and a profile that exceeds it fails to sync rather than degrading gracefully. Each table in a profile is limited to fifteen relationships, only one of which can be a many-to-many or one-to-many type, and an offline profile can include at most fourteen image columns across every table involved. Several capabilities common in online apps simply are not supported offline at all: non-Dataverse connectors such as SharePoint or Excel, virtual and elastic tables, calculated and rollup fields (since there is no client-side engine to reevaluate them), the Relate and Unrelate functions, and self-referential or multi-level relationship lookups.

The foreground-sync behavior that caused the technician’s missing notes in the opening scenario is arguably the most consequential limitation for business planning, because it is invisible until it causes a problem. Power Apps only synchronizes offline data while the app is actively running and the device screen is unlocked. There is no background sync service quietly reconciling data the way a native mobile app with push-based sync might. A field worker who closes the app, locks their phone, or switches to another task mid-shift has effectively paused synchronization, and nothing in the default experience tells them that has happened. For a use case involving safety documentation, chain-of-custody records, or time-sensitive service confirmations, that gap deserves explicit attention before the app reaches production, not after an audit finds it.

A Practical Path Forward

None of this argues for reversing the democratization Microsoft has enabled here; the administrative bottleneck it removed was real; a field team should not wait weeks for a platform team to configure something a maker can now do safely in an afternoon. The more useful response is to treat offline-enabled canvas apps as a specific category worth a lightweight review step, separate from the general app governance an organization already applies. That review does not need to be heavy. It can be as simple as requiring any app with offline mode enabled to pass through a short checklist before it reaches production users: confirming the data involved does not exceed reasonable volume for the sync limits described above, confirming the business process can tolerate the foreground-only sync behavior or has been explicitly designed around it (a startup screen reminder, a manual sync button, a status indicator showing pending changes), and confirming someone owns monitoring the Sync Error table for that app rather than assuming silence means success.

It also means updating whatever Center of Excellence monitoring already exists to specifically flag apps where offline mode has been enabled, since that is now a maker-level decision rather than an admin-level one, and the two are not tracked through the same audit trail by default. An organization that already has DLP policies and environment strategy in place is not starting from zero here, but it should not assume that existing governance automatically covers a setting that used to require an admin’s hands and no longer does.

The underlying capability is genuinely useful, and for the right use case, three weeks of unblocked development against three months of waiting for a platform team is not a close call. The organizations that get real value out of this change will be the ones that pair the speed with a deliberate answer to the question the admin center used to answer by accident: who checks this before it goes to the field. Routeget Technologies has walked several clients through exactly this kind of governance retrofit, and the pattern that works best treats offline enablement as a specific, named checkpoint rather than folding it into a general app review that was never built to catch it.

#PowerAppsOffline #CanvasApps #FieldMobility #CitizenDeveloperGovernance #DataverseSync #PowerPlatformGovernance

Your Dynamics 365 Power BI Dashboards Are Getting Faster, Not Instant

IT and finance leader reviewing a real-time analytics dashboard on a wall-mounted monitor in a modern office

An IT Director I know sat through a Monday operations review where the COO pointed at a Power BI inventory dashboard and asked why it still showed Friday’s numbers. The dashboard was labeled “real-time” in the workspace title, a name someone had chosen two years earlier and nobody had revisited since. It wasn’t a bug. It was the honest output of a reporting pipeline that moved data from Dynamics 365 Finance and Operations to Power BI through several intermediate stops, each one adding its own delay before a transaction became a chart.

That gap between when something happens in the ERP and when a decision-maker can see it is the actual cost center in most Dynamics 365 analytics programs, even when nobody puts a dollar figure on it. Microsoft closed a meaningful part of that gap this year with a change that makes Dynamics 365 Power BI dashboards measurably fresher, and the result is worth understanding before your team assumes “real-time” now means what the word implies.

Where the lag actually came from

Most organizations running Dynamics 365 Finance and Supply Chain Management have historically moved data into Power BI through some version of the same pattern: an export process pulls records out of the operational database, writes them as flat files, a separate conversion step turns those files into the columnar format analytics tools actually want, and only then does the data land somewhere Power BI can query it efficiently. Under the older Fabric Link architecture, that meant Dataverse writing data out as CSV first, then a second process converting that CSV into Delta Parquet before it reached the Fabric lakehouse. Each of those stages is a place where a batch job can queue, a conversion can lag behind incoming volume, or a large table can simply take a while to work through.

Layer scheduled Power BI refreshes on top of that, and the staleness compounds. A report built on imported data can only be as fresh as its last refresh cycle, and refresh frequency has practical ceilings tied to licensing tier and workload size. The net effect for a lot of finance and supply chain teams was dashboards that were accurate but rarely current, off by anywhere from thirty minutes to an hour depending on the day’s data volume and where in the refresh cycle a viewer happened to open the report.

What actually changed for Dynamics 365 Power BI dashboards

Microsoft announced general availability of low-latency sync for Fabric Link in a Power Platform blog post published June 9, 2026, and it targets exactly that CSV hop. The new sync engine writes data from the Dataverse database directly into Delta Parquet format in OneLake, removing the intermediate serialization step entirely. Fewer stages means fewer places for a job to fail, less contention on shared resources during the conversion, and a simpler retry path when something does go wrong.

Solution architect at a dual-monitor workstation reviewing an abstract data pipeline and sync architecture diagram

The throughput difference Microsoft cites for Finance and Operations apps specifically is substantial: table sync that previously ran in the range of 100,000 to 700,000 records per hour now reaches upwards of 1 million records per hour per table, under lab conditions the company is careful to note may not match every production environment exactly. Dynamics 365 customer engagement apps see a comparable improvement in delta sync latency, though Microsoft hasn’t published an equivalent throughput figure for that side of the platform. Paired with Power BI’s Direct Lake mode, which queries the Delta tables in OneLake directly instead of importing a copy into the report, the combination removes both sources of staleness at once: the pipeline delay and the refresh-schedule delay.

The rollout followed a staged regional schedule rather than a single cutover. Early release stations had it first, European, Canadian, and Indian environments picked it up in late June 2026, Asia Pacific, Japan, the UAE, Australia, and the UK followed in early July, and the remaining stations, including most of the Americas, were targeted for general availability by the end of July 2026. Microsoft flagged those windows as approximate and subject to change based on deployment health, which is a reasonable caveat for any organization trying to plan a go-live date around it.

What “near real-time” actually buys you

Here is the detail worth putting in front of whoever asked for real-time dashboards in the first place: this is a genuine and measurable improvement, but it is not streaming analytics. Practitioner reporting on the feature places typical data freshness in the range of fifteen to forty-five minutes after a transaction posts, down meaningfully from the roughly sixty-minute staleness common under the old architecture and refresh-schedule combination, but still a real interval. If your business actually needs second-by-second visibility into something like a production line sensor feed or a live transaction stream, that’s a different Fabric capability, Real-Time Intelligence, built around event streams and purpose-built for that use case rather than general ERP reporting.

Setting that expectation correctly matters more than the technical detail, because a COO who was told a dashboard is “real-time” and then watches it lag by half an hour during a busy close period will lose trust in the tool faster than one who was told upfront to expect fifteen-to-forty-five-minute freshness and sees exactly that. The fix here is genuinely good news for finance and supply chain reporting. It just isn’t the specific thing the word “real-time” tends to promise in a boardroom conversation.

The decisions this forces onto your roadmap

For organizations already on Fabric Link, adopting the new engine isn’t automatic. Existing links have to be unlinked and reconnected once a given environment’s region has been enabled, and Microsoft is explicit that relinking triggers a full initial resynchronization of every configured table, not an incremental catch-up. For a large Finance and Operations environment with years of transaction history, that’s not a trivial operation to schedule during business hours, and it’s worth treating as a planned cutover with its own change window rather than a background toggle. You can confirm a link has moved to the new engine by checking the Azure Synapse Link section in the admin experience for a “low-latency mode” flag against the profile.

There’s a version dependency to check before assuming your environment even qualifies. Microsoft’s guidance points organizations to verify their Finance and Operations build against the minimum supported version documented for low-latency sync, commonly cited around release 10.0.46 and later builds; if your environment hasn’t been kept current, that’s worth confirming with your applications team before the migration gets scheduled rather than after.

There’s also a budget conversation worth having early. Fabric Link’s replication model increases Dataverse storage consumption, since the platform is now maintaining a synchronized copy of operational data inside the Fabric environment; the compression Delta Parquet provides offsets some of that, but not all of it, and IT Directors sizing next year’s Fabric capacity should factor that in rather than discovering it in a usage report. Organizations that specifically need data exported into storage accounts they control, rather than accessed through Fabric shortcuts, still have Azure Synapse Link as an alternative path, though it carries its own Spark pool compute costs that scale with refresh frequency and change volume.

Finally, this is a reasonable moment to revisit whether your organization is still running the older Export to Data Lake integration. Microsoft’s messaging has been consistently pointing customers toward Fabric Link as the forward path, and while no hard retirement date has been published as of this writing, an environment still depending on the older CSV-based export is not going to benefit from any of the improvements described here. Rolling that conversation into the same project as the low-latency migration, rather than treating them as separate initiatives six months apart, saves a second round of testing and stakeholder communication.

Getting the rollout right

None of this requires a rebuild of your analytics estate. It requires a version check, a scheduled relink with real downtime planning around the resync, an honest conversation with the business about what “near real-time” will and won’t deliver, and a capacity plan that accounts for the storage shift. Organizations that have gone through a few rounds of Dynamics 365 and Power BI platform changes tend to treat this kind of update as routine infrastructure work rather than a special project, which is generally the right instinct. Routeget has walked several clients through exactly this kind of Fabric Link migration, and the pattern that separates a clean cutover from a messy one is almost always the same: confirm the prerequisite build first, schedule the resync deliberately, and set the freshness expectation with stakeholders before the new dashboard goes live, not after someone notices the timestamp.

#PowerBI #MicrosoftFabric #DynamicsFinanceOps #DataLatency #DirectLakeMode #FinanceReporting

Configuring Dynamics 365 Email Sensitivity Labels Without Losing Copilot

IT security and compliance professional reviewing an email data classification and encryption dashboard

A Customer Service administrator at a regulated financial services firm spent most of Q1 rolling out Microsoft Purview sensitivity labels across the organization’s email traffic, a project driven by a compliance mandate that had nothing to do with the contact center. Once Dynamics 365 email sensitivity labels went live in the Customer Service workspace, the security team considered the job done. Three weeks later, a supervisor noticed that case summaries were quietly missing for a cluster of escalated tickets, and Copilot’s intent detection wasn’t firing on a subset of inbound email at all. The two projects, security and AI, had never been evaluated together, and nobody had checked whether the feature that satisfied the compliance mandate was compatible with the feature the contact center had spent the prior year building its workflows around.

That collision is becoming common enough to plan for directly. Data sensitivity labels for email reached general availability in Dynamics 365 Customer Service on May 1, 2026, giving service representatives a native way to classify and protect outbound and inbound messages using labels defined centrally in Microsoft Purview. It is a genuinely useful capability, and for regulated industries it is close to mandatory. But it was shipped as a security feature, evaluated by security teams, and its interaction with Copilot-driven case automation is easy to miss until an agent asks why a summary never generated.

What Actually Ships With the Feature

The capability itself is narrow and well-scoped: agents get a Sensitivity Label dropdown in the command bar, available both when reading an inbox item and when composing or replying to an email, inside the Customer Service workspace and Contact Center apps. Labels are not created in Dynamics 365 at all. They are authored in the Microsoft Purview compliance portal, under Information Protection, where an administrator defines the label’s name, priority, scope, and, critically, its protection settings, including whether it carries encryption, a Do Not Forward restriction, or a visual marking like a watermark or header. Once that label policy is published tenant-wide, it becomes available inside Dynamics 365 without any additional publishing step on the Dataverse side.

What surprises a lot of technical teams is how much of the actual behavior is inherited from Purview rather than configured in Dynamics 365. A label that carries an encryption policy behaves identically whether it was applied from Outlook, from Word, or from a Customer Service email form: the message becomes a protected, rights-managed object the moment the label is applied, not a cosmetic tag on a Dataverse record.

Configuring Dynamics 365 Email Sensitivity Labels: The Two-Step Setup

The rollout has two distinct halves, and skipping the prerequisites is the most common reason a pilot stalls. Before anything happens inside Dynamics 365, the environment needs an email server profile configured for Server-to-Server Authentication against the same tenant’s Exchange Online, and server-side synchronization for email has to already be running. Neither of those is new infrastructure specific to this feature, but plenty of sandbox and dev environments never had them fully wired up, since basic email testing doesn’t require them.

With that in place, enabling the feature itself is a single toggle: in the Power Platform admin center, under the target environment’s Settings, expand Email, open Email Settings, and switch on “Enable data sensitivity labels for emails.” The second half of the work happens in Power Apps rather than the admin center. Inside the relevant solution, add the Email table’s main form to the solution if it isn’t already there, open the form in the designer, locate the “Sensitivity label” column, and drag it onto the canvas. On its own that column just stores a value, so the practical step is adding the “Email sensitivity label control” component to the same field and configuring it, then saving and publishing the form. Skip that control and the column exists on the record but agents never see anything to interact with.

One detail worth flagging to the security team directly: the Entra ID identity associated with the mailbox needs its own permissions in Microsoft Purview to apply the labels that are relevant to that queue. This is a common gap in shared-mailbox and queue-based routing setups, where the mailbox identity was provisioned years ago for basic send/receive and never touched again.

Solution architect configuring email sensitivity label settings in a Dynamics 365 environment

How Enforcement Actually Behaves in Practice

Once labels are live, the enforcement rules mirror what a user would expect from Outlook, and that consistency is deliberate. A label like Do Not Forward or Do Not Reply restricts the corresponding action for recipients inside the organization, and an agent cannot manually downgrade a message to a less restrictive label than the one already applied, so a “Confidential” thread can’t be quietly relabeled “General” to make it easier to forward externally. Replies and forwards inherit the label of the message being responded to by default, which is the behavior most compliance teams actually want, since it removes the judgment call from the agent in the moment they’re least likely to think about it. Attachments carry their own labels independently, and when an attachment’s label conflicts with the email’s label, the interface surfaces which one takes precedence rather than silently picking one.

Where this gets operationally interesting is auto-labeling. Purview supports content-based auto-labeling, where a label gets applied automatically based on what the message contains, and that setting lives entirely in Purview, invisible from the Dynamics 365 side. A queue that starts seeing a spike in encrypted, auto-labeled mail didn’t necessarily have a policy change made against it directly. Somewhere upstream, a Purview label’s auto-apply conditions matched more content than before.

The Gap Nobody Tests For: Encrypted Mail and Copilot

This is the part of the rollout that deserves its own test plan rather than a footnote. When a label applies encryption protection, Dataverse does not decrypt or store the message content. The email still appears in the case timeline, so an agent knows the correspondence exists, but the body is not readable inside the application at all. Agents are redirected to Outlook on the web to open and decrypt the message there.

That gap propagates directly into every Copilot capability that depends on reading email content. Case summarization skips encrypted messages entirely, meaning a case summary generated near the end of a long thread may be missing the specific email that actually contains the customer’s core complaint, if that thread’s most detailed message happened to carry a Confidential-and-Encrypted label. Case enrichment, intent detection, and any Copilot workflow built around analyzing inbound email content behave the same way: they simply do not see encrypted mail, and there is no fallback summarization or partial analysis. From the AI feature’s perspective, the message is invisible, not redacted.

For a technical team that built intent-based routing or auto-summarization as part of a Copilot rollout, this means the encryption policy decided in a completely separate Purview governance project can silently degrade the reliability of automation the contact center is depending on operationally. Neither team is wrong about their own configuration. The interaction between the two simply isn’t visible from inside either admin surface on its own.

Rolling This Out Without Breaking What Already Works

The practical fix isn’t to avoid sensitivity labels, since for a regulated organization that usually isn’t optional, and blanket-disabling encryption defeats the purpose of the compliance project in the first place. The fix is sequencing the two conversations that normally never happen in the same room. Before a label policy that carries encryption goes anywhere near production mailboxes tied to Customer Service queues, pull a sample of real case threads that currently drive summarization or intent detection, and run them through the label to see which specific messages would become invisible to Copilot under that policy. That test takes an afternoon and reliably surfaces problems that would otherwise take weeks to notice in production, one confused agent at a time.

It’s also worth treating auto-labeling as a change management event even though it technically lives entirely in Purview. Any time compliance adjusts an auto-apply condition on a label with encryption attached, that change has a direct, measurable effect on Copilot coverage in the contact center, and the service delivery team should be in the notification loop for that change, not discovering it through a drop in summarization quality. Finally, agents need to know the Outlook-on-the-web redirect path exists and why it exists, rather than treating an unreadable encrypted email in the case timeline as a bug to escalate. A short addition to onboarding material covers this permanently; a support ticket every time it happens doesn’t.

Routeget has walked several clients through exactly this sequencing problem when a compliance-driven Purview rollout landed on top of an existing Copilot investment in Customer Service, and the fix is almost always coordination rather than reconfiguration. Getting the security and the AI roadmap talking to each other before go-live is considerably cheaper than untangling the symptoms afterward.

#DynamicsCustomerService #DataSensitivityLabels #MicrosoftPurview #CopilotService #EmailSecurity #ComplianceGovernance

Business Central 1099 Thresholds Didn’t All Move Together in 2026

Finance controller reviewing a tax compliance and vendor payments dashboard on a wall-mounted monitor in a modern office

A controller closing out Q3 payables in Dynamics 365 Business Central recently found herself staring at a vendor card for a landlord who’d been paid $1,400 in rent through September. Under the threshold she believed applied for 2026, that vendor wouldn’t need a 1099-MISC at all. She was wrong about that specific case (rent does cross the new reporting line), but the mistake that actually worried her had happened two months earlier, when she updated every box minimum in the company’s Vendor Box Setup to a single new number because that was the figure everyone in her network was repeating. Attorney gross proceeds and royalty payments to a handful of consultants quietly stopped generating 1099s the moment she made that change, because neither of those categories moved.

That’s the problem with updating Business Central 1099 thresholds for 2026: the increase is real and significant, but it applies to almost none of Form 1099-MISC uniformly. For a finance team running Business Central, the risk isn’t that they’ll miss the change entirely. Microsoft’s own release notes and every ERP consulting blog covered it. The risk is that they’ll apply it correctly to the one box everyone talks about and incorrectly to the six or seven boxes nobody mentions, inside a system that makes it just as easy to set a wrong minimum as a right one.

Finance controller reviewing a tax compliance and vendor payments dashboard on a wall-mounted monitor in a modern office

What actually changed for tax year 2026

For payments made on or after January 1, 2026, the reporting threshold for Form 1099-NEC nonemployee compensation, and for several categories on Form 1099-MISC, rises from $600 to $2,000. That covers rents, prizes and awards, other income, medical and health care payments, crop insurance proceeds, section 409A deferrals, and nonqualified deferred compensation. It does not cover royalties or broker payments in lieu of dividends and interest, which stay at a $10 minimum, and it does not cover gross proceeds paid to attorneys or purchases of fish for resale, which stay at $600. Interest, dividend, and retirement distribution reporting on Forms 1099-INT, 1099-DIV, and 1099-R sit outside this change entirely, still governed by their own long-standing $10 minimums. Starting in 2027, the $2,000 figure is subject to inflation adjustment, which means the number itself won’t stay fixed even for the categories it does apply to.

One rule that didn’t move at all: any business filing ten or more aggregate information returns across all form types in a calendar year is still required to file electronically rather than on paper. That threshold, which has applied since the aggregation rule took effect for returns filed in 2024, catches most Business Central customers well before they’d ever consider paper filing as an option, which makes the electronic filing path the default rather than a special case.

Business Central 1099 thresholds live box by box, and nothing warns you they differ

Business Central’s current 1099 architecture, rebuilt in the 27.2 release toward the end of 2025, replaced the older preprinted-forms workflow with a set of purpose-built pages: IRS Forms Setup for email templates, IRIS credentials, and TIN protection controls; IRS Reporting Periods for managing each year’s cycle, with a copy-forward action to bring last year’s configuration into the new period; Vendor Box Setup for mapping each vendor to the specific 1099 form and box their payments belong in; and a Form Documents page for generating, reviewing, and transmitting the actual forms.

Accounts payable specialist at a dual-monitor workstation reviewing a vendor tax form configuration screen with a numeric threshold table

The box minimum lives at the box level by design, which is exactly right in principle. The trouble shows up in practice, because nothing in that setup screen warns a controller that the value they’re about to paste into every row isn’t the same value for every row. A company that runs an “Update Form Boxes” pass once a year, changes the number that made the news, and moves on will end up with 1099s that look complete and are quietly wrong. Under-reporting a required form doesn’t just create IRS exposure; it creates a vendor relations problem when that vendor’s own accountant asks where their form went, and a documentation problem when an auditor asks why the threshold on file doesn’t match what’s printed in the IRS’s own instructions for that box.

What native filing now covers, and where it still stops

The bigger structural change in Business Central’s 1099 handling isn’t the threshold at all. It’s that the platform can now submit forms directly to the IRS’s Information Returns Intake System, IRIS, through an API integration that reached general availability on November 1, 2025, for Business Central Online. Forms transmit without a manual export and re-import step, and an IRIS Transmission page tracks status so finance doesn’t have to guess whether a batch went through. Copy B, the version vendors receive, prints or emails as a plain-paper substitute rather than requiring the preprinted stock that year-end close teams used to scramble to order.

That’s a meaningful reduction in the case for a third-party 1099 add-on, but it isn’t a full replacement for one, and it’s worth being specific about why. As of the current release, Business Central’s Form Documents page has no option to print or email every vendor’s form in a single action; each one has to be handled individually, though Microsoft has flagged bulk printing and emailing as coming in a near-term update. TIN matching against IRS records isn’t part of the native workflow, so a company that wants pre-filing verification that a vendor’s name and taxpayer ID actually match still needs to run that check somewhere else. State filing is out of scope too: IRIS handles federal transmission, and any state that doesn’t participate in the Combined Federal/State Filing Program still needs its own submission, which is exactly the kind of gap that standalone 1099 compliance apps in the Business Central ecosystem were built to close and continue to be relevant for. Correction and amendment handling after an original form has already transmitted is also thinner in the native tool than in most dedicated filing services, which matters more than it sounds like it should, since threshold-driven errors are precisely the kind of mistake that generates corrections.

What this means for the close calendar, not just the tax calendar

None of this is a reason to delay adopting the native IRIS integration. Eliminating the preprinted-forms supply chain and the manual transmission step is a genuine operational win, and most finance teams should move onto it as their filing method regardless of what else they use alongside it. The point is narrower: the threshold change is a forcing function to actually open Vendor Box Setup and check every box against the IRS’s own 2026 instructions, line by line, rather than trusting whatever number was last typed in.

Finance and compliance team reviewing a year-end tax compliance checklist and reconciliation chart in a meeting room

That review belongs on the calendar before the fourth quarter closes, not in the scramble between January 1 and the filing deadline. It’s worth having someone outside of accounts payable, ideally whoever owns tax compliance or the external CPA relationship, sign off on the box configuration once it’s set, since the people most likely to hear about the threshold change first are the ones least likely to know which of the seven or eight affected categories it actually touches. If the organization already licenses a third-party 1099 or AP compliance app for TIN verification, bulk processing, or state filing, this is also the moment to confirm that app’s own 2026 configuration has been updated to match, rather than assuming it inherited the change automatically from Business Central.

Routeget has walked several clients through exactly this kind of box-by-box reconciliation ahead of a release change, and the pattern holds regardless of company size: the failure mode is never a controller who ignores a well-publicized rule change. It’s a controller who applies it correctly to the one number that made headlines and never checks the six that didn’t.

#BusinessCentral #1099Thresholds #VendorBoxSetup #IRISFiling #YearEndClose #TaxCompliance