Sales Opportunity Agent Risk Criteria: A Configuration Guide

Sales professional reviewing a CRM opportunity pipeline dashboard with risk indicators on a widescreen monitor

A sales operations director at a mid-size distributor recently asked a reasonable question during a forecast review: why had the Sales Opportunity Agent flagged a deal with a signed letter of intent and an engaged economic buyer as high risk, while waving through a deal where the primary contact had gone silent for three weeks? The answer, once the architect behind the deployment dug into it, was that the agent’s risk model was still running on Microsoft’s default predictive scoring fields: stage velocity, close date slippage, historical win rate by deal size. None of those fields knew that this particular buyer’s procurement team always goes quiet right before signature, or that a champion’s sudden silence after a reorg announcement is the real warning sign in this account base. That gap between what a generic model measures and what an experienced seller actually watches for is precisely what Microsoft’s August 30, 2026 update to Sales Opportunity Agent risk criteria was built to close, and it changes what a technical rollout of this agent actually involves.

Until that update, configuring risk assessment in the agent meant choosing which existing Dynamics 365 fields fed the predictive opportunity scoring model and adjusting a handful of thresholds. Useful, but rigid. Now admins can add a custom risk criterion by describing it in plain language, and the agent layers that instruction on top of its default scoring rather than replacing it. For a solution architect or D365 CE technical consultant planning a rollout, that single change reshapes several downstream decisions: how selection criteria should be scoped, how many agent instances to run, and how much validation work happens before anyone trusts the output.

Sales professional reviewing a CRM opportunity pipeline dashboard with risk indicators on a widescreen monitor

What the Sales Opportunity Agent Risk Criteria Actually Do

The agent’s baseline risk assessment draws on the predictive opportunity scoring machine learning model already present in Dynamics 365 Sales. If that model isn’t configured in your environment, the agent triggers its setup automatically the first time it runs, which is worth knowing up front since it introduces a delay that has nothing to do with your own configuration work. On top of that baseline, the risk configuration section (found under Guidance in the agent’s settings page) now exposes an “Add a custom risk” option. Rather than mapping a field to a threshold, you write a description of the business condition you want flagged, and the agent interprets it against the data it has access to.

This is a meaningful departure from how most Dynamics 365 configuration has historically worked, where a business rule or classic workflow condition had to be expressed as an explicit field comparison. A natural-language risk criterion is closer to writing a prompt than writing a rule, which means two architects describing the same business concern could produce criteria that behave slightly differently depending on wording. That is not a flaw so much as a tradeoff: you gain the ability to capture tacit sales knowledge that was never going to get modeled as a formal Dataverse field, at the cost of the deterministic testability you’d expect from a traditional business rule.

Selection Criteria Come First, and They Are Easy to Get Wrong

Before any risk criterion runs, selection criteria decide which opportunities the agent even looks at. This is configured as a named segment (for example, “Enterprise renewals”) with filter conditions such as rating, estimated revenue, and status, plus an optional look-back period for including opportunities created before the agent was activated. Skip the look-back setting and the agent only considers opportunities created after activation, which catches teams off guard when historical pipeline doesn’t show up in the first few days.

The common mistake here is scoping selection criteria too broadly, on the theory that wider coverage means more value. In practice, loose criteria just mean the agent spends its processing cycles researching deals that were never going to close, competing for the same shared capacity pool as the opportunities you actually care about. A tighter starting point, something like status equals open, status reason equals in progress, and a revenue floor that reflects what “worth researching” means for your sales org, produces better signal and leaves headroom if you later add more segments.

It also helps to understand how the agent prioritizes work once multiple opportunities qualify, since this determines what gets attention first when capacity is constrained. The agent scores queued opportunities using several factors in order: estimated revenue, estimated close date, how recently the opportunity was researched, recent email activity, predictive win-rate score (lower scores get prioritized, since they need more attention), and whether a seller manually requested a refresh. That ordering matters operationally. A high-value deal with a distant close date will generally get processed before a smaller deal closing sooner, so if your sales leadership expects near-term renewals to surface first, you may need a separate agent instance scoped specifically to that segment rather than relying on the shared queue to sort it out.

Writing a Risk Criterion That Actually Earns Its Place

The temptation with natural-language configuration is to restate what the default model already covers, just in different words. That adds noise without adding insight. A custom risk criterion is worth configuring when it encodes something a seller already watches for informally but that no existing field captures well. A few examples that hold up in practice: flagging an opportunity when the primary contact’s job title has changed within the last 30 days, since a champion move is a known risk signal that stage and close-date fields won’t surface; flagging deals in a late stage with no email activity logged in the past two weeks, which tends to catch stalled deals before they slip a quarter; or flagging opportunities where a competitor’s name appears in recent email or meeting notes captured by the agent’s research, which surfaces competitive displacement risk earlier than a rep might think to log it manually.

Close-up of a laptop screen showing an abstract sales pipeline funnel visualization with risk-flag markers on deal nodes

Because these criteria are interpreted rather than evaluated against a strict rule, validate them the same way you’d validate any new logic before trusting it at scale. Use the Preview option in the selection criteria screen to check a representative sample, but treat that preview as directional rather than exhaustive, and cross-check with Advanced Find or a saved view before assuming the criterion behaves the way you intended. Configuration changes also don’t take effect until you explicitly apply them, and the agent only reprocesses on its configured refresh cadence of three, seven, or fourteen days, so budget a full cycle before concluding a criterion isn’t working.

Multiple Instances, One Shared Capacity Pool

Organizations can run up to ten active agent instances at once, each with its own profile, selection criteria, and knowledge sources, which is the mechanism for applying different risk logic to different parts of the business, say, enterprise deals versus transactional ones, without cramming every condition into a single configuration. The catch is that all instances draw from one shared Copilot Studio knowledge base and one shared capacity pool, so heavier use by one instance can slow research for another. If two instances’ selection criteria overlap, the instance with the earlier start time claims the opportunity, and that ownership sticks for the opportunity’s lifecycle. There’s no warning when criteria overlap, which means the discipline has to come from how you design segments up front rather than from anything the platform will catch for you.

The simplified admin configuration that reached general availability on June 30, 2026 helps here by offering guided setup with sensible defaults and a basic-versus-advanced configuration split, so a first instance can go live quickly and pick up custom risk criteria and finer-grained settings later. That’s a genuine improvement for getting started, but it doesn’t remove the need to plan selection criteria deliberately before adding a second or third instance, since the underlying shared-capacity constraints don’t change.

Getting Useful Signal Out of the Rollout

The August GA of custom risk criteria removes a real excuse that architects have had for a while: that the agent’s risk model didn’t understand the specific patterns of a given sales motion. It now can, provided someone takes the time to write criteria that reflect what sales leadership actually raises in forecast calls rather than restating stage and close date in prose. The work that remains is the same discipline any configuration project needs: scope selection criteria narrowly, verify with independent tools rather than trusting the preview alone, and treat a natural-language rule with the same scrutiny you’d give a workflow condition, because it is making decisions about what gets a seller’s attention.

Routeget Technologies has walked a handful of clients through standing up their first Sales Opportunity Agent instances this year, and the pattern that works best is starting with one tightly scoped segment, letting it run a few refresh cycles, and only then drafting custom risk criteria based on what actually surprised the sales team about the default output. That sequencing avoids the common failure mode of over-engineering risk logic before anyone has seen how the baseline model behaves against real pipeline.

#SalesOpportunityAgent #Dynamics365Sales #CRMConfiguration #OpportunityManagement #SalesAIAgents #CustomerEngagement

Business Central’s Outlook Integration Deadline Is October 1, 2026

IT professional reviewing an email and calendar dashboard, representing Business Central Outlook integration

An IT Director at a distribution company we work with found out about this deadline the way most people do: from a support ticket, not a Microsoft email. A sales rep’s Outlook add-in stopped letting her attach a quote from Business Central mid-thread, and the contact she’d synced from BC to Outlook six months ago had quietly vanished from the folder it used to sit in. Nothing had changed on her machine. What had changed was that her company’s Business Central environment was still two release waves behind, and Microsoft had already started tightening the plumbing underneath a feature nobody in IT had flagged as fragile.

That plumbing is Exchange Web Services, the aging protocol Outlook add-ins and contact sync in Business Central have leaned on for over a decade. Microsoft is retiring it, and the resulting Outlook integration deadline that Business Central’s own product team has set is considerably firmer than the platform-wide retirement schedule most IT leaders have heard about. If your organization runs Business Central and anyone in sales, purchasing, or accounting touches customer or vendor contacts through Outlook, this is worth twenty minutes of your attention before the end of the month.

IT professional reviewing an email and calendar dashboard, representing Business Central Outlook integration

What’s Behind the Outlook Integration Deadline

Exchange Web Services, usually shortened to EWS, is the API that has quietly connected Outlook to a long list of Microsoft and third-party applications since the mid-2000s. Microsoft first announced its deprecation back in 2018, but the timeline accelerated meaningfully after the Midnight Blizzard security incident in January 2024 pushed the company toward faster retirement of legacy authentication and API surfaces across Exchange Online. The result, as published by the Exchange engineering team, is a phased shutdown: EWS begins to be disabled globally starting in October 2026, with full disablement across all tenants by April 2027.

Business Central’s product group didn’t wait for that full window to close. Because the older Exchange-based contact synchronization and Outlook add-in deployment in Business Central depend directly on EWS calls, the team attached a much nearer deadline to its own 2026 release wave 1 features: organizations need to be on Business Central version 28.0 or later, and Microsoft has stated plainly that after October 1, 2026, Outlook add-in functionality and contact sync built on the older Exchange connection may stop working in earlier versions. That is a considerably tighter window than the broader EWS retirement calendar, and it is the one that actually matters if you’re planning around this.

What Breaks in Practice, Not in Theory

For a company still running a pre-28.0 version, the practical failure points are the ones your sales and finance teams touch daily rather than anything IT usually monitors. The Outlook add-in that lets a salesperson pull up a customer’s Business Central record, attach a quote, or check open invoice balances without leaving their inbox depends on that Exchange connection to authenticate and retrieve data. The legacy Exchange Sync. Setup page, which many mid-market Business Central customers configured years ago and then never touched again, uses EWS to keep a “Business Central” folder of synced contacts current in each user’s Outlook. Automatically tracking email correspondence against a customer record, a feature accounting and account management teams tend to rely on more than they realize until it’s gone, runs through the same plumbing.

None of this fails with a dramatic outage. It fails quietly: an add-in that used to load now times out, a contact that used to sync now sits stale, an email that used to log itself against a customer record now just sends. That’s a worse failure mode for a CIO to manage than a hard outage, because it doesn’t generate an incident ticket. It generates a slow trickle of user complaints that get diagnosed as one-off glitches for weeks before anyone connects them to a platform deprecation that IT technically knew about.

Abstract visualization of data synchronization flowing between two connected systems on a laptop screen

What Version 28 Actually Replaces It With

Business Central 2026 release wave 1, generally available since April 1, 2026 and auto-enabled for all users on that version, rebuilds this integration on Microsoft Graph instead of EWS. The most visible change is a new “Synchronize with Outlook” action added directly to the Contacts list, which copies selected contacts from Business Central into Microsoft 365, making them usable in both Outlook and Teams. Unlike the old Exchange Sync. Setup configuration, which required a separate admin setup flow and validated an Exchange connection before anything would sync, this action sits where sales and account teams already work, and it supports syncing in either direction if an organization wants contacts created in Outlook to flow back into Business Central.

The other change worth flagging to your security and IT operations teams directly is that Outlook add-in installation now requires a one-time additional setup step to verify the account, a deliberate friction point Microsoft added for account protection reasons rather than a bug. If your organization uses centralized deployment to push the Business Central add-in to users automatically rather than relying on individual installs, that deployment process still works, but the added verification step means it is worth testing the rollout against a pilot group rather than assuming a push that worked in 2025 will behave identically in 2026.

Who Is Actually at Risk

If your Business Central environment is a standard SaaS deployment on Microsoft’s evergreen update cadence, there’s a reasonable chance you’re already on version 28.0 or close to it, since Microsoft pushes two release waves a year to every SaaS tenant on a schedule customers don’t fully control. The organizations that should be checking their version today rather than assuming they’re covered fall into a narrower but not small group: companies running Business Central on-premises, where upgrades are a deliberate IT project rather than an automatic platform event; companies that migrated from Dynamics GP, NAV, or SL in the last two years and may still be running an early post-migration version they haven’t touched since go-live; and any organization that has deliberately delayed a release wave update because of a customization or third-party integration compatibility concern, which is common enough in manufacturing and distribution environments with heavily extended BC implementations.

Checking your version takes a few minutes: in Business Central, the Help and Support page shows the current version and build number directly, and any IT Director who can’t answer “what release wave are we on” from memory should treat that itself as a minor governance gap worth closing regardless of this specific deadline.

What to Do Before October 1

The organizations that will sail through this deadline without incident are the ones treating it as a two-part check rather than a single upgrade task. The first part is confirming the Business Central version itself, since anything at 28.0 or later already has the Graph-based integration and doesn’t need to do anything further beyond being aware the old Exchange Sync. Setup pages are being phased out and shouldn’t be reconfigured going forward. The second part, and the one that gets missed, is validating that Outlook add-in deployment and any automated email-tracking workflows actually work end to end after an upgrade, not just that the version number changed. An upgrade that technically completes but leaves the add-in’s new security verification step unaddressed for most users produces the same quiet failure pattern as not upgrading at all, just with a shorter fuse. For any organization using EWS-dependent integrations beyond Business Central itself, Microsoft’s own EWS Usage Reports in the Microsoft 365 admin center are worth a look this month, since Business Central is rarely the only application in a tenant still calling that API.

None of this requires a large project. It requires someone in IT confirming a version number, someone in sales or finance confirming the add-in still authenticates cleanly, and roughly three weeks of runway that is shrinking by the day. Routeget Technologies has walked several clients through exactly this check in the past month, and in every case the fix was smaller than the anxiety the deadline initially produced, provided someone looked at it before October 1 rather than after.

#BusinessCentral #OutlookIntegration #ExchangeWebServices #ERPGovernance #Microsoft365Integration #DynamicsMigration

Dynamics 365’s Tax Data Migration Tool: What Actually Gets Automated

Enterprise IT consultant reviewing tax configuration data on a monitor, representing Dynamics 365 tax data migration review

A solution architect I’ll call by his actual role, not his name, spent three weeks last spring rebuilding tax configuration for a distributor operating across six US states and two Canadian provinces. The client had outgrown the standard sales tax engine years earlier but never had a project sponsor willing to fund the rework. Every tax code, every group, every item tax group had to be re-created by hand in the newer Tax Calculation service, cross-checked against the original ledger parameters, and validated transaction by transaction. It was the kind of work nobody budgets enough time for, because on paper it looks like data entry, and it is exactly the work Microsoft’s new Tax Data Migration capability is now trying to automate.

That is the exact problem Microsoft is now trying to solve with a preview capability inside Globalization Studio called Tax Data Migration. Rather than asking implementers to rebuild tax master data from scratch, the tool reads a legal entity’s existing standard sales tax setup and generates a working Tax Calculation feature version automatically. It will not replace the judgment a migration still requires, but it does remove a meaningful share of the mechanical rebuilding that used to eat the first few weeks of every one of these projects.

What Tax Data Migration actually converts

The migration reads four categories of standard sales tax master data and maps each into its Tax Calculation equivalent. Sales tax codes become tax codes. Sales tax groups become tax groups. Item sales tax groups become item tax groups. And critically, the general ledger parameters that used to control cash discount and cash discount timing behavior get converted into tax jurisdiction parameters, since Tax Calculation manages that logic at the jurisdiction level rather than the ledger level.

The origin field on each tax code also gets translated rather than copied verbatim. A tax code set to calculate as a percentage of the gross amount becomes “By Gross Amount” in the new model; percentage of margin becomes “By Margin”; amount per unit becomes “By Quantity,” and so on through the six origin types the legacy engine supports. None of this is exposed as a simple lookup table in the product; it is worth documenting for your own project file before you run the migration, because a few of the mappings (particularly “percentage of sales tax” becoming “tax on tax”) are not intuitive if you have not seen the conversion logic before.

Abstract visualization of tax data migrating from one table structure to another in Dynamics 365 Finance

Where the automation gets genuinely clever, and where it gets messy

The part of this feature that will actually save implementation time is variant handling. In real tax configurations, the same tax code frequently shows up in multiple sales tax groups with different behavior attached, one group where it is marked exempt, another where use tax applies. The standard engine tolerates this because the group, not the code, carries the override. Tax Calculation does not work that way, so the migration tool automatically splits a conflicting code into variants: the original code keeps its name, and each subsequent variant gets a numeric suffix appended.

This is also where technical teams need to slow down before trusting the output. The suffix assignment order is explicitly documented as nondeterministic, meaning you cannot predict in advance whether a given tax group ends up with the base code or the _1 variant, and if the original code name is already at Tax Calculation’s ten-character limit, the tool truncates the base name to make room for the suffix. A code your team recognizes on sight can come out the other side looking different enough that a quick visual check will not catch a misassignment. Budget time to open every variant and confirm which tax group it landed in rather than assuming the naming is self-explanatory.

There is a harder stop worth planning around too. If the combined character length of the tax codes attached to a single tax group, or a single item tax group, exceeds 1,000 characters, the migration cancels outright with an error rather than producing a partial result. For a tax group used across many countries or with dozens of narrow tax codes attached, this is not a hypothetical edge case; it is the kind of limit that shows up on the first attempt for exactly the complex, multi-jurisdiction entities where the automation would otherwise save the most time. If you hit it, the fix is manual: trim the tax group before running the migration again, which somewhat defeats the point of automating the exercise for that entity.

The cash discount conflict nobody should skip

One behavior deserves specific attention because it fails silently in the sense that matters: the process still completes successfully even when it can’t fully reconcile a setting. If a tax group’s cash discount treatment differs from the general ledger default, the tool completes the migration and simply throws a warning naming the affected groups, leaving it to the implementer to go build the correct tax jurisdiction rule by hand afterward. It is easy to read a green completion status, skim past a warning banner, and move on to validation testing, especially on a project where the migration ran late in a sprint. Treat any cash discount warning as a required follow-up task, not an FYI, and reference Microsoft’s tax jurisdiction cash discount setup documentation directly rather than guessing at the intended rule from the original ledger parameter alone.

Scope limits that shape how you plan the work

Three constraints matter more for project planning than for the mechanics of any single run. First, the migration operates on one legal entity at a time, scoped to whichever entity is currently selected, so a multi-entity F&O implementation still needs a migration pass per entity rather than a single global conversion. Second, there is no incremental sync: if tax master data changes after you generate a feature version, those changes are not reflected automatically, and picking them up means creating a new version or rerunning the migration from the current state rather than patching the existing one. That makes sequencing important. Run the migration once your legacy tax setup is genuinely stable, not while a parallel project is still adjusting sales tax groups. Third, Brazil and India are explicitly excluded from the feature, which will matter for any global rollout that includes those entities; plan on manual configuration there regardless of how well the automation performs elsewhere.

Where this leaves an implementation plan

None of this changes the fundamental decision of whether to move to Tax Calculation, and it should not be read as a shortcut around understanding how applicability matrices, registration number rules, and jurisdiction-level parameters actually work in the target state. What it does change is where a project’s early hours go. Instead of spending the first several weeks re-keying tax codes and groups that already exist somewhere in the standard engine, a team can generate a starting configuration in an afternoon and spend the time it saved on the work that actually requires expertise: validating applicability logic, building jurisdiction rules for the edge cases the tool flags, and testing real transactions against the converted setup before it goes anywhere near production. The feature is still in preview with no announced general availability date, and Microsoft’s own documentation is explicit that preview functionality isn’t intended for production use, so the responsible move right now is to run it in a sandbox, learn where your specific tax configuration triggers variants or warnings, and have that homework done before GA arrives rather than starting from zero once it does.

We’ve run this migration path on sandbox copies of a few clients’ production tax configurations at Routeget specifically to build a checklist of the mapping quirks and character-limit failures worth watching for, and the pattern holds across fairly different configurations: the tool gets you most of the way to a working feature version, and the remaining ten percent is exactly the part that requires someone who understands both the old engine and the new one.

#TaxDataMigration #TaxCalculationService #GlobalizationStudio #DynamicsFinanceOps #ERPTaxCompliance #FinanceTransformation

Standard vs Custom Dataverse Tables: The Schema Decision That Compounds

Solution architect reviewing an entity-relationship diagram of Dataverse tables on a wall-mounted monitor in a modern office

A solution architect reviewing a Dataverse environment for a mid-market industrial services client recently found three separate custom tables, each carrying a different prefix from three different implementation phases, all describing the same thing: a physical site where equipment lived. One had been built by an internal power user modeling “Locations.” Another arrived bundled with an asset management add-on that already shipped a standard table for exactly this purpose. A third was created eighteen months later by a consulting partner who never checked whether either of the first two existed. None of the three synced with each other. Field technicians updated one, finance reported from another, and a Copilot Studio agent built the following year queried a fourth table that didn’t even have the data anyone actually needed.

This is not an unusual story. It is close to the default outcome when the standard vs custom Dataverse tables decision gets made under sprint pressure by whoever is in the room that week, without anyone asking a simple question first: does a standard table already do this?

Solution architect reviewing an entity-relationship diagram of Dataverse tables on a wall-mounted monitor in a modern office

Why the standard vs custom Dataverse tables decision is easy to get wrong

Dataverse ships with hundreds of standard tables (Account, Contact, and Case are the obvious ones, but plenty of others arrive silently through installed solutions like Asset Management, Project Operations, or Customer Service) built on the Common Data Model, Microsoft’s shared schema for representing common business concepts consistently across apps. These tables carry no prefix. A custom table, by contrast, always carries one, whether that’s a publisher prefix like cra_ or a legacy new_. That naming convention is the fastest way to tell which category a table belongs to, but it only helps if someone actually looks.

The reason teams skip that check is rarely laziness. It is usually that building a new custom table feels faster and safer than researching whether a standard one already covers the need, especially early in a project when the backlog is long and the standard table’s full column list and relationship graph aren’t obvious from a quick glance at the maker portal. The problem is that this shortcut doesn’t cost you anything visible in week one. It costs you eighteen months later, when a Fabric Link migration, a cross-application integration between Finance and Operations and Customer Engagement, or a Copilot Studio agent expects the canonical CDM entity and instead finds three partial, disconnected substitutes.

What actually distinguishes standard, custom, and virtual tables

The decision isn’t really binary. There are three categories worth holding in mind, and each answers a different question about who owns the data’s lifecycle.

Standard tables are the right choice when Dataverse itself is the authoritative source for that data and the concept maps to something Microsoft has already modeled: a contact, an account, a case, a work order. Even when a standard table doesn’t fit perfectly out of the box, most standard tables are customizable, meaning you can add columns, choices, and relationships to extend them without forking the concept into a parallel structure. Extending a standard table keeps every existing app, flow, security role, and future Copilot agent that already understands that entity working correctly, because they’re still querying the same canonical table, just with a few more fields on it.

Custom tables earn their place when the data genuinely doesn’t correspond to anything in the Common Data Model and is specific to how your organization actually operates: an internal certification tracking table, a custom approval matrix, something with no reasonable standard analog. The mistake isn’t creating custom tables. It’s creating one before checking whether the concept already has a home.

Virtual tables solve a different problem entirely: they matter when an external system, not Dataverse, remains the true owner of a record’s lifecycle. A virtual table stores only metadata in Dataverse and queries the external source (an ERP system, a warehouse management platform, a legacy line-of-business database) live, through a data provider. This matters more than it sounds like it should, because the alternative, replicating that external data into a standard or custom Dataverse table on a schedule, introduces a staleness window that can turn into a real operational failure. If a warehouse system shows zero units on hand but the last Dataverse sync ran six hours ago and still shows ten, a sales rep can quote stock that doesn’t exist, and the order gets canceled after the customer has already been told it’s on the way. Virtual tables avoid that gap by not caching the data at all, at the cost of depending entirely on the external system’s availability and performance for every query.

Close-up of a laptop screen showing an abstract database table relationship diagram on a desk

The decision doesn’t stop at the table level

Getting the table category right is only the first layer of the structure question. Once you’ve decided a standard table is the right home for a concept, the choice columns and relationships you add to extend it are where a lot of the same discipline quietly gets abandoned. A choice column added to the standard Case table to capture an industry-specific status, for instance, is a reasonable extension. A parallel custom table built solely to hold a lookup list of those same statuses, connected back to Case through a one-to-many relationship that duplicates logic the choice column could have handled directly, is the same mistake as the duplicate-table problem, just one level down. Relationships matter here too: a standard table’s existing relationships to Account, Contact, or Activity records represent years of Microsoft’s own modeling work and every prebuilt view, form, and security role built around them. Recreating an equivalent relationship structure on a new custom table means none of that inherited tooling applies, and every new integration has to be taught the relationship from scratch. The pattern to watch for is simple: if you’re building a new table or relationship whose only real justification is that it mirrors something a standard table’s fields or connections already do, that’s usually a sign to extend the standard structure instead of building a parallel one next to it.

Where this decision shows up again at the platform level

Microsoft’s own tooling has started reflecting how much this decision matters beyond a single app. Guided table selection for Dataverse-to-Fabric sync, which reached general availability in March 2026, now lets administrators choose which tables get synced to Microsoft Fabric before any data movement happens, rather than syncing everything by default and cleaning up storage and compute costs after the fact. That capability is far more useful, and far cheaper to operate, when the tables being selected are standard, CDM-aligned entities that Fabric, Copilot, and cross-application processes already expect, instead of a scattered set of custom tables that each need to be individually understood, mapped, and maintained by whoever inherits the environment next.

The same logic applies to Copilot Studio agents built against Dataverse. An agent configured to reason over the standard Account or Case table benefits from every piece of existing metadata, relationship, and security context Microsoft has already built around that entity. An agent pointed at a custom table invented to avoid learning the standard schema starts from nothing, and every future integration against that data has to rediscover the same ground.

A practical check before the next table gets created

Before greenlighting a new custom table, it’s worth spending twenty minutes on three checks that would have caught the industrial services example above. First, search the environment for a standard table whose name or description plausibly matches the concept, since standard tables installed by add-on solutions often don’t surface in a maker’s mental model of “what’s already in this environment” the way tables they built themselves do. Second, if a standard table exists but seems incomplete, check whether it’s marked customizable before assuming it needs to be replaced rather than extended, since most standard tables accept new columns, choices, and relationships without any loss of the functionality that came with them. Third, before replicating any externally-owned data into Dataverse on a schedule, ask explicitly whether the business can tolerate a sync delay, because if the answer is no, a virtual table is very likely the more honest architectural choice, even though it takes more setup effort than a straightforward custom table import.

None of this is exciting work, and it rarely shows up as a line item any client asks for by name. But schema decisions are the one architectural choice in a Dataverse implementation that nobody revisits for years, which is exactly why they deserve more scrutiny at the start than they usually get. Routeget Technologies typically includes a standard-table gap analysis as one of the first steps in any new Dataverse engagement, precisely because the cost of fixing a schema mistake grows every quarter it goes unnoticed, while the cost of catching it early is measured in a single afternoon of research.

#DataverseArchitecture #CommonDataModel #PowerPlatformGovernance #DataverseSchema #FabricLink #EnterpriseDataStrategy

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