Power Automate’s Desktop Flow Version Control Reached GA. It Isn’t the Git Workflow You Expected.

Solution architect reviewing a workflow version comparison on a monitor in a modern office

Last quarter, a client’s unattended invoice-processing bot broke in production after a maker “fixed” a selector on a Friday afternoon and republished without telling anyone. There was no way to see what had changed, no way to diff the working version against the broken one, and no way to roll back except by rebuilding the flow from a screenshot someone had taken three weeks earlier. That is not a hypothetical: it is the normal operating condition for most Power Automate desktop flow estates, and it is the exact gap Microsoft’s new desktop flow version control feature was built to close.

Desktop flow version control reached general availability on May 13, 2026, alongside a companion capability, compare flow versions, released the same day. A related feature, test subflows with test suite, followed in June 2026. Together they represent the most significant governance shift Power Automate for desktop has had since unattended runs first shipped, and for solution architects who have spent years explaining to security and change-management teams why their RPA estate has none of the source-control discipline their .NET or Java pipelines take for granted, this is worth understanding in detail, not just filing away as a changelog entry.

What Desktop Flow Version Control Actually Shipped, and What It Isn’t

The instinct when you hear “version control for desktop flows” is to picture Git: branches, merges, pull requests, a commit graph. That is not what Microsoft built, and treating it as a Git replacement will set you up for a bad rollout conversation with your development team. The underlying storage is Dataverse, not a distributed version-control system. Every draft and published version of a desktop flow is stored there in a compressed format, and Microsoft’s documentation is explicit that there is no configurable cap on how many versions accumulate, though versions older than twelve months are automatically purged, with the exception of the latest published version, which is retained indefinitely.

The model itself is linear rather than branching. A maker saves incremental changes as a draft, which has no effect on whatever is currently running in production. When the maker is satisfied, they publish, which creates an official version available for execution from the console or from a triggering cloud flow. Publish is deliberately disabled until the flow contains at least one enabled action, a small guardrail against accidentally shipping an empty shell. Every prior published version remains accessible as a read-only, previously-published entry, and a maker can restore any of those older versions, which pulls it back in as the current draft rather than silently reinstating it as production. That distinction matters operationally: restoring a version is a deliberate, two-step act, not a one-click rollback that could be triggered by accident.

There is no merge conflict resolution because there is no merging. If two makers edit the same flow concurrently, Microsoft’s guidance is essentially to coordinate manually and avoid overlapping edits, which is a meaningfully different discipline than what a development team accustomed to feature branches will expect. If your organization runs a centralized Center of Excellence model where a small number of makers own each flow, this limitation is mostly academic. If you have distributed ownership across multiple business units touching shared subflows, it is a real constraint you need to design around before you tell anyone this “solves” your governance problem.

Compare Flow Versions: What the Diff Actually Shows

The comparison tool is where this feature starts to feel like genuine engineering tooling rather than a glorified undo button. Selecting any two saved versions opens a read-only comparison view, with the designer locked from editing while the comparison window is open, and the most recent version by timestamp used as the reference baseline. The right-hand pane acts as a change filter: clicking an entry highlights the corresponding element directly in the flow canvas, so you are not scrolling through the whole flow trying to spot what moved.

The scope of what gets diffed is broader than a simple action-by-action list. It surfaces added, removed, and renamed subflows; changes to action configuration and parameters; variable type, name, and value changes; updates to UI element selectors, which is precisely the category of change that silently breaks unattended runs most often; and additions or removals of image assets used for image-based automation. For a team that has ever spent an afternoon trying to figure out why a previously stable flow started failing, having selector changes surface explicitly in a diff view is arguably the single most practically useful part of this release, more so than version control’s headline framing suggests.

Abstract illustration of workflow nodes with a version comparison branch and a passed test checkmark

Subflow-Level Testing Closes a Real Gap

Before this release, testing a Power Automate desktop flow meant running the entire parent flow end to end, because there was no supported way to validate a subflow’s logic in isolation. That forced teams into a familiar bad pattern: either skip meaningful pre-deployment testing because a full run is slow and environment-dependent, or build brittle manual test scripts outside the platform entirely. Test subflows with test suite, which reached general availability in June 2026, extends the existing desktop-flow test framework down to the subflow level, using the same behavior-driven-development structure, defined inputs, expected outputs, and assertions, that the parent-flow test suite already used.

This is not glamorous, but it is the piece that actually makes version control operationally useful rather than just a historical record. A version history without a way to verify that a candidate version behaves correctly before you publish it is an audit trail, not a quality gate. With subflow-level tests, a maker can validate the specific piece of logic they changed, independent of the surrounding flow, and get a pass or fail result recorded in the console and designer before that version ever reaches an unattended runtime. Combined with the comparison tool, you now have a workflow that resembles, even if it doesn’t literally replicate, a real pre-merge review: see exactly what changed, run a targeted test against the changed logic, then publish deliberately.

The Caveats That Change Your Rollout Plan

A handful of details in Microsoft’s documentation will change how you deploy this, and skipping them is how a promising governance feature turns into a support ticket. Self-healing, the capability that lets a desktop flow automatically repair a broken UI selector at runtime, is disabled whenever a flow is running from a saved draft rather than a published version. If your team gets in the habit of testing directly against drafts in a production-adjacent environment, understand that you have also quietly turned off a reliability feature you may be depending on elsewhere.

Enabling the feature requires the prvReadcomponentchangesetpayload privilege, which is included by default for the Environment Maker role but must be added explicitly to any custom security role your organization uses for minimum-permission configurations, a step that is easy to miss if your RPA governance model already deviates from Microsoft’s defaults. Import conflicts are another real-world snag: importing a published flow into an environment that already has an unpublished draft throws an error about an unmodified active context with an existing unpublished row, and the fix is to delete the pending draft before the import runs, which has implications for how you structure ALM pipelines that move flows between dev, test, and production environments. Finally, once version control is turned on for an environment, it cannot be turned off, which argues for enabling it first in a genuinely lower, disposable sandbox rather than directly in whatever environment your team currently treats as “dev.”

What This Means for How You Structure RPA Delivery

None of this makes desktop flow governance equivalent to modern application development practice, and it shouldn’t be sold to a client or an internal stakeholder that way. But it does close the two gaps that have made RPA estates genuinely hard to govern at scale: an unauditable history of what changed and when, and no supported way to test a piece of logic before it reaches an unattended machine. Teams that adopt both capabilities together, disciplined draft-and-publish habits paired with subflow tests run before every publish, will get a meaningfully more defensible answer the next time an auditor or a CISO asks how changes to an automation that touches financial or customer data actually get reviewed. Teams that enable version control and stop there, treating it as a rollback insurance policy rather than a discipline, will find it useful during an incident and largely irrelevant the rest of the time.

Routeget Technologies has been building governance frameworks around Power Automate and Power Platform estates for clients moving from pilot-stage RPA into production-scale automation, and the pattern above, comparison-driven review paired with subflow testing before publish, is close to what we now recommend as a baseline practice rather than an aspirational one. The tooling finally supports it; the discipline still has to be built deliberately.

#PowerAutomate #DesktopFlows #RPAGovernance #ALM #ProcessAutomation #EnterpriseAutomation

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

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

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

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

What the Feature Actually Does

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

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

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

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

Why “Real-Time Web Tracking” Needs a Footnote

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

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

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

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

The Business Case Underneath the Feature

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

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

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

What a CIO or CMO Should Actually Evaluate

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

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

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

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

Where This Leaves the Rollout Decision

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

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

#DynamicsCustomerInsights #CustomerDataPlatform #LeadScoring #SalesMarketingAlignment #DigitalTransformation

Business Central Withholding Tax Just Went Standard. The Setup Still Isn’t a Checkbox.

Finance director reviewing an international vendor payment and tax compliance dashboard in a modern office

For years, a Business Central partner fielding a withholding tax requirement from a customer expanding into Brazil, Nigeria, the Philippines, or a dozen other markets had exactly two honest answers: buy a third-party ISV solution built for that specific jurisdiction, or write custom code against the purchasing posting routines and hope the next major version upgrade didn’t break it. Neither answer was cheap, and neither scaled if the same customer later opened operations in a second country with a different withholding regime. That gap is what Microsoft’s new Business Central withholding tax engine is built to close. With the public preview that opened April 1, 2026 and general availability targeted for October 2026, Microsoft has built the calculation logic directly into the standard, non-localized version of the product, available for any country or region where a business needs it.

This matters more than it might sound like on first read. Country-specific withholding tax logic has existed in Business Central for a long time, but only inside the local functionality packs for markets like Italy, India, Australia, and New Zealand, each maintained as its own separate implementation with its own tables and its own quirks. A partner supporting a customer with entities in Italy and Colombia couldn’t reuse the Italian withholding tax setup for the Colombian entity, because the two were never built on shared logic. The new engine changes that by putting a single, configurable withholding tax framework into the base application, meaning any tenant, in any country, can turn it on without waiting for Microsoft (or an ISV) to ship a localization for that specific jurisdiction.

How the Business Central Withholding Tax Engine Works

The mechanics are straightforward at the conceptual level. When you post a purchase invoice or purchase order for a vendor flagged as withholding tax liable, Business Central calculates the applicable withholding tax based on your configuration, withholds that amount from what you’d otherwise pay the vendor, and creates a withholding tax entry for tracking and later settlement. A separate action, Calculate and Post Withholding Tax Settlements, lets you process and remit those withheld amounts to the tax authority for a given period. None of that is conceptually new to anyone who has worked with Italian or Indian withholding tax before. What’s new is that it’s no longer bolted onto a country pack; it lives in General Ledger Setup as a feature you enable directly.

Enabling it is only the first step, and this is where the “just flip a switch” narrative some blog posts have used falls apart under any real implementation pressure. After turning on Enable Withholding Tax in General Ledger Setup, you still need to build out four interconnected setup layers before a single invoice will calculate correctly. First, Withholding Tax Revenue Types, which define the categories of taxable transactions (each with its own code, description, and display sequence) and which later drive statutory reporting and certificate generation. Second, Withholding Tax Business Posting Groups, assigned to the vendors subject to withholding, and Withholding Tax Product Posting Groups, assigned to the items or G/L accounts the tax applies against. Third, a Withholding Tax Posting Setup record that links a specific business posting group to a specific product posting group and defines the actual calculation behavior: the calculation rule (less than, equal to, or another comparison against a threshold), a minimum invoice amount below which no tax is withheld, the withholding percentage itself, and a Realized Withholding Type that determines whether the tax is recognized at invoice posting, at payment posting, or at whichever comes first. Fourth, the G/L account setup for the prepaid and payable withholding tax accounts, plus the balancing account types and numbers Business Central needs to post the offsetting entries correctly.

That Realized Withholding Type field deserves particular attention from anyone implementing this for a jurisdiction they haven’t worked with before, because it isn’t a cosmetic timing preference. Statutory withholding regimes frequently specify exactly when the withholding obligation legally arises, and that moment doesn’t always match Business Central’s default assumptions. A configuration that recognizes withholding tax at invoice posting when the local rule requires recognition at payment will produce entries that reconcile cleanly inside Business Central while being wrong for the actual filing. This is not a gap in the software so much as a reminder that a generalized engine can’t encode every country’s statutory timing rules for you; that judgment call sits with whoever configures the posting setup, and it needs to be validated against actual local tax guidance, not against what feels intuitive from a US or UK accounting background.

Abstract illustration of a digital invoice with a portion of its value being withheld into a separate ledger

The Parts the Documentation Leaves for You to Test

Microsoft’s own documentation for this feature is candid about what it covers and noticeably quiet about several scenarios that any multinational deployment will eventually hit. There’s no published guidance yet on how withholding tax interacts with early payment discounts, where the discount changes the payment amount after the withholding calculation might already have run. There’s nothing specific on multi-currency purchase documents, where the withholding percentage presumably applies to a converted amount, but the conversion timing (invoice date rate versus payment date rate) isn’t spelled out. Prepayment scenarios, where part of the vendor payment happens before the final invoice, aren’t addressed either, and neither is whether a single vendor can carry more than one withholding tax code simultaneously for different transaction types.

None of this means the feature is unfinished in a way that should block evaluation. It means that any partner scoping an implementation should treat those four scenarios (discounts, multi-currency, prepayments, multiple codes per vendor) as required test cases before go-live, not edge cases to handle reactively after a customer complaint. Build a small set of test vendors and test posting groups in a sandbox, run each scenario through to a posted settlement, and compare the resulting entries against what the local tax authority actually expects. That’s a half-day of structured testing that will surface problems far more cheaply than discovering them during a live settlement run in month three.

There’s a second practical wrinkle worth planning around: coexistence with the existing localized versions. A customer running Italian local functionality for their Milan entity and the new standard engine for a newly opened Kenyan entity now has two withholding tax implementations active in the same tenant, built on different tables, with different setup pages, and (presumably, though Microsoft hasn’t published a migration path) no automatic bridge between them. For partners supporting genuinely multinational customers, this is worth raising proactively rather than waiting for someone to ask why the Italy withholding tax report doesn’t include Kenyan vendors.

Why the Timing Matters Right Now

Because the feature is still in public preview as of this writing, with general availability set for October 2026, this is the window where testing and feedback actually shape the shipped product rather than reacting to it after the fact. A conflicting timeline circulated by at least one independent Business Central blog puts general availability as early as June 2026, but Microsoft’s own release plan documentation lists October 2026 as the GA date, which is the figure worth planning around until Microsoft says otherwise. Partners with customers who have been paying for third-party withholding tax add-ons or running custom code against the purchasing module have a real opportunity here: a standard, Microsoft-supported alternative is arriving, and the preview period is the right time to validate it against the specific statutory requirements those customers already comply with, rather than assuming general availability means production-ready for every jurisdiction on day one.

At Routeget, this is the kind of feature we tend to see underestimated at the scoping stage, precisely because “Microsoft now supports withholding tax natively” sounds like it closes a requirement rather than opening a configuration project. The posting groups, the realized timing decision, and the untested edge cases are where the actual implementation effort lives, and getting them wrong doesn’t surface until a settlement run doesn’t match what the tax authority expected.

#DynamicsBusinessCentral #WithholdingTax #FinanceAutomation #TaxCompliance #ERPGovernance #GlobalFinance

Accounts Payable Settlement Priority Is Now On by Default in Dynamics 365 Finance. It Solves a Narrower Problem Than It Sounds.

Finance manager reviewing a vendor payment and cash flow dashboard on office monitors

A controller at a mid-market distributor recently asked her Dynamics 365 partner a reasonable question: now that accounts payable settlement priority is on by default in the 10.0.49 update, does that mean the system will hold back lower-priority vendors during a tight cash week and pay the critical ones first? The honest answer disappointed her. It doesn’t do that, and understanding exactly why is the difference between using this feature correctly and assuming it covers a problem it was never built to solve.

Dynamics 365 Finance 10.0.49 reached general availability for self-update customers in September 2026, with auto-update environments following in October. Buried in the Cash and Bank Management section of the release notes is a single line: “Accounts payable enable settle with priority” is now on by default. For years this capability existed behind a feature flag that most organizations never touched, largely because nobody explained clearly what problem it actually solves. Now that Microsoft has switched it on for everyone, finance teams are encountering it for the first time in production, often without having reviewed what it changes.

What Accounts Payable Settlement Priority Actually Does

Abstract illustration of digital invoices sorted into a prioritized settlement queue

Settlement priority operates at a narrower point in the payables process than most people assume. It has nothing to do with deciding which vendors get selected for a payment run in the first place. That job still belongs to the payment proposal, whether generated manually or through the automated vendor payment proposal process, and both of those continue to select invoices based on due date and cash discount date windows exactly as they did before this update.

What settlement priority governs is what happens after a payment already exists and needs to be applied against a vendor’s open invoices. When a single payment doesn’t fully cover everything outstanding for that vendor, perhaps because of a short remittance, a disputed line held back from the total, or simple rounding, the system has to decide which invoices get settled first and which remain partially or fully open. Before this update, that decision followed either manual selection or a straightforward date-based default. With settlement priority enabled, it instead follows a priority number you assign to the vendor, configured on the Settlement priority tab of the Accounts Payable Parameters page, with the option to extend the same logic into automatic settlement once both the “Prioritize settlement” and “Automatic settlement” parameters are turned on together.

That is a genuinely useful piece of consistency. Large accounts payable teams processing thousands of vendor transactions a month have historically dealt with inconsistent settlement outcomes when a payment fell short of the full balance, sometimes resolved by whichever clerk happened to be settling the transaction that day. Replacing that variability with a defined, auditable order is a real improvement, and it is the kind of quiet process-integrity fix that rarely gets attention until an auditor asks why two similar short-payment scenarios were resolved two different ways six months apart.

The Gap Between What CFOs Expect and What Ships

Where the confusion starts is in how naturally this feature’s name suggests something bigger. “Settle with priority” sounds like it should mean strategic vendor prioritization during cash-constrained periods, and that is precisely the capability many finance leaders have wanted from their ERP for years. If working capital tightens ahead of a large tax remittance or a seasonal inventory build, the instinct is to want the system to automatically defer discretionary vendors and protect payments to single-source suppliers or anyone with contractual penalty clauses for late payment.

That is not what happens here, and it’s worth being direct about the practical consequence. If your organization relies on the automated vendor payment proposal process to generate weekly or monthly payment runs, turning on settlement priority changes nothing about which invoices get proposed for payment. The proposal still pulls invoices based on due date adjustments and minimum payment date criteria defined in the process automation setup, with no awareness of cash position, vendor criticality, or the priority numbers you may have just configured. A vendor ranked as low priority in your new settlement configuration will still be selected for payment on schedule if its invoice falls inside the proposal’s date window, because priority only comes into play once a payment already exists and needs to be matched against that vendor’s open balance.

For genuine cash-position-driven prioritization, the lever still sits where it always has: in how proposals are filtered before generation, in manual holds placed on specific vendor accounts, or in a dedicated treasury or AP automation layer sitting alongside Dynamics 365 that can factor in real-time cash forecasts. Settlement priority is a settlement-application control, not a payables strategy tool, and treating it as the latter risks a finance team believing they have protection they don’t actually have during the next liquidity crunch.

What to Check Before This Silently Changes Behavior

Because this shipped as an on-by-default change rather than an opt-in feature, the practical risk isn’t that it’s dangerous. It’s that it’s invisible until someone notices settlement behavior has shifted. A few things are worth confirming in any environment that has moved to 10.0.49 or will auto-update in October.

First, check whether priority numbers have ever been assigned to vendors in your instance. If settlement priority is now active but no one has configured priority values, the system will apply whatever default ordering exists, and finance staff should know what that default actually is rather than assume it matches prior manual practice. Second, review whether “Automatic settlement” is also enabled alongside “Prioritize settlement,” since that combination extends priority-based logic into unattended settlement runs rather than only manual ones, which raises the stakes on getting the configuration right before it processes a batch overnight. Third, walk through a short-payment scenario in a test environment with a vendor that has multiple open invoices, to see firsthand which invoice gets settled and which remains open, rather than relying on documentation alone to predict the outcome.

Where This Fits in a Broader Payables Strategy

None of this diminishes the value of the underlying capability. Consistent, auditable settlement behavior matters more as transaction volumes grow and as more of the payables cycle runs through automation with less manual review at each step. Organizations running multi-entity or shared-service AP operations, where the same clerk may be settling transactions across dozens of legal entities with different vendor relationships, stand to benefit the most from replacing ad hoc judgment calls with a defined priority scheme.

The mistake to avoid is treating this release note as evidence that Dynamics 365 now handles strategic vendor prioritization end to end. It handles one well-defined piece of a much larger payables process, and the other pieces, cash forecasting, proposal filtering, vendor criticality scoring, still need to be designed deliberately, whether through native configuration, process automation rules, or a third-party AP platform. Firms that have implemented and tuned payables processes across enough Dynamics 365 environments tend to see this pattern repeat with almost every feature flip: the capability itself is sound, but the assumption about its scope is usually larger than what shipped. Reading the fine print before the next auto-update cycle is a cheap way to avoid finding out the gap the hard way, during the week cash is actually tight.

#DynamicsFinanceOps #AccountsPayable #VendorPaymentPriority #CashManagement #WorkingCapital #FinanceAutomation

Dataverse’s Recycle Bin Restore Reached GA. Your Business Logic Isn’t Included.

Solution architect reviewing a data recovery and system administration dashboard on a large monitor in a modern office

A bulk delete job runs at 2 a.m. against the wrong view filter. By the time anyone in operations notices, eleven thousand account records are gone, and the only recovery plan anyone can point to is a nightly export sitting in a storage account nobody has tested restoring from in two years. That scenario is why Microsoft spent nearly two years moving deleted record recovery in Dataverse from public preview to general availability in late April 2026. For solution architects and Dynamics 365 technical teams, a native Dataverse recycle bin restore capability closes a gap that has existed since the platform’s earliest days: there was never a supported, in-product way to undo a delete. Now there is one. The problem is that plenty of teams will configure it, assume it behaves like the Recycle Bin on a Windows desktop, and discover the gap between what it restores and what they actually needed restored only during a real incident.

The feature’s actual behavior is narrower and more procedural than its name suggests, and the places where it falls short map directly onto the customizations most F&O, Business Central, and Customer Engagement implementations already carry.

Solution architect reviewing a data recovery and system administration dashboard on a large monitor in a modern office

What the Dataverse Recycle Bin Restore Actually Covers

The capability itself is straightforward to enable. From the Power Platform admin center, under an environment’s Settings, Product, Features, there is a “Keep deleted Dataverse records” toggle with a retention window configurable from one to thirty days. Turn it on, and Dataverse begins tracking rows that get deleted so a System Administrator can view them under Data management, Deleted Records, and issue a Restore request against the ones worth recovering. The setting lives at the environment level, not the tenant level, so a sandbox and its corresponding production environment can carry entirely different retention windows, which matters if you’re testing destructive changes in a lower environment that doesn’t need the same thirty-day buffer production does.

The detail that trips up almost every team on first contact is that the feature is not retroactive. Only rows deleted after the setting is enabled and has finished propagating, which the documentation notes can take up to thirty minutes, become recoverable. A record deleted an hour before someone flips the toggle is gone exactly as it always was. If you’re reading this and haven’t enabled retention on a production environment yet, that thirty-minute propagation window is the argument for doing it now rather than after the incident that makes you wish you had.

Restoration happens through the Restore message, available in the SDK for both early-bound and late-bound entities, or as an action call through the Web API. The request takes a full target record rather than a bare reference, so you can override specific column values as part of the restore rather than being forced to bring back an exact snapshot. Deleted rows are also queryable directly: a FetchXml query with datasource='bin', or a QueryExpression with its DataSource property set the same way, returns rows sitting in the bin rather than the live table, which is enough to build a lightweight internal tool that surfaces what’s recoverable without routing every check through the admin UI.

The Tables That Never Show Up in the Bin

The exclusion list is where the feature’s real limits show up, and it is long enough that assuming universal coverage is a mistake worth catching before an incident rather than during one. Virtual tables are excluded entirely: if a record surfaced from an external system through a virtual table disappears, there was never anything in the bin to restore, since that row was never really “deleted” from Dataverse’s perspective so much as it stopped resolving. Elastic tables, increasingly common for high-volume telemetry, IoT-style logging, or activity history where standard table row limits become a constraint, are excluded as well. So are solution component tables, and so is any table that has grown past six hundred attributes, a ceiling that heavily customized standard entities in mature Dynamics 365 implementations can approach faster than teams expect.

Beyond those structural exclusions, Microsoft maintains a list of roughly two hundred and fifty system tables that don’t support deleted-record retention regardless of configuration: async operation records, background operation records, bulk delete failure logs, Power Automate flow run and flow log tables, solution and solution component tables, plugin assembly tables, and the full family of msdyn_ and mspp_ prefixed tables tied to first-party Dynamics 365 apps and Power Pages. None of that is arbitrary; those tables tend to be high-volume, system-managed, or tightly coupled to processes where a stale restored row could reintroduce more problems than it solves. But it does mean that if your disaster recovery narrative for a Power Pages portal assumes the recycle bin has you covered, it’s worth checking the actual exclusion list against your table inventory before that assumption ends up in a postmortem.

Abstract illustration of glowing data records being restored from an archive bin into an active data grid

Cascade Deletes Restore in Order. Custom Logic Doesn’t.

Where this feature gets genuinely interesting for anyone who has built out relationship cascading behavior is how it treats dependent records. Rows removed because of a configured cascade delete relationship, the kind set up through standard relationship behavior rather than custom code, are restorable, but not independently. You have to restore the parent record first; attempting to restore a cascaded child before its parent throws RefCannotBeRestoredRecycleBinNotFound, and the platform expects you to work back up the dependency chain in the correct order rather than picking records to restore arbitrarily.

Custom logic is a different story, and it’s the part of the feature architects need to internalize before promising anyone a one-click recovery story. If a plugin or a Power Automate flow deletes related records as a side effect of deleting the primary record, none of that custom-triggered deletion is automatically reversed by a Restore call. The recycle bin captures what Dataverse’s own relationship engine did, not what your business logic did on top of it. That means any implementation with plugins that clean up child records, cancel related cases, or cascade status changes on delete needs a mirrored restore path: a plugin registered against the Restore message, in the PostOperation stage specifically since the restored record isn’t available yet during PreOperation, that re-creates or re-links whatever the delete-time logic tore down. Skip this step and a team restores the parent record, then discovers days later that none of the related activity history, case associations, or downstream integration records came back with it, because nothing ever told them to.

A handful of other failure modes are worth knowing before you hit them live. Restoring a record whose ID has since been reused by a new record throws DuplicateExceptionRestoreRecycleBin, since Dataverse preserves the original primary key on restore rather than generating a new one. If a deleted record referenced an option set value that has since been removed from the choice definition, the restore fails with PicklistValueOutOfRangeRecycleBin. Both are recoverable situations, but only if whoever is running the recovery understands what the error is actually telling them instead of treating it as a generic restore failure and giving up.

Building the Restore Path for Real Incidents

None of this argues against enabling the feature. It argues for treating it as infrastructure that needs its own runbook rather than a switch you flip and forget. A reasonable rollout enables retention on every production environment now, sets the window to match your actual incident response SLA rather than defaulting to the maximum thirty days without weighing the storage tradeoff, and documents exactly which tables in your specific implementation fall outside the coverage: your virtual tables, any elastic tables you’ve adopted, and anything near the six-hundred-attribute ceiling.

The more valuable investment is building and testing the restore path before you need it: registering the mirrored Restore-stage plugin logic anywhere delete-time custom logic exists, confirming cascade restore order against your actual relationship map rather than assuming it will be intuitive mid-incident, and running a deliberate test delete-and-restore cycle in a sandbox so the first time anyone executes this procedure isn’t during a live outage. It’s also worth being explicit internally that this is record-level recovery, not a replacement for environment-level point-in-time restore, which remains the right tool for a broader corruption event or a bad deployment rather than a scoped accidental deletion. Teams that conflate the two end up with a false sense of coverage in exactly the scenario where they can least afford one.

The recycle bin is a genuinely useful addition, and it’s the kind of foundational reliability work that doesn’t generate much attention next to agent and Copilot announcements but matters more day to day for the teams operating these environments. Routeget has walked several clients through exactly this kind of gap analysis between what a new platform capability claims to cover and what a specific implementation’s customizations actually need, and the pattern holds here too: the feature is only as good as the runbook built around it. Treat this GA date as the trigger to write that runbook, not as the moment the problem quietly solves itself.

#Dataverse #DataverseRecycleBin #DataRecovery #PowerPlatformGovernance #ITDisasterRecovery #CloudArchitecture

Power BI Semantic Model Refresh Just Got Granular. Your Dynamics 365 Reports Still Refresh Everything.

A solution architect reviews a data refresh and capacity monitoring dashboard on a large screen at night

A Fabric capacity dashboard turning red at two in the morning is one of the more specific kinds of dread in Dynamics 365 reporting work. Somewhere in the tenant, a scheduled job kicked off a full refresh of a forty-table semantic model built over Dataverse-linked Finance and Operations data, and now every other overnight pipeline is queued behind it. The general ledger fact table alone might carry a decade of posted transactions. None of that history changed since yesterday. It gets reloaded anyway, because until recently, “refresh” in Power BI meant one thing: everything, from scratch, every time.

That default is finally negotiable. Power BI’s August 2026 update made granular semantic model refresh controls generally available in both Desktop and the service, giving report owners a real choice between refreshing schema, refreshing data, or refreshing both, down to the level of an individual table. For anyone maintaining Power BI models over Dynamics 365 F&O, Business Central, or Dataverse data more broadly, this is the kind of change that should prompt an actual architecture review rather than a shrug and a changelog skim.

What changed, specifically

The expanded Refresh control in Power BI Desktop and the service now exposes three distinct operations instead of one. Refresh Schema and Data is the familiar default: Power BI checks the source for structural changes, applies them, and then reloads data. Sync Schema Only updates the model’s structure, picking up new or renamed columns and data type changes, without pulling fresh rows. Refresh Data Only does the opposite: it reloads current values while deliberately ignoring any structural drift at the source, which matters more than it sounds like it should when a source system adds a column you have no interest in modeling yet.

Critically, this granularity now applies at the table level through the UI itself, not just through a REST call. Select a table in the Data pane, and you can choose to refresh its schema, its data, or both, independently of what happens to the rest of the model. Under the hood, this builds on the Enhanced Refresh API’s objects parameter, which has supported table- and partition-level targeting in JSON refresh requests for several years. What is new is that the capability is no longer something you had to script or automate through Power Automate to get; it is a first-class option in the interface most report authors actually use.

The timing lines up with Direct Lake’s move to general availability for OneLake semantic models in March 2026. Direct Lake models query OneLake data at query time instead of importing it into a separate in-memory copy, which changes what “refresh” even needs to accomplish. A schema-only sync is explicitly called out as the more sensible operation for many Direct Lake scenarios, since the underlying data is already current in OneLake and what actually needs updating is the model’s awareness of structural changes upstream.

Why Dynamics 365 semantic model refresh costs add up fast

Generic BI advice treats all semantic models as roughly interchangeable, but Dynamics 365 F&O and Business Central models have a particular shape that makes blanket full refreshes disproportionately expensive. A handful of tables, typically the ones behind AP aging, open sales orders, or current inventory positions, change constantly and need frequent, current data. Most of the rest of the model, historical GL transactions, closed projects, prior fiscal years, is functionally read-only from one day to the next. When Fabric Link or the older entity-store approach lands both categories in the same semantic model and a nightly job refreshes the whole thing on one schedule, the model pays the full cost of reprocessing static history every single time it wants fresh numbers for the tables that actually moved.

That cost shows up in two places that matter to whoever owns the Fabric capacity bill. Wall-clock refresh duration extends as historical fact tables grow, which is a slow-motion problem that eventually collides with the maximum refresh duration ceilings on shared and Premium capacity. And CU consumption on Fabric capacity is metered by the compute the refresh operation actually performs, so reprocessing unchanged partitions burns capacity that has no analytical payoff. Neither problem is solved by adding capacity; both are solved by refreshing less.

Applying granular refresh to a Dynamics 365 semantic model

The practical starting point is an honest table-by-table audit of your existing model, sorted by two questions: does this table’s data actually change day to day, and does its schema drift when Microsoft ships a Finance and Operations or Business Central update. Tables like open transactions, current inventory on-hand, and active project status are obvious candidates for a Refresh Data Only cadence that runs frequently, maybe hourly if the business case justifies it, without touching schema at all. Large historical fact tables, closed fiscal periods, and reference dimensions that rarely change structure are candidates for a much less frequent Refresh Schema and Data pass, perhaps weekly, with the understanding that if Microsoft renames a field or adds a column mid-week, you will not see it in the model until the next scheduled schema sync.

Abstract illustration of a few illuminated data table blocks refreshing among many dimmed, unchanged ones

Where this pairs particularly well with existing Power BI capability is incremental refresh policies on the largest transaction tables. Incremental refresh already partitions a table by date so that only the current period’s partition gets reprocessed on a routine basis; layering table-level refresh selection on top means you can decide, table by table, whether even that partitioned refresh needs to run tonight or can wait until the weekend. For a semantic model spanning several Dynamics 365 legal entities, this combination is usually the difference between a refresh job measured in tens of minutes and one measured in hours.

Implementing this through the Enhanced Refresh REST API rather than clicking through the UI is worth the extra setup for any model refreshed on a schedule, because it lets you express the table list as configuration rather than tribal knowledge sitting in someone’s memory of which tables to click. A request that targets specific tables through the objects array, with applyRefreshPolicy set appropriately for whether you want the incremental refresh window respected, is straightforward to build and far easier to audit six months later than a manual process. Teams running Power Automate flows or Azure Data Factory pipelines to orchestrate refreshes should treat this as the moment to replace a single “refresh the whole dataset” call with a small set of targeted requests, each on its own cadence.

Where this still needs judgment, not just configuration

Schema-only sync deserves particular caution in Dynamics 365 contexts because Microsoft’s release cadence for F&O and Business Central genuinely does add and rename fields with some regularity, and a model that never runs a full schema sync will eventually diverge from its source in ways that surface as confusing blank columns or broken relationships rather than clean errors. A reasonable middle ground is to schedule schema syncs on their own cadence, independent of data refreshes, rather than skipping them indefinitely because a table’s data refresh doesn’t need one.

It is also worth being explicit with report consumers and downstream teams about which tables now run on which schedule, since the old assumption that “refreshed this morning” meant the entire model was current no longer holds once refresh granularity is in play. A short data dictionary note next to each table, or a dedicated tab in the workspace documentation, prevents the kind of confusion where someone builds a decision on a historical table that was deliberately left out of last night’s run.

The architecture conversation this actually forces

The real value of granular refresh isn’t the UI convenience, it’s that it forces a semantic model design conversation that most Dynamics 365 reporting teams have been avoiding: which tables in this model are operational and which are archival, and should they even live in the same refresh schedule, or the same model, at all. Teams that have this conversation now, while the tooling to act on the answer just became native to the product, will end up with leaner Fabric capacity bills and faster refresh windows than teams that keep treating every semantic model as a single monolithic refresh unit. At Routeget, this is usually the point in a Fabric or Power BI engagement where we walk a client’s existing model inventory table by table rather than accepting the assumption that a full nightly refresh is simply the cost of doing business with ERP-scale data.

#PowerBIRefresh #SemanticModels #DirectLake #FabricCapacity #DynamicsFinanceOps #BusinessCentral

Azure AD B2C’s Retirement Just Reshaped the Power Pages Authentication Provider Decision

IT director reviewing an identity and access management dashboard, representing the Power Pages authentication provider decision

A supply chain director at a mid-market manufacturer recently asked her IT team to stand up a new supplier self-service portal on Power Pages: purchase order visibility, invoice status, a place for vendors to upload compliance documents. Nothing exotic. The kind of project that used to start with a fairly routine question: which identity provider do we wire up for sign-in? For years, the routine answer was Azure AD B2C. It isn’t anymore, and the reason has less to do with Power Pages itself than with a licensing decision Microsoft made about the identity service underneath it.

If your organization is not already an Azure AD B2C customer, you cannot create a new B2C tenant today. That single fact changes the Power Pages authentication provider decision for every external-facing portal currently on a scoping document, and most of the teams building those portals have not caught up to it yet.

IT director reviewing an identity and access management dashboard, representing the Power Pages authentication provider decision

What Actually Changed

Microsoft closed Azure AD B2C to new customers on May 1, 2025. Organizations that already had a B2C tenant on that date can keep using it, keep creating additional tenants, and Microsoft has committed to supporting the product through at least May 2030. Organizations that did not already have a B2C relationship lost the option outright. There was a second, quieter cutoff in between: B2C’s P2 tier, the one with the deeper Conditional Access and Identity Protection integration, was discontinued for all customers, existing and new, on March 15, 2026. Existing tenants moved to P1, which is the tier Power Pages sites have generally run on anyway, so that part of the change was less disruptive than it sounds. The tenant-creation cutoff is the one that actually redraws the map.

Microsoft’s stated replacement is Microsoft Entra External ID, which reached general availability for Power Pages on May 1, 2025 after a public preview that started the previous September. It is a real product, not a rebrand: it gives Power Pages a low-code way to add branded sign-in and registration screens, multi-factor authentication, social identity provider sign-in alongside your own directory, and built-in analytics on who is actually using the portal, all configured from the site’s Identity Providers settings rather than through a separate Azure tenant with a manually registered OpenID Connect application. For a straightforward customer or supplier portal, that setup experience is arguably better than what B2C ever offered.

The Power Pages Authentication Provider Choice, in Practice

Here is where the decision actually splits. If your organization already runs an Azure AD B2C tenant for something else, whether it is an older customer portal, a mobile app, or a partner-facing application, you retain the option to keep building on B2C for new Power Pages sites too, including its deeper customization layer. If you do not have that existing relationship, Entra External ID is not one option among several. It is the only Microsoft-native path forward, because the door to B2C is closed regardless of how well External ID happens to fit your requirements.

That asymmetry matters more than it looks like on the surface. A portal built by an existing B2C shop and a functionally identical portal built by a net-new customer are no longer choosing between comparable tools. One team has the full B2C toolkit available if they need it. The other is working within whatever Entra External ID currently supports, full stop.

The Gap Nobody’s Migration Deck Mentions

What Entra External ID currently supports is where the real planning risk sits. Azure AD B2C’s Identity Experience Framework let architects write custom policies: orchestration logic that could federate authentication out to an external identity provider, including something as specific as a legacy on-premises IdentityServer instance, and then auto-provision a user record in the destination system based on claims that came back from that external IdP. That pattern shows up constantly in supplier and partner portals, where the partner organization already has its own identity system and nobody wants to make external users create yet another password.

Abstract illustration of an aging security key transferring authentication to a new digital identity token, representing migration from Azure AD B2C to Microsoft Entra External ID

Entra External ID does not yet replicate that. A Microsoft moderator confirmed this directly in a Microsoft Q&A thread from an organization that ran into exactly this wall: new B2C tenant creation is closed to net-new customers, existing customers are unaffected, and there is no workaround for the federation and custom-policy gap in External ID. The response was candid about the limitation rather than papering over it, which is useful information in itself: this is a known, acknowledged gap, not a configuration mistake on the customer’s part.

There is a second limitation worth flagging for anyone running a multi-organization or B2B-style portal. Entra External ID’s contact-mapping feature, which automatically associates an authenticated user with the right Dataverse contact record based on their email address, does not apply to multitenant endpoints. If your portal is meant to serve users from several different partner organizations authenticating through their own tenants rather than one shared consumer-style sign-up flow, that automatic mapping convenience simply is not there yet, and the provisioning logic has to be built by hand elsewhere in the solution.

Neither gap is disqualifying on its own. Both are the kind of detail that surfaces three weeks into a build rather than during the initial scoping conversation, which is exactly when it is most expensive to discover.

What This Means for a Portal You’re Scoping Right Now

Before signing off on the identity approach for a new Power Pages site, it is worth getting a straight answer to a short list of questions. Does the portal need to authenticate users who already have credentials in a system Microsoft does not control, such as a partner’s own identity provider or an on-premises directory that predates your cloud migration? Does user access depend on custom provisioning logic beyond a standard email-and-password or one-time-passcode sign-up, such as auto-approving users from a specific partner domain or pulling attributes from an external system at the moment of first login? Will the portal ultimately need to serve users authenticating from more than one external tenant rather than one consolidated sign-up pool?

A “yes” to any of those questions is worth checking against your organization’s actual B2C status before the project plan gets locked in. If you already hold a B2C tenant, that route remains open and may be the lower-risk path for a portal with those requirements, with the reassurance of Microsoft’s support commitment running through 2030 to absorb the migration timeline. If you do not, the honest scoping conversation is about designing around Entra External ID’s current boundaries: pushing provisioning and claims logic into Power Automate flows or Dataverse plugins that run after a simpler authentication event, rather than assuming the identity layer itself will do that orchestration for you. Microsoft’s own FAQ on this transition is candid that detailed migration guidance is still being finalized and points customers to their account team for specifics, which is itself a signal that this is an evolving area worth revisiting before a portal design is treated as final.

None of this argues against building on Power Pages. It argues for treating the authentication provider decision as a genuine architecture choice again, the way it was before B2C became the automatic default, rather than a checkbox to clear on the way to the parts of the portal that feel more interesting. We have been walking clients through exactly this calculation at Routeget, both for organizations sitting on legacy B2C configurations deciding whether to keep extending them and for net-new engagements designing around External ID’s current limits rather than building technical debt against a gap Microsoft has acknowledged but not yet closed.

#PowerPages #AzureADB2C #EntraExternalID #IdentityGovernance #PowerPlatform #PartnerPortals

Dynamics 365 Contact Center Voice Biometrics Just Reached GA. Your Compliance Review Hasn’t.

Contact center security analyst reviewing a voice authentication waveform and verification dashboard on a monitor

A customer calls in about a suspicious charge, and before a human agent ever picks up, the system has already confirmed who they are by the sound of their voice. No security questions about a mother’s maiden name, no four-digit PIN read aloud to a stranger, no thirty seconds of dead air while an agent pulls up an account and reads through a verification script. As of September 15, 2026, Dynamics 365 Contact Center voice biometrics is generally available, and for any organization running high call volumes through Microsoft’s platform, it is worth pausing on before flipping the switch. The technology is ready. The question most IT and legal teams haven’t finished answering is whether their organization is.

What Dynamics 365 Contact Center Voice Biometrics Actually Shipped

Voice biometrics authentication entered public preview in August 2026 and reached general availability a month later, built natively into both the Dynamics 365 Contact Center voice agent platform and Copilot Studio, so it works whether a caller is being verified by a bot or handed off to a person. The mechanics are straightforward on paper: a caller enrolls a voiceprint during an initial interaction, and on subsequent calls the system compares live speech against that stored print to confirm identity, either as a standalone factor or layered with a one-time SMS passcode and knowledge-based challenge questions for higher-risk transactions. Authentication happens before the call routes to a representative, which is the detail that matters most for anyone modeling the business case: the verification step that used to consume the first minute or two of an agent’s time now happens in the queue, invisibly, while the caller is still on hold.

Microsoft has packaged this with fraud case management tools, prebuilt performance dashboards, and centralized administration through the Customer Service Admin Center, so security and fraud teams get a single place to define policy, monitor false-accept and false-reject rates, and audit which callers were verified by voice versus a fallback method. That last piece, the audit trail, is going to matter more than most rollout plans currently assume.

Why this actually changes the cost equation

The economics here are more concrete than most AI-adjacent contact center features, because pre-authentication attacks a cost driver that finance teams already track closely: average handle time. Identity verification through spoken challenge questions is slow, it’s inconsistent across agents, and it’s one of the easiest points in a call for a trained social engineer to talk their way past a tired representative. Moving that verification into an automated, voice-based step ahead of routing shortens the part of the call an agent actually has to manage and removes a well-documented fraud vector at the same time. For contact centers handling account changes, payment authorizations, or sensitive service requests, that combination of lower handle time and reduced fraud exposure is the kind of dual benefit that gets a feature prioritized on a roadmap fast.

It’s also why this shouldn’t be treated as a routine feature-flag decision. Voice biometrics is biometric data collection, full stop, and that classification carries legal obligations that have nothing to do with how well the Dynamics 365 configuration works.

The compliance gap Microsoft’s documentation doesn’t close

Abstract illustration of a voice waveform authenticating through a glass security shield, representing voice biometric verification

Microsoft’s release notes for this feature describe the enrollment and verification flow in useful technical detail, but they are notably silent on consent language, retention schedules, and regional legal exposure. That’s not an oversight so much as a boundary: Microsoft is providing the platform capability, and the legal responsibility for how a specific organization collects and stores voiceprints from its customers sits with that organization, not with Redmond.

That responsibility is not trivial in the United States right now. Illinois’s Biometric Information Privacy Act remains the sharpest edge in this space, because unlike most state privacy laws, it grants individuals a private right of action, which is what has driven years of class-action litigation against companies that collected fingerprints, face scans, or voiceprints without the specific written notice and consent BIPA requires. A 2024 amendment narrowed the damages exposure somewhat, treating repeated collection through the same method as a single violation rather than a separate claim per scan, but the underlying notice-and-consent obligation didn’t go anywhere. Texas and Washington impose similar consent and retention requirements, enforced by their respective attorneys general rather than through private lawsuits, which changes the risk profile but doesn’t eliminate it. Colorado added more prescriptive deletion requirements to its biometric provisions in 2024, and Louisiana became the twenty-second state with a standalone biometric consent law in May 2026. For a multistate contact center, that adds up to a genuine patchwork, not a single compliance checkbox.

None of this makes voice biometrics a bad decision. It makes it a decision that has to be made jointly by IT, legal, and the security or fraud team, rather than one that gets configured and enabled the same week a Message Center notice lands.

What to actually check before enabling it

Start by mapping where your callers are located, not just where your contact center is headquartered. If any meaningful share of inbound volume originates in Illinois, or in any of the other states with biometric consent requirements, that determines whether you need affirmative, specific consent captured and documented before enrollment, not just a line buried in a privacy policy. Build that consent capture into the IVR flow itself, worded clearly enough that a caller understands they are being asked to enroll a biometric identifier, and log that consent event somewhere durable and auditable, ideally tied to the same Dataverse record the fraud dashboards already reference.

Retention and deletion policy needs equal attention. BIPA and its state counterparts generally require organizations to publish a retention schedule and actually delete biometric data once it’s no longer needed for the purpose it was collected for, which means someone has to define what “no longer needed” means for a voiceprint tied to an active customer relationship, and build the deletion workflow to match, not just write the policy and leave the data sitting in Dataverse indefinitely.

It’s also worth treating the rollout as opt-in rather than a default-on migration, at least initially. Keeping SMS OTP and knowledge-based challenges available as an equal-footing alternative, rather than a fallback for people who refuse voice enrollment, avoids putting the organization in the position of coercing consent, which is exactly the fact pattern that has produced some of the more aggressive BIPA litigation elsewhere. A phased pilot in a single, lower-risk jurisdiction, with legal and fraud teams reviewing false-accept rates and consent capture together before wider rollout, is a more defensible path than enabling it organization-wide the week after the Message Center notice arrives.

The takeaway for decision-makers

Voice biometrics in Dynamics 365 Contact Center is a genuinely useful capability, not a gimmick. It shortens calls, closes a real fraud gap, and gives fraud analysts tooling they didn’t have before. But general availability from Microsoft answers the technical readiness question, not the legal one, and the two timelines rarely move at the same pace. Organizations that treat this as a joint IT-legal-security decision, with consent and retention worked out before enrollment goes live, will capture the cost and fraud benefits without inheriting a class-action problem a year later. Routeget Technologies works with contact center teams on exactly this kind of platform-and-compliance sequencing when new Dynamics 365 capabilities reach GA faster than the surrounding legal review, and that pairing is usually the difference between a smooth rollout and a rushed one.

#DynamicsContactCenter #VoiceBiometrics #ContactCenterFraud #BiometricPrivacyLaw #OmnichannelCX #CustomerServiceSecurity

Business Central’s OData Deprecation Is the Deadline That Actually Matters

Solution architect reviewing integration and API connection status on a monitor, representing Business Central OData migration planning

Every Business Central partner with a client list has spent the last few months triaging one deadline: SOAP web services on Microsoft-authored pages stop working the moment version 29.0 goes generally available on October 1, 2026. It’s a real cutoff, it’s close, and it deserves the attention it’s getting. But teams that treat that project as the finish line are missing the bigger one sitting six months behind it. Business Central’s OData deprecation for Microsoft UI pages lands with version 30.0, the 2027 release wave 1 release scheduled for the first workday of April 2027, and it is going to break far more integrations than SOAP ever did, because OData has been the default, path-of-least-resistance protocol for Business Central reporting since NAV migrated to the cloud.

Here’s the scenario that shows up in almost every environment once you actually go looking: a controller built an Excel workbook years ago that pulls G/L entries through an OData feed on a standard Microsoft page. Nobody remembers who set it up. It isn’t in the integration inventory because nobody classified a spreadsheet as an integration. A Power BI dataset does the same thing against the Customer or Item Ledger Entry pages, refreshing nightly through a service account that predates the current IT team. None of this shows up when you audit “our integrations,” because the people who’d know to look for it moved on, and the connections themselves were never registered anywhere except a connection string buried in a Power Query step. SOAP, by contrast, was mostly used by a smaller set of legacy middleware tools that companies have already been migrating off for years because SOAP has felt dated since well before Microsoft announced its removal. OData never felt dated. It’s still the protocol Microsoft’s own documentation recommends for ad hoc reporting scenarios, right up until version 30 removes the ability to expose a Microsoft-authored page through it at all.

Solution architect reviewing integration and API connection status on a monitor, representing Business Central OData migration planning

What Business Central’s OData deprecation actually removes

The scope here matters, because it’s narrower than the headlines suggest and that narrowness is exactly what makes it easy to underestimate. Starting in version 30, Business Central will no longer allow a page published by a Microsoft-authored app, meaning the Base Application, System Application, or any other first-party extension, to be exposed as an OData endpoint. Custom pages you or a partner built in your own AL extension are unaffected. Standard API pages and API queries, which already use a different endpoint structure under /api/v2.0/, are unaffected. What goes away is specifically OData access to the UI pages Microsoft ships out of the box: the Customer Card, the Chart of Accounts, the Sales Order list, and every other page that a reporting tool or Excel workbook has been happily pointing at for a decade.

Microsoft’s stated rationale is worth understanding because it explains why there’s no reprieve coming. A UI page isn’t governed by the same change-management discipline as an API. Microsoft can add a field, reorder a FastTab, or rename a control on a standard page in a minor update without that counting as a breaking change to the platform, but if your OData integration depends on that page’s exact shape, the same update breaks your feed. Microsoft has effectively decided it can no longer support that implicit contract at scale, and the SOAP removal in version 29 was the first half of enforcing that decision. Version 30 finishes it for OData.

Finding what you don’t know is there

Before any migration plan makes sense, you need an honest inventory, and guessing from documentation or asking the client “what connects to BC” will undercount every time. Business Central’s telemetry to Application Insights already logs this if you have it wired up. Web service requests are recorded under event ID RT0008, and the category custom dimension on that event records whether each call came in as API, ODataV4, ODataV3, or SOAP. Paired with the alObjectName and endpoint dimensions, a straightforward Kusto query against your Application Insights workspace, filtering customDimensions.eventId == "RT0008" and grouping by category and object name, will produce a real list of which Microsoft pages are being called through OData, how often, and from what client. Run that query across a full month rather than a day or two; monthly reports and quarter-end reconciliation jobs won’t show up in a short window, and those are exactly the integrations most likely to have been forgotten.

Abstract illustration of a legacy data connection node fading out as a new API connection node forms, representing migration from OData to API v2.0

Triaging what the audit finds

Once you have the list, not every entry needs the same fix, and treating them uniformly wastes effort on the easy ones while under-resourcing the hard ones. Some OData calls map directly onto an existing standard API entity: Customer, Vendor, Item, and Sales Order OData feeds usually have a clean equivalent already published under API v2.0, and switching the connection string plus adjusting field names is genuinely a low-effort change. Others don’t have a standard API match because they’re pulling something specific, like a custom-shaped join across ledger entries and dimensions that a spreadsheet author built by hand in Power Query. For those, an AL query object is usually the right tool rather than trying to force a page-based API to do the work. Query objects are read-only, they can join across multiple tables the way the old OData feed effectively did through Power Query, and they publish as their own API endpoint with proper OData-style $filter and $select support, without exposing a Microsoft UI page at all. A third category is the genuinely awkward one: integrations built around unbound actions on standard pages, which as of now have no direct equivalent in the REST API surface. Microsoft hasn’t closed this gap yet, so the practical workaround is either wrapping the needed logic in a bound action on a custom API page you control, or moving that piece of orchestration out of Business Central entirely into an Azure Function or a Logic Apps flow that calls the standard API for the parts it can and handles the rest itself.

The option nobody should default to, but should know exists

If a specific OData integration truly cannot be replatformed before April 2027, Microsoft’s own guidance leaves one path open: copy the source code of the standard page into your own extension and publish that copy as the OData endpoint instead. This works because the restriction is specifically on pages published by a Microsoft-authored app, not on OData as a protocol. It should be treated as a last resort rather than a template, though, because it means you now own maintaining a forked copy of a Microsoft page indefinitely, including replicating any future field or logic changes Microsoft makes to the original. For a page that rarely changes, that’s a manageable trade-off for another year or two of runway. For a page tied to core financial posting, it’s a maintenance burden that will outlast the convenience it buys.

Building the plan now

Version 29’s SOAP removal is close enough that most partners already have a project underway for it, and there’s real value in doing the OData audit at the same time rather than as a separate engagement six months from now. The RT0008 telemetry query doesn’t distinguish urgency by protocol, so pulling both SOAP and OData usage in one pass gives you a single, complete picture of every legacy web service dependency in an environment instead of two half-finished ones. Clients who hear “we already checked your integrations for the SOAP deadline” and then get surprised by an OData outage eighteen months later will reasonably ask why the first audit didn’t catch it. It’s a fair question, and the honest answer is that it’s a different telemetry filter and a few extra hours of query classification, not a fundamentally different project. Doing both now, while the environment’s already open on the workbench, is the cheaper version of this work by a wide margin.

Routeget Technologies has been walking clients through Business Central’s SOAP and OData retirement timelines as part of standard health-check engagements, building the telemetry-based inventory first so the migration scope is based on what’s actually running rather than what’s documented.

#BusinessCentralOData #ODataDeprecation #APIv2Migration #BCIntegrations #ERPGovernance #BusinessCentralAPI

Project Operations Subscription Billing Is Live, But Not for Every Deployment

Finance controller reviewing a recurring billing schedule dashboard on a laptop

A finance director at a mid-size systems integrator called her Microsoft partner last week with a simple question: can we finally bill our managed services retainers automatically instead of re-keying the same fixed-fee lines into a project invoice every month? She had just read a Message Center notice about Project Operations subscription billing and wanted to know how soon her team could stop doing this by hand. The answer she got was more complicated than the announcement suggested, and it is worth walking through, because the gap between what is generally available today and what is entering preview later this month will shape a real budgeting decision for a lot of professional services firms this quarter.

Project Operations Subscription Billing: Two Announcements, Not One

There are actually two separate pieces of functionality connected to this topic, and conflating them is the easiest way to make a bad planning decision. The first, “enable project fee journals to support subscription billing,” has been generally available since Dynamics 365 Finance version 10.0.46, released in October 2025. It lets a project generate a billing schedule through the Subscription Billing module, using Project Fee Journal as the invoice transaction type instead of a standard project invoice. The second, tracked in Microsoft’s Message Center as MC1472430 and titled simply “support subscription billing for Project Operations,” entered public preview on September 30, 2026. It promises recurring billing on flexible cadences, tiered pricing models, subscription hold and termination handling, and refund management, described by Microsoft as reducing manual intervention in recurring invoicing. Only the first one exists in production today. The second is a preview, and previews change shape before they reach general availability.

How the Fee-Journal Mechanism Actually Works

For the capability that is live now, the workflow starts on the project record itself. From Project management and accounting, a user creates a new billing schedule directly from the project, and the system automatically populates the customer account, the project ID, and the funding source. The invoice transaction type gets set to Project Fee Journal rather than Sales Order, which determines how the billing schedule lines behave. Each line carries a fee category, a unit price, and the usual tax fields, but it flows through work-in-progress and accrual postings before it ever becomes a customer-facing invoice.

That sequencing matters more than it sounds. Rather than posting a project invoice the moment work is recorded, the system books WIP and accrual entries through the fee transaction first, then generates the actual invoice on a schedule, whether monthly, quarterly, or however the contract is structured. A firm can choose from three posting behaviors: generate the fee journal only and create invoices manually later, generate the journal and stop at an invoice proposal for review, or post the invoice automatically in one step. That range gives controllers real choice over how much human review sits between recognized revenue and a document that goes out to the client.

Finance controller reviewing a recurring billing schedule dashboard on a laptop

The catch, and it is a significant one, is that this fee-journal path is only available for Project Operations deployments that run on the Finance and Operations platform, what Microsoft’s own documentation refers to as Project Operations for manufacturing. A standalone deployment of Project Operations, the version many services firms chose specifically because it does not require standing up the full Finance and Operations stack, cannot use it. If your organization licensed Project Operations to avoid exactly that complexity, the subscription billing capability that shipped last October simply is not on your platform, no matter how current your update cadence is.

Why the Deployment Distinction Is the Actual Decision Point

This is where the finance director’s original question gets harder to answer cleanly. If her firm runs the Finance-integrated deployment, the fee-journal mechanism is already available, and the work is largely configuration: enabling the relevant features in Feature management, setting project stage rules to trigger billing schedule creation automatically, and deciding which of the three posting behaviors matches her team’s risk tolerance for unattended invoicing. If her firm runs standalone Project Operations, the near-term answer is to watch the MC1472430 preview closely rather than assume it will simply extend the same mechanism to her platform.

Microsoft’s release documentation for 2026 wave one describes the fee-journal capability specifically in the context of manufacturing deployments, and nothing in the public preview announcement confirms that the broader recurring billing framework will be deployment-agnostic once it reaches general availability. Firms that commit new client contracts to a subscription billing structure on the assumption that Project Operations will automate it end to end, without first confirming which platform variant they run, are setting up a manual workaround they did not budget for. That is an expensive mistake to discover six months into a new retainer agreement.

There is a real financial argument for making this move regardless of which deployment a firm is on, and it has less to do with saving a few hours of invoice preparation than with getting revenue recognition right. Because the fee-journal mechanism books WIP and accrual entries ahead of the customer invoice, it gives finance teams a documented, systematic separation between when value is delivered and when cash is billed. That separation is exactly what supports ASC 606 and IFRS 15 compliance for recognizing revenue independent of billing milestones. A firm still reconciling that gap manually in a spreadsheet, project by project, is carrying audit exposure that this feature is specifically built to remove. That argument for prioritizing the upgrade path is stronger than “we bill retainers and want less manual work,” even though the manual-work complaint is usually what starts the conversation.

Abstract illustration of a recurring billing cycle with glowing invoice nodes

What to Check Before the Next Contract Renewal Cycle

Before signing a new managed services or retainer agreement on the assumption that Project Operations will handle the billing automatically, confirm three things. First, identify which Project Operations deployment your organization actually runs, since the terminology in vendor conversations, and even in some Microsoft documentation, does not always make the distinction obvious to someone outside the implementation team. Second, if you are on the Finance-integrated deployment, treat this as a configuration and change-management project rather than a licensing question. Feature management settings, project stage rules, and the choice of posting behavior all need to be worked through with whoever owns your Dynamics 365 Finance environment before the first live billing schedule goes into production.

Third, if you are on standalone Project Operations, do not build a client-facing commitment around a preview feature. Track the Message Center entry, ask your partner directly whether the general availability scope will include your deployment type, and keep the manual process in place as a fallback until that answer comes back in writing rather than inferred from a roadmap post. Preview features are, by definition, subject to change, and a contract term written around one is a liability if the feature narrows or slips before it ships broadly.

The subscription billing announcement is a genuine step forward for firms trying to move recurring engagements off manual invoicing, and the fee-journal mechanism that already exists proves the underlying accounting model works in production. What it is not, yet, is a platform-wide capability every Project Operations customer can turn on this quarter. Firms that treat the distinction seriously now will spend less time unwinding a contract structure that outran their tooling. We have walked several clients through exactly this kind of platform-versus-roadmap gap during Project Operations rollouts, and the pattern holds: the tooling question is almost always simpler to answer once the deployment type is confirmed first, before a single retainer contract gets rewritten around a capability that may not yet apply to it.

#ProjectOperations #SubscriptionBilling #RevenueRecognition #ProfessionalServicesFinance #DynamicsFinanceOps #ERPGovernance