Business Central Accelerated Depreciation Reaches GA. The Real Decision Isn’t in the Setup Screen.

Finance office desk with a laptop, binders, and a plant, representing fixed asset depreciation recordkeeping

A controller at a mid-market manufacturer with a French subsidiary spends part of every quarter close doing something Business Central was never quite built to do natively outside that one country: running two depreciation schedules for the same fixed assets. One follows straight-line depreciation for consolidated financial reporting. The other follows an accelerated, tax-driven method required by local law, applied through a coefficient that increases with the asset’s useful life. The two schedules rarely agree, and reconciling the gap between them, quarter after quarter, in a spreadsheet that lives outside the ERP, is exactly the kind of manual process that turns a routine close into a source of quiet risk.

That gap is what Microsoft is closing with Business Central accelerated depreciation, a new capability that makes accelerated depreciation methods for fixed assets standard, general-purpose functionality rather than a country-specific add-on. The feature entered public preview on June 5, 2026, and Microsoft’s release plan lists general availability for October 2026, putting it in the same wave as several other core financial management updates, including new handling for withholding taxes and vendor-specific numbering for self-billing invoices. For finance leaders at Business Central customers with international operations, particularly anyone with entities subject to accelerated or declining-balance tax depreciation requirements, this is worth planning for now rather than discovering after the fact.

Finance office desk with a laptop, binders, and a plant, representing fixed asset depreciation recordkeeping

How Business Central Accelerated Depreciation Works

Business Central has supported multiple depreciation methods for years, including declining-balance calculations. What’s new is not a depreciation method in isolation, but a mechanism for running two depreciation views of the same asset side by side and automatically tracking the difference between them. Setup happens in two places. A depreciation book is configured to use an accelerated depreciation method, and the fixed asset card itself is where the acceleration coefficient and related settings get entered. From there, Business Central calculates the accelerated depreciation amount, the equivalent straight-line amount for the same period, and the variance between the two, posting all three to the appropriate general ledger accounts without any custom extension in the mix.

This will look familiar to anyone who has worked with Business Central’s existing France localization, where a very similar pattern already exists to satisfy French tax law: companies above certain size thresholds must track the difference between accounting depreciation and a faster tax depreciation schedule, using what the system calls a derogatory posting structure, with the variance flowing to dedicated derogatory accounts. The mechanics described for this new, generalized feature (an acceleration coefficient, an automatically calculated linear equivalent, a tracked variance, and inquiry pages showing annual depreciation, variance, and remaining book value) map closely onto that existing model. Whether or not the underlying code is literally shared, the design clearly draws from a pattern Microsoft already had working and tested in one jurisdiction, and is now making available as base functionality rather than something scoped to a single country’s localization pack.

That distinction matters for anyone evaluating this outside France. A business in the United States, India, or the UK, for instance, doesn’t operate under the same statutory requirement to track a tax-accelerated depreciation variance the way French entities do. But plenty of these organizations still want the option: a US subsidiary with MACRS-based tax depreciation running alongside GAAP book depreciation, or a private company that simply wants to accelerate cost recovery for internal planning purposes while keeping a clean straight-line view for lenders or investors, are both scenarios this feature could serve without anyone needing to install a country pack that assumes French tax law.

Abstract illustration of two diverging depreciation curves converging into a single reconciled sphere

The Business Case, in Concrete Terms

The immediate value is not abstract. Today, a company that wants to run accelerated depreciation alongside standard book depreciation, without the France localization applying, typically does it in a spreadsheet, in a bolt-on tax fixed-asset tool, or by approximating it through manual journal entries. Each of those approaches introduces the same three problems: someone has to remember to update the calculation every period, the numbers live outside the system of record, and reconciling the two views at close consumes hours that could go toward analysis instead of arithmetic. Native support inside Business Central removes the reconciliation step almost entirely, because the accelerated amount, the linear equivalent, and the variance are all calculated and posted automatically as part of the standard depreciation run.

There’s a second, less obvious benefit for organizations weighing platform decisions. Companies migrating off legacy systems such as Dynamics GP or NAV, or evaluating Business Central against alternative ERPs during a broader Dynamics 365 implementation, often assume that anything resembling statutory dual-book depreciation requires a heavier, F&O-tier platform or a bolt-on fixed-asset module. A capability like this narrows that gap, and it’s a reasonable data point for IT directors and finance leaders building the business case for a Business Central consulting engagement rather than a more expensive alternative.

What Finance Leaders Should Decide Before Turning It On

The setup itself, a depreciation book configuration plus a coefficient on the asset card, is not the hard part. The hard part is the policy decision that has to happen first, and it belongs with the CFO and controller, not with whoever configures the system.

The first question is which assets actually warrant an accelerated view, and why. If there’s no statutory requirement driving it, the acceleration coefficient becomes a matter of internal accounting policy, and that policy should be documented and applied consistently rather than set asset by asset based on whoever happens to be entering the fixed asset card that week. The second question, and arguably the more consequential one for finance teams that haven’t dealt with dual-book depreciation before, is what the tax-versus-book variance actually represents on the balance sheet. In jurisdictions where accelerated tax depreciation legitimately exceeds book depreciation, that gap is typically the source of a deferred tax liability, and finance teams new to running parallel schedules should loop in their tax advisor or external auditor before the first variance posts, not after it shows up in a quarterly review with no clear explanation.

Third, this is a case where the preview window is genuinely useful rather than a formality. With public preview available since June and general availability not expected until October, there’s real time to configure this in a sandbox environment, run it against a representative sample of fixed assets, and confirm the inquiry pages produce numbers that match what a manual parallel calculation would show, before it touches production data. Given how much else is shipping in the same core financial management wave, including changes to withholding tax handling that could interact with the same vendor and asset records, a sandbox validation pass is worth the time even for teams that don’t consider themselves early adopters.

Finally, IT and finance should jointly confirm whether this actually reduces total license or tooling cost. If a bolt-on fixed-asset or tax depreciation tool is currently in use specifically to solve this problem, this feature is a legitimate reason to reevaluate that contract, but only after the sandbox testing confirms the native functionality produces defensible, audit-ready numbers on its own.

None of this makes accelerated depreciation a feature every Business Central customer needs to touch. Most domestic, single-entity businesses running straight-line depreciation for both book and tax purposes will have no reason to configure it at all. But for finance teams already juggling a manual reconciliation between two depreciation views, whether because of a French entity, a multinational tax position, or an internal policy choice, this closes a gap that has existed in Business Central’s core financial management module for a long time. Routeget Technologies has walked clients through comparable dual-book depreciation setups during Business Central and legacy ERP migrations, and the pattern holds regardless of which system is involved: the software can automate the calculation, but only the finance function that owns the underlying accounting policy can decide what that calculation should actually produce.

#BusinessCentral #FixedAssetDepreciation #TaxBookReconciliation #FinanceTransformation #ERPTaxCompliance #ERPModernization

Subcontractor Vendor Invoice Matching Is GA in Project Operations. Ten Silent Fields Decide If It Works.

Project accountant reviewing a vendor invoice reconciliation dashboard for subcontractor cost matching

A project controller at a mid-size engineering firm spends the third week of every month reconciling subcontractor invoices against timesheets in a spreadsheet, because the vendor invoice that lands in accounts payable has no native connection to the hours a contract welder actually logged against a task. She cross-checks rates, dates, and task codes by hand, then emails the project manager to confirm before anything gets marked ready for payment. That reconciliation gap is exactly what general availability of subcontractor vendor invoice matching to actuals in Dynamics 365 Project Operations, reached this September as part of 2026 release wave 1, is meant to close. For any organization running resource-based or nonstocked subcontracting through Project Operations, this is worth a close look before the next AP cycle, not because the concept is new (a version of automatic matching has existed since 2022), but because the field-level logic determining whether a match actually happens is stricter, and less forgiving, than most implementation teams assume going in.

What subcontractor vendor invoice matching actually changes

Subcontract-based project delivery in Project Operations has always followed a familiar shape: a project manager creates a subcontract against a vendor, attaches purchase price lists, links time-based or expense-based subcontract lines to either generic team members (to represent a staffing need) or named contract workers (to draw down capacity), and lets subcontractor resources log time, expenses, or product usage against tasks. Once that work is approved, it generates project cost actuals priced from the subcontract’s purchase rate. None of that is new. What the newly GA capability changes is the connective tissue between those cost actuals and the vendor invoice line items that eventually get paid.

Before this feature matured, matching a vendor invoice line to the underlying cost actuals was either manual or dependent on earlier, more limited automatic-association logic. Now, when a project manager records a vendor invoice with a line referencing a subcontract, Project Operations attempts to associate matching cost actuals automatically, and gives the project manager a structured, auditable workflow (built around a Verification status field) to confirm, adjust, or reject those matches before the invoice becomes eligible for payment.

The match logic: what has to line up

This is the part implementers need to internalize before go-live, because it determines whether the automatic matching actually fires or silently leaves everything to manual review. For a cost actual to link to a vendor invoice line, two separate conditions both have to hold.

Abstract illustration of cost actual records linking to vendor invoice line items in a reconciliation chain

The first is a status condition: the cost actual’s Adjustment status field must be blank. If a cost actual has been recalled, if its approval was cancelled, or if a correction journal against it is in progress, it is excluded from matching entirely, and the system will not surface it as a candidate no matter how closely the other fields align. This one trips up teams during parallel testing more than any other rule, because test data frequently includes actuals that went through a correction cycle, and those actuals simply never appear in the unmatched list, with no error message explaining why.

The second is field equivalence, and this is the longer list: project contract, project contract line, transaction class, project, task, resource category, transaction category, product, subcontract line, and bookable resource. Every one of these fields on the vendor invoice line has to match the corresponding field on the cost actual for a link to be proposed. There is one important carve-out worth building into your test plan: if a field is simply not populated on the vendor invoice line, it is excluded from the comparison rather than treated as a mismatch. That sounds like a convenience, and in some cases it is, but it also means a sparsely populated invoice line can match against a broader set of cost actuals than a fully populated one would, which is not always the outcome an AP team expects when they are trying to enforce tight three-way matching discipline.

Verification status: the workflow project managers actually see

Once matching candidates exist, the project manager works through a Verification status field that moves through three states. Not started is the default state for a fresh vendor invoice line, and it is the only state in which the line remains freely editable. The moment the first cost actual is matched to that line, status automatically advances to In progress, and the line locks against further direct edits outside the matching interface itself. From In progress, the project manager reviews the matched actuals in a grid, can pull in additional unmatched actuals or remove ones that were matched incorrectly, and once satisfied, sets the line to Complete, either manually or through the system’s own completion logic once every actual on the line has been addressed. Only when every line on a vendor invoice reaches Complete can the invoice itself be confirmed, and confirming it is what flips the invoice to Ready for payment, reverses the previously recorded project cost actuals, and books the actual cost from the vendor invoice onto the project instead. That last step matters for anyone reconciling project cost reports mid-cycle: costs on a project can genuinely shift in value between the point a subcontractor’s time is approved and the point the corresponding invoice clears verification, and finance teams need to know that is expected behavior, not a data integrity problem.

Unmatching works, but only in one direction of the workflow. A project manager can select one or more linked cost actuals from a vendor invoice line’s Matched cost actuals tab and unmatch them, but only while that line sits in In progress status. Once a line reaches Complete, unmatching is no longer available through the standard interface, which is a deliberate control: it keeps a verified invoice from being quietly altered after AP has already relied on that verification to release payment.

Implementation considerations before rollout

A few practical points are worth working through with the project accounting team before turning this on for a live subcontracting population. Fixed Price billing is not currently supported for resource-based or nonstocked subcontracting scenarios, so any subcontract lines built around milestone-based fixed pricing need a different reconciliation approach; automatic matching in this feature applies to time-and-material subcontract lines where cost actuals are generated from logged, approved work. Teams that run a mix of fixed-price and time-and-material subcontracts on the same project should map out, line by line, which subcontract lines are even eligible for automatic matching before assuming full invoice coverage.

It is also worth auditing how consistently your existing vendor invoice entry process populates the ten matching fields. If your AP team has historically entered vendor invoice lines with only project and transaction class filled in, and left task, resource category, or bookable resource blank as a matter of habit, the matching engine will happily use whatever partial field set is present, and the practical effect is a much looser match than your controls team may assume is happening. Before rollout, walk through a sample of recent invoices with both project accounting and AP to agree on which fields will be entered consistently going forward, because the strictness of this feature is only as good as the discipline behind the data feeding it.

Finally, because this capability reached general availability in the same month as several other Project Operations updates, including changes to correction journal usability and project accrued revenue reconciliation, it is worth testing subcontractor invoice matching in a sandbox environment that reflects your current configuration rather than assuming behavior documented earlier in the release wave still applies unchanged. Microsoft’s release cadence for Project Operations has been dense enough this year that features shipped in preview back in May have, in some cases, had their default behavior refined by the time they reached GA in September.

Organizations that get the field discipline right stand to remove a genuinely manual, error-prone step from project-based AP, and the audit trail built into the Verification status workflow gives finance a defensible record of exactly which actuals supported each payment decision. Routeget’s implementation teams have walked several clients through exactly this kind of subcontract reconciliation redesign, and the pattern holds consistently: the technology is ready well before the underlying data entry habits are, and that gap is where rollout timelines usually slip.

#SubcontractorInvoiceMatching #ProjectOperations #DynamicsFinanceOps #ProjectAccounting #VendorInvoiceReconciliation #ERPGovernance

Power Platform Agent Authentication Governance Reaches GA: What to Audit First

An IT administrator reviewing an agent identity and access governance dashboard on a large office monitor

A CISO at a mid-market manufacturer asked her Power Platform admin a simple question last month: how many Copilot Studio agents does the organization actually have running, and how many of them require anyone to prove who they are before they can use them? The admin came back three days later with a spreadsheet of 214 agents. Nineteen had “No authentication” configured. Four of those nineteen had access to a knowledge source containing vendor contract terms. Nobody remembered turning authentication off for any of them, because nobody had turned it on to begin with. It had simply never been set. That gap is exactly what Power Platform agent authentication governance, which reached general availability this month, was built to close.

Microsoft has been describing this exact scenario in its own guidance for a while. In a February 2026 security post, Microsoft described unauthenticated agents as a recurring pattern rather than an edge case: authentication gets “deactivated for testing, left in its default state, or misunderstood as optional,” and the result is an agent that anyone with a link can use, sometimes surfacing internal information through its topics, actions, or knowledge sources without anyone intending it to. The fix Microsoft has been building toward arrived this month, and it changes who is responsible for catching this problem before it reaches production.

What Power Platform Agent Authentication Governance Actually Does

The feature reached general availability on September 2, 2026, after a public preview that opened in late May. Listed in Microsoft’s release plan as “Manage agent security with enhanced admin controls,” it gives administrators a way to set authentication and access policy for agents centrally, at the environment or environment group level, inside the Power Platform admin center. Rather than relying on individual makers to choose the right authentication setting each time they build or republish an agent, an admin can now require Microsoft Entra ID authentication across a group of environments, permit a defined list of approved external identity providers for agents that genuinely need one, or block anonymous access outright.

The detail that matters most for a governance program is when these policies get enforced. This is not a design-time warning that a maker can dismiss and move past. Microsoft’s own documentation describes the policy as evaluated both when an agent is deployed and again at runtime, so a policy change made after the fact actually reaches agents that are already published, not just new ones being built going forward. That closes a gap that has existed in Copilot Studio governance for a while: DLP data policies could already restrict unauthenticated usage at the tenant level, but that control was blunt. It did not give admins a way to say, for example, that the environment group serving finance requires Entra ID, while a separate environment group hosting a public-facing customer service agent is allowed to run anonymously because that is the intended design.

That distinction is worth sitting with, because the instinct after reading a story like the manufacturer’s spreadsheet is to conclude that anonymous access is always the mistake. It isn’t. A number of legitimate agents, particularly ones embedded in Power Pages sites or public marketing properties, are supposed to be reachable without a sign-in. The problem in most organizations is not that anonymous agents exist. It is that nobody made a deliberate decision about which ones should, and the setting drifted in by default rather than by design.

Abstract illustration of glowing padlock and key icons connected in a network, representing agent identity and access governance

Why This Became Urgent Now

The timing lines up with a broader shift that most IT leaders are already tracking anecdotally even if they haven’t quantified it. Citizen-developer agent creation in Copilot Studio has grown faster than most organizations’ governance processes have kept pace with, and a maker publishing an agent from a template or a quick prototype rarely stops to think about identity architecture. Microsoft’s guidance on securing Copilot Studio deployments at scale describes a zoned model, where agents built by citizen developers are expected to carry the least privilege and the most constrained data access, and where authentication choices become progressively more deliberate as an agent moves toward professional development and broader distribution. Enforcement has lagged the model. Before this release, an admin who wanted to guarantee that zone boundaries actually held had to lean on DLP connector policies and manual audits, neither of which was built specifically to answer the authentication question.

There’s also a compliance dimension that will matter more to some organizations than others. Regulated industries, healthcare, financial services, and any company subject to a SOC 2 or ISO 27001 audit cycle have been fielding questions from auditors about AI agent access controls for a while now, often without a clean answer. A centrally enforced authentication policy, applied at the environment group level and demonstrably active at runtime rather than merely recommended at build time, gives those organizations something concrete to show. It is the difference between telling an auditor that agents are supposed to require authentication and showing them a Power Platform admin center screen where that policy is actually configured and enforced.

What to Audit Before You Roll This Out

The rollout sequence matters more than the feature itself, and getting it backwards creates its own incident. The first step is the one the manufacturer’s CISO already took: get a current inventory of every agent in the tenant and its existing authentication setting, broken down by environment. Most organizations doing this for the first time are surprised by the count, and a meaningful share of that surprise usually comes from test or proof-of-concept agents that were never decommissioned rather than from production systems.

Once the inventory exists, the harder work is deciding environment group boundaries before applying policy, not after. An environment group that mixes internal line-of-business agents with a customer-facing Power Pages chatbot forces an uncomfortable compromise: either weaken the policy to accommodate the anonymous agent or break a legitimate public integration. Splitting those into separate environment groups first, then applying a strict Entra ID requirement to the internal group and an explicit, reviewed exception for the external one, is the pattern that avoids both outcomes.

It is also worth coordinating this rollout with whoever owns DLP policy in the organization, since the two controls now overlap in purpose even though they operate at different layers. A tenant-wide DLP restriction on unauthenticated connector usage and an environment-group-level authentication requirement can either reinforce each other or produce confusing, hard-to-diagnose failures if they are configured without reference to one another. Treating this as a single governance conversation, rather than two separate admin tickets handled by different people, avoids that outcome.

Finally, this is a good moment to revisit whichever Center of Excellence process the organization uses to track agent inventory and ownership, since an authentication policy is only as good as the organization’s ability to know when a new agent shows up outside of it. The policy catches misconfiguration. It does not catch an agent nobody knew existed until the inventory audit runs again.

The Practical Takeaway

None of this requires a large project to act on immediately. A first pass, an inventory of current agents and their authentication settings, a decision about which environment groups genuinely need anonymous access and which don’t, and a staged policy rollout starting with the highest-risk internal environment group, is realistic within a normal sprint or two for most Power Platform admin teams. What changes with this GA release is that the tool for enforcing the decision now exists natively, rather than requiring a workaround built from DLP policies never designed for this specific job.

Routeget Technologies has been walking clients through Copilot Studio governance reviews since well before this feature existed, largely because the underlying problem, agents accumulating faster than anyone tracks their authentication posture, predates any specific Microsoft release. The general availability of centralized agent authentication governance does not solve that problem by itself. It gives the teams already paying attention to it a real lever to pull, and it gives the teams who haven’t started yet a clear, specific reason to.

#CopilotStudio #PowerPlatformGovernance #AgentAuthentication #AIGovernance #EnterpriseAI #DataLossPrevention

Why Your AI Builder Default Model Keeps Changing Without Warning

An IT governance leader reviewing an AI model version timeline on a widescreen office display

A finance team at a mid-size distributor built a Power Automate flow eighteen months ago that reads incoming vendor contracts, pulls out payment terms and renewal clauses with an AI Builder prompt, and routes a short summary to the approver queue. The flow still runs every morning. Approvals still clear. Nobody who built the flow works there anymore, and nobody currently on the team could tell you which language model is actually answering the prompt today. It is not the one that answered it when the flow went live, and there was no meeting, no change ticket, and no line in a release note that told anyone it had changed.

That gap is not a one-off. It is how AI Builder’s generative AI prompts are designed to work, and it is worth understanding before the next swap happens rather than after a downstream process quietly starts behaving differently.

AI Builder’s prompt capability, the “Create text using a prompt” action available in Power Automate and Power Apps, runs on the same Prompt Builder infrastructure Microsoft also surfaces inside Copilot Studio. Unless a maker deliberately pins a specific model, every one of those prompts runs against the AI Builder default model, and Microsoft’s own documentation is explicit that this default is “periodically upgraded as new, more capable models become generally available.” The upgrade happens on Microsoft’s schedule, not the customer’s, and it happens without a change request landing on anyone’s desk.

Why the AI Builder default model keeps changing

The churn is not hypothetical. Microsoft’s published model availability record for Copilot Studio and AI Builder prompts shows GPT-4o and GPT-4o mini retired in July 2025, replaced by GPT-4.1 and GPT-4.1 mini. The o1 reasoning model retired the same month in favor of o3, which was itself retired on December 4, 2025 and replaced by GPT-5 reasoning. As of the current documentation, GPT-4.1 mini is the default model behind AI Builder prompts. Sitting just behind it in experimental status, available in limited regions ahead of a wider rollout, are GPT-5.3 chat, GPT-5.2 reasoning, Claude Sonnet 4.6, Claude Opus 4.6, and Grok 4.1 Fast. Experimental status is where every prior default model spent its final months before becoming the new standard, so this list is a reasonably good preview of what gets promoted next.

This is not even the first time the underlying mechanism itself has changed. The original AI Builder GPT feature, announced in December 2023 on GPT-3.5-Turbo, was itself deprecated in favor of the current Prompt Builder architecture. Teams that built early automation on that first action had to migrate the action type entirely, not just adjust to a new model version answering the same call. The lesson from that history is that the platform underneath these prompts has changed twice already, and there is no reason to assume it stops changing now.

Abstract illustration of glowing spheres arranged in a rotation cycle, representing AI model versions turning over

Thirty days is the entire window

When Microsoft promotes a new default, the model it replaces does not disappear immediately. Documentation for Copilot Studio confirms that a retired model stays usable for up to one month after retirement, and there is a setting, buried under an agent’s Settings page in the Model section, called “Continue using retired models,” that lets a maker keep running the outgoing version during that window while testing against the new one. It is a genuinely useful control. The problem is that it lives inside Copilot Studio’s authoring surface, and most of the people who built and now maintain a production flow in Power Automate or an app in Power Apps have never opened Copilot Studio at all. The setting exists. Whether the person responsible for a given prompt even knows to look for it is a separate question, and for most organizations right now, the honest answer is no.

The practical risk is not that the new model performs worse. Often it performs better on the metrics Microsoft optimizes for. The risk is that a model swap can shift output length, formatting, tone, or how confidently it phrases an uncertain answer, and none of that shows up as an error. A prompt that used to return a clean three-sentence summary might start returning five sentences with a caveat clause, and if a downstream Power Automate step parses that output into a fixed-width field or feeds it into a condition check, the flow keeps running successfully while quietly producing something different from what was tested and signed off.

What bring-your-own-model actually fixes, and where it does not

Microsoft’s answer to this is a real one: since September 15, 2025, AI Builder and Copilot Studio prompts have supported bringing your own model from Azure AI Foundry instead of relying on the shared default. An organization deploys its own model in its own Foundry resource, connects the deployment’s chat completion endpoint inside the prompt editor, and from that point forward it owns the version, the region, and the retirement timeline. Nobody upgrades it out from under them. For a prompt that feeds a regulated process, or one where consistent output structure genuinely matters, this is the correct fix, and it has been generally available for a full year.

It comes with two limits worth knowing before anyone builds a governance policy around it. First, a bring-your-own model connected through Prompt Builder can only be used inside prompt actions themselves. It cannot serve as the primary orchestration and planning model for a Copilot Studio agent, so it solves the AI Builder prompt problem specifically rather than every generative AI surface in the platform. Second, GPT-5-class models are not currently supported for bring-your-own connections at all. An organization that has already standardized its Azure AI Foundry deployments on GPT-5 cannot yet point an AI Builder prompt at that same deployment, which means the newest, often best-governed model choice is precisely the one this workaround does not yet cover.

There is also a licensing wrinkle that changes how a team should think about where a prompt lives in the first place. AI Builder credits are consumed when a prompt runs inside Power Apps or Power Automate, but the same prompt running inside Copilot Studio does not draw down those same credits. Two functionally identical prompts can carry meaningfully different cost profiles purely based on which product surface invokes them, which is easy to miss when a finance team is estimating consumption ahead of a rollout.

The governance moves worth making now

None of this requires a large program to address, but it does require someone to own it deliberately rather than let the platform default apply by omission. Start with an inventory of every production flow or app using a Prompt Builder action, and flag which ones are pinned to a specific model versus riding the default, since only the latter is exposed to the thirty-day retirement clock at all. For anything feeding a regulated, financial, or customer-facing process, evaluate whether bring-your-own-model through Azure AI Foundry is worth the setup cost given its current limits. At the environment level, the Power Platform admin center lets administrators disable the “Preview and experimental AI models” feature and lock that setting tenant-wide through environment group rules, which is a low-effort way to keep makers from quietly adopting an experimental model that has not been through any review. Because AI Builder sits inside the Dataverse connector for data loss prevention purposes, existing DLP boundaries already extend to prompt outputs, so that control is worth confirming rather than assuming.

The technology here is not the risk. A rolling default model, upgraded on a vendor’s schedule with a one-month grace period, is a reasonable design for a platform serving millions of makers. The risk is that most organizations have not assigned anyone to watch that clock. The AI Builder engagements Routeget gets pulled into to troubleshoot rarely trace back to a broken prompt. They trace back to a model decision nobody revisited since the day the flow was built, quietly drifting further from what the business actually validated.

#AIBuilder #PowerPlatformGovernance #CopilotStudio #AIModelGovernance #AzureAIFoundry #EnterpriseAI

Power Automate Error Handling: Why Your Approval Flows Fail Silently

IT professional reviewing a Power Automate approval workflow dashboard on a monitor in a modern office

A finance manager submits a purchase requisition through a Power Automate approval flow on a Friday afternoon. The flow’s run history shows a clean green checkmark. Nobody gets an error notification. Nobody gets paged. And nobody notices that the requisition is still sitting in “Waiting for approval” three weeks later, because the connection that created the flow belonged to an employee who left the company the same week the flow ran. The flow didn’t crash. It just stopped being able to reach the approver, and the default configuration had no mechanism to tell anyone that had happened. This is the gap that Power Automate error handling, done properly, is supposed to close, and it’s a gap that most approval flows in production today were never built to cover.

This is the failure mode that makes approval flows uniquely dangerous among Power Automate use cases. A malformed SharePoint update or a broken HTTP call to an external API tends to fail loudly and immediately, inside a run that someone is watching because they just triggered it. An approval flow fails quietly, often days or weeks after it started, to an audience that has already moved on to something else. Power Automate error handling for approval-heavy processes has to account for that gap between when something breaks and when a human would otherwise notice, and the out-of-the-box behavior of a cloud flow does very little to close it.

What Actually Breaks an Approval Flow

Before building an error-handling pattern, it helps to know what you’re actually defending against, because the failure modes for approvals are more specific than generic connector errors. Microsoft’s own troubleshooting documentation for flow approvals names two conditions directly tied to the connection that created the approval: ApprovalConnectionOwnerNotFoundInGraph, which fires when the account that owns the Approvals connection has been deleted from Microsoft Entra ID, and ApprovalConnectionOwnerNotEnabledInGraph, which fires when that account still exists but has been disabled. Both are common consequences of ordinary offboarding, and both will stop an approval flow cold with no warning to the requester or the intended approver.

A second cluster of failures involves timing. ActionTimedOut occurs when a “Wait for an approval” action’s configured timeout expires before a decision is made, and OperationTimedOut shows up on longer-running processes that exceed the platform’s maximum flow run duration of thirty days. Left at their defaults, many approval actions simply run until someone acts on them or the flow hits that ceiling, which means a request can sit unresolved for weeks without the flow itself ever reporting an error, because from the platform’s perspective nothing has technically gone wrong yet.

A third category sits at the connection layer more broadly: InvalidConnection and ConnectionAuthorizationFailed errors, which surface when a password reset, an expired OAuth token, or a Conditional Access policy change invalidates the credentials a flow depends on. Microsoft’s guidance on broken connections is blunt about the underlying cause, noting that connections tied to individual user accounts break whenever that account’s password changes or the account is disabled, which makes personal connections a structurally poor choice for anything running unattended in production.

Why Power Automate Error Handling Doesn’t Happen by Default

The reason none of this shows up as a visible incident is that Power Automate’s default run-after configuration only wires one path: continue if the previous action succeeded. There’s no branch for failure unless you explicitly add one, and there’s no notification unless you explicitly build it. A flow that fails at the approval step simply shows a red icon in a run history that, realistically, nobody is checking unless they already suspect something is wrong. For a process with dozens or hundreds of concurrent approval instances across an organization, that’s not a monitoring gap. It’s the absence of monitoring entirely.

This is precisely the situation Microsoft’s own coding guidance addresses through Run After configuration, and it’s worth treating as the non-negotiable baseline for any approval flow that matters to the business, not an optional hardening step reserved for critical systems.

Abstract illustration of a broken chain link being reconnected by gears, representing Power Automate error handling and recovery

Building the Scope-Based Try, Catch, Finally Pattern

The standard architecture for this, and the one Microsoft’s guidance points toward, wraps the core approval logic in three scopes. The first, a “Try” scope, contains the actual approval request, the wait, and whatever downstream actions execute once a decision comes back. The second, a “Catch” scope, is configured through Run After to execute when the Try scope has failed, has timed out, or was skipped, which are the three states that indicate something went wrong rather than simply concluded. Inside the Catch scope, the result() expression combined with a Filter Array action pulls the specific error code and message out of the failed action, which is what lets a notification say “the approval connection owner was removed from Entra ID” instead of a generic “something failed.”

A third scope, often labeled “Finally,” is configured to run after the Catch scope regardless of outcome, meaning after it has succeeded, failed, timed out, or been skipped. This is where cleanup and status logging belong, because it executes whether the Try scope worked cleanly or not, which keeps your audit trail complete instead of only recording the failure path.

For notification and logging, Microsoft’s guidance is explicit that Application Insights should be the default target rather than writing to a SharePoint list or a Dataverse table with a dedicated logging flow, both because it avoids the performance cost of excessive custom logging and because it consolidates monitoring across many flows into one queryable location instead of scattering it flow by flow. The workflow() function is useful here too, since it returns the run’s ID and environment metadata, which you can use to build a direct link to the failed run and drop it straight into a Teams message or an email to whoever owns the process.

Hardening the Approval Action Itself

Beyond the general try/catch pattern, approval actions specifically benefit from three adjustments that are easy to skip during initial flow design. First, set an explicit timeout on the “Wait for an approval” action rather than leaving it at the default, and pair that timeout with a Run After branch that fires on “has timed out.” That branch should escalate, typically to a backup approver, a manager one level up, or a distribution list, rather than simply notifying that the deadline passed and leaving the request unresolved. Second, configure retry policies on the connector actions surrounding the approval, using an exponential backoff pattern (an initial interval that doubles or triples with each attempt, up to a defined cap) so that transient throttling from Microsoft Graph or Dataverse doesn’t get treated the same as a permanent failure.

Third, and most important given how often it’s the actual root cause, move production approval flows off personal connections entirely. A connection reference paired with a service principal, rather than a connection tied to whoever happened to build the flow, means the flow keeps running when that person changes teams, resets a password, or leaves the company, which directly eliminates the ApprovalConnectionOwnerNotFoundInGraph and ApprovalConnectionOwnerNotEnabledInGraph failure modes described earlier. This is also an offboarding process question as much as a technical one: whoever manages user departures needs to know which production flows depend on that person’s connections before the account gets disabled, not after an approval silently stalls.

Testing Failure Paths on Purpose

None of this is verified until you’ve actually watched it fail. Before a flow goes into production, it’s worth deliberately breaking it: disable a test account that owns a connection and confirm the Catch scope actually catches it, set an artificially short approval timeout and confirm the escalation branch fires, and revoke a connection mid-run to see whether the resulting error surfaces somewhere a person will actually see it. Teams tend to build the happy path carefully and assume the failure path will behave the same way, which is rarely true the first time it’s tested. A flow checker pass and a clean test run through the approval itself tell you almost nothing about how the flow behaves once something upstream goes wrong, and that’s exactly the scenario a production approval process will eventually face.

The Takeaway

Approval flows fail differently than most other automation, because the cost of an undetected failure compounds silently while everyone assumes the process is working. The fix isn’t exotic: Run After branching, a Try/Catch/Finally scope structure, retry policies with backoff, connection references instead of personal accounts, and centralized logging through Application Insights. What it requires is treating error handling as part of the initial build rather than a patch applied after the first incident. At Routeget Technologies, the approval flows we get called in to fix almost never fail because the underlying logic was wrong. They fail because nobody built a path for the flow to tell anyone it had a problem.

#PowerAutomate #ApprovalWorkflows #FlowErrorHandling #ConnectionOwnership #PowerPlatformGovernance #EnterpriseAutomation

Dynamics 365 Service Agent Reached GA. Your Budget Approval Was for the Wrong Number.

A business technology leader reviews a customer service AI analytics dashboard on a large office monitor

A customer service VP at a mid-size distributor got budget sign-off in August for next year’s Dynamics 365 Customer Service renewal, including a line item for “AI capabilities” that her team had been piloting since spring. Then her IT director came back with a different number. Turning on Dynamics 365 Service Agent, the interactive AI layer Microsoft folded into Microsoft 365 Copilot this summer, wasn’t a checkbox inside the Customer Service license she’d already budgeted for. It was a second license, a consumption meter, and a rollout plan that touched roles, queues, and app modules she hadn’t scoped at all.

That gap between what leaders assume “enabling Copilot” costs and what it actually requires is becoming a recurring theme across the Dynamics 365 ecosystem, and Service Agent is a particularly clean example of it, because the feature itself is genuinely useful. The problem isn’t the capability. It’s that the licensing and governance model behind it doesn’t map cleanly onto how most organizations already budget for customer service technology.

What Dynamics 365 Service Agent Actually Does Differently

Dynamics 365 Customer Service has had AI-assisted features for a while: case summarization, suggested knowledge articles, sentiment flags. Service Agent, which reached general availability on June 30, 2026, is a different kind of thing. Microsoft describes the shift as moving from a tool that answers and summarizes to one that reasons and acts, and the distinction holds up in practice. Instead of surfacing a suggestion inside the Customer Service workspace, Service Agent operates through more than 90 Model Context Protocol tools that let a service representative, or a supervisor, update a case, reassign it, draft and send a reply, pull the next item from a queue, or generate a coaching note, all from inside Microsoft 365 Copilot itself. That means Teams, Outlook, and the Copilot chat surface, not just the Dynamics 365 application.

The practical effect is that a rep no longer has to open the Customer Service workspace to get value from the AI. A supervisor can ask Copilot in Teams for SLA exposure across a queue and get an answer grounded in live Dataverse case data, then reassign three at-risk cases without leaving the conversation. Microsoft’s own reference customer, Northern Trust, framed the change as moving from reactive search to proactive intelligence, which is a fair description of what changes when action, not just information, becomes available inside a chat interface.

That is a meaningfully different product than the Case Management Agent capability covered in this publication’s prior look at autonomous email resolution. That feature handles inbound email triage and resolution on its own, largely without a human in the loop for routine requests. Service Agent is closer to a force multiplier for people who are still doing the work, giving them a faster path to the same actions they’d otherwise take by clicking through the workspace. Both features draw on the same underlying AI infrastructure and the same consumption-based billing, which is exactly why they need to be budgeted together rather than as separate, unrelated line items.

The License Stack Nobody Scopes on the First Pass

Getting Service Agent in front of a customer service team requires three separate commercial commitments, and skipping any one of them stalls the rollout partway through.

The first is the Dynamics 365 Customer Service license itself, at Enterprise or Premium edition, which is what grants access to the underlying case data, knowledge base, and workflow engine that Service Agent reads from and writes to. Most organizations already have this if they’re running Customer Service at any scale, so it rarely surprises anyone.

The second is a Microsoft 365 Copilot license, and this is where the August budget conversation usually goes sideways. As of the licensing consolidation Microsoft rolled out in October 2025, the M365 Copilot license at thirty dollars per user per month now includes what used to require a separate twenty-dollar Copilot for Sales, Service, and Finance add-on on top of a fifty-dollar bundled SKU. That’s a genuine simplification from where the pricing sat a year earlier, but it doesn’t change the fact that every representative or supervisor who needs the integrated Service Agent experience, meaning access from Teams and Outlook rather than only inside the Dynamics 365 workspace, needs this license in addition to their Customer Service seat. For a fifty-person service organization, that’s an incremental cost that has to be modeled explicitly rather than assumed to already be covered by whatever Customer Service tier they’re on.

The third layer is consumption-based: Copilot Credits, which meter usage of the premium tools inside Service Agent’s toolset, on top of whatever is included in the base licenses. This requires a Power Platform pay-as-you-go plan with an attached Azure subscription, which in most enterprises means a separate procurement conversation with whoever owns the Azure relationship, not the team that owns the Dynamics 365 or Microsoft 365 contract. Organizations that have already gone through this exercise for the Case Management Agent’s autonomous email resolution feature have a head start, since the billing infrastructure is the same. Organizations tackling Service Agent as their first Copilot Credits commitment are effectively standing up a new procurement process from scratch, and that process alone can take longer than the technical rollout.

None of this is disclosed as a single number anywhere in Microsoft’s GA announcement, because it can’t be. Actual cost depends on how many representatives get the integrated experience versus a Customer-Service-only rollout, and how heavily premium tools get used once it’s live. That’s a reasonable design choice given how differently organizations will deploy this, but it means the budgeting exercise has to happen internally, with IT, finance, and the service organization in the same room, before a number goes to a steering committee.

Abstract illustration of stacked translucent layers representing tiered software licensing above a glowing customer service headset icon

Governance Controls That Make a Phased Rollout Realistic

The part of Service Agent’s design that deserves more credit than it gets is the rollout mechanism itself. Microsoft built in role-based access at three levels of granularity: per role, per application module, and per queue, and every one of those controls is reversible. That means an organization doesn’t have to choose between an all-or-nothing switch and doing nothing at all.

In practice, this supports a pilot pattern that’s more disciplined than what most AI rollouts get. A service leader can enable Service Agent for a single queue handling a well-understood, lower-risk category of requests, watch how representatives actually use the action-taking tools versus the summarization ones, and expand module by module rather than committing the entire service organization to an integrated experience on day one. Running the new experience side by side with the existing Customer Service workspace, rather than replacing it outright, gives teams a genuine off-ramp if adoption or accuracy doesn’t meet expectations in a given queue.

That control granularity is also what makes the licensing conversation tractable. Instead of asking “how many M365 Copilot licenses does the whole service organization need,” the real question becomes “which roles and queues justify the incremental license and credit consumption in phase one,” which is a much smaller number to defend to finance and a much easier one to revise later.

What to Settle Before the Next Budget Cycle

Before committing spend to a broader Service Agent rollout, it’s worth resolving three questions concretely rather than deferring them to the implementation team. First, determine how much license overlap already exists: any representatives who already hold M365 Copilot seats through other departments or through the Sales and Finance Copilot consolidation don’t need a second license, and that overlap can materially change the incremental cost. Second, get a real consumption estimate for Copilot Credits from a pilot queue before assuming what full deployment will cost, since usage patterns for action-taking tools tend to run higher than for pure summarization once representatives get comfortable with them. Third, decide who owns the Azure and Power Platform pay-as-you-go relationship before the rollout stalls waiting on a procurement approval that nobody flagged early enough.

Service Agent is a legitimate step forward for how customer service teams work inside Dynamics 365, and the reversible, granular rollout controls are a genuinely well-designed answer to the usual all-or-nothing AI adoption problem. The organizations that get the most value from it are the ones that treat the licensing stack as part of the technical evaluation from the start, not as a surprise that shows up after the pilot already has executive attention. That’s the pattern Routeget Technologies has seen repeatedly across Dynamics 365 AI rollouts: the technology rarely disappoints, but the budget conversation that should have happened in parallel with the pilot usually happens after it, and that sequencing is what turns a good capability into a frustrating procurement delay.

#ServiceAgentGA #CopilotLicensing #DynamicsCustomerService #CustomerServiceAI #CopilotCredits #ITBudgetPlanning

Business Central’s New Shopify Tax Matching Agent: What Confidence Levels Actually Tell You

Finance operations analyst reviewing a multi-state tax jurisdiction dashboard on a monitor

An integration consultant working a Shopify-to-Business-Central rollout will recognize this scenario immediately: an order comes through with sales tax already calculated at checkout, the sales order posts into Business Central, and three weeks later finance finds a jurisdiction mismatch during month-end reconciliation. Nobody did anything wrong. Shopify’s tax engine and Business Central’s tax engine simply disagreed about which jurisdiction, and which rate, applied to that ship-to address, and the native connector had no mechanism to catch that disagreement before posting. With Business Central 2026 release wave 2 (update 29.0), that changes. A new capability called the Tax Matching Agent enters public preview this month, with general availability set for October 2026 alongside the rest of update 29.0, giving technical teams a review checkpoint that has been missing from this integration since Microsoft first shipped it.

This piece looks at what the Tax Matching Agent actually reviews, what its confidence levels and rate differences mean in practice, and how it fits inside a broader set of Shopify connector changes landing in the same release that push the connector well past its original scope as a simple order-sync tool.

Why tax jurisdiction matching needed its own review step

Shopify calculates sales tax at checkout using its own nexus configuration and its own read of the customer’s shipping address. Business Central, when it creates the corresponding sales document, applies its own tax area and jurisdiction logic against that same address, through a separate calculation path, whether that path runs through Business Central’s built-in tax engine or a connected third-party service. The two were never designed to reconcile automatically. Most orders land on the same answer, since most addresses map cleanly to one unambiguous jurisdiction. The trouble shows up at the edges: marketplace facilitator states with their own filing rules, origin-versus-destination sourcing differences, home-rule jurisdictions layering municipal tax on top of state tax, and ship-to addresses that sit near a jurisdiction boundary. With no reconciliation step, those edge cases post silently and surface only when someone downstream, usually in accounting, notices the numbers don’t tie out.

That silent failure mode is really the problem the Tax Matching Agent solves. It isn’t that either system’s tax logic is wrong in some general sense. It’s that nobody was checking whether the two agreed, order by order, until now.

What the Tax Matching Agent actually does

Microsoft’s own description of the feature, as documented in the update 29.0 release notes, is precise about its scope: it lets a reviewer check suggested tax jurisdictions, confidence levels, and rate differences on a new Tax Match Review page before the sales document processes with sales tax. That phrasing matters. This is a pre-posting gate, not a background reconciliation job that fires after the fact and generates an exception report nobody reads until quarter close.

The design follows a pattern Business Central has already established with its other Copilot-based agents. The Payables Agent autonomously processes incoming vendor invoices and matches them to purchase orders, but it proposes posting accounts and flags routing exceptions for a human to resolve rather than posting blind. The Sales Order Agent handles incoming customer email requests and drafts a quote, but a person still reviews and sends it before anything commits. The Tax Matching Agent fits the same model: it does the comparison automatically, but the decision to accept a jurisdiction match, or override it, stays with the person reviewing the Tax Match Review page.

Confidence level and rate difference are the two pieces of information that page is built around, and they answer different questions. Confidence level reflects how closely the agent’s own jurisdiction assignment logic agrees with what Shopify calculated for that order, given the same ship-to and item data. Rate difference is the concrete dollar or percentage delta between the two calculations. A low confidence score with a near-zero rate difference is a very different situation from a high confidence score sitting next to a meaningful rate gap, and teams rolling this out should build their review workflow around that distinction rather than treating confidence level as a single pass or fail signal.

Part of a larger connector overhaul, not an isolated feature

The Tax Matching Agent didn’t ship alone. Update 29.0 adds four other Shopify connector capabilities in the same release, and understanding them together explains why the tax review step arrived when it did. Business Central now supports managing Shopify B2B companies, catalogs, and pricing directly, including mapping company tax identifiers and controlling price synchronization for whatever B2B capabilities a merchant’s Shopify plan includes. It adds handling for edited and exchanged Shopify orders, so changes and refunds on the Shopify side stay aligned with the sales documents already created in Business Central instead of drifting out of sync. It gives administrators explicit control over sales document creation, through Shopify Shop Card settings for order numbering and return processing, plus a contact review step before a sales document is created. And it adds tariff number and country-or-region-of-origin synchronization, through an HS Code and Country of Origin toggle on that same Shop Card, feeding into product synchronization tasks.

Abstract illustration of data flowing from an online storefront to an enterprise system through a validation checkpoint

Read alone, those four changes look like incremental connector maintenance. Read together with the Tax Matching Agent, they describe a connector being pushed past simple direct-to-consumer order capture and into territory that used to need a specialized middleware layer or a heavier custom build: B2B wholesale pricing, cross-border trade documentation, and multi-jurisdiction tax exposure. Each of those areas raises the stakes on getting tax right, which is presumably why the review agent landed in the same wave rather than as a standalone update later.

What technical teams should actually do with this

The preview window is worth using deliberately rather than skipping straight to general availability. Before update 29.0 reaches GA in October, teams running or planning a Shopify connector implementation should pull a sample of historical orders from exactly the jurisdictions known to be difficult: any home-rule state with meaningful order volume, ship-to addresses near a county or municipal boundary, and any state where marketplace facilitator rules changed how Shopify itself handles the calculation. Running those through the Tax Match Review page in preview, even manually, will say more about how the agent’s confidence scoring behaves than the release notes alone can.

It’s also worth being explicit about what this feature does not replace. If the organization already relies on a third-party tax determination engine, the Tax Matching Agent does not remove the need for that engine’s own jurisdiction and rate logic to be correctly configured. It adds a checkpoint between Shopify’s calculation and Business Central’s posting step; it does not become the tax engine itself. Treating it as a substitute for properly maintained tax setup, rather than a safeguard on top of it, is the surest way a team ends up disappointed after rollout.

The review process itself needs a threshold, not a habit of clicking through. A team that reviews every flagged order with equal scrutiny will either burn out and start rubber-stamping everything, defeating the point of the agent, or grind order processing to a crawl. A more workable approach sets a materiality threshold on rate difference, so small variances route to whoever normally processes sales orders, while anything above the threshold, or a persistently low confidence score from a specific jurisdiction, escalates to a tax specialist who can check whether the underlying nexus or tax area configuration needs correcting, rather than approving the same exception every time it appears.

One coordination point matters more than it might seem at first. Shopify’s tax and nexus settings are frequently owned by the e-commerce or marketing team, not finance or the ERP administrator, and a meaningful share of the mismatches this agent surfaces will likely trace back to Shopify-side configuration drift rather than anything wrong on the Business Central side. A feedback loop that gets a pattern of flags on the Tax Match Review page back to whoever manages the Shopify store’s tax settings, not just to the person clicking approve, is what turns this from a reporting tool into an actual fix.

The takeaway

The Tax Matching Agent doesn’t make the underlying tension between two independently calculated tax engines disappear, and Microsoft’s own preview disclaimer is a fair reminder that the exact behavior at GA could still shift before October. What it does is take a failure mode that used to stay invisible until reconciliation, or until an auditor asked an uncomfortable question, and put it in front of a person before the document posts. That visibility is usually worth more than automation would have been. The pattern holds across other e-commerce-to-ERP engagements we’ve worked: the tax gap was rarely a defect in either system so much as an unmanaged handoff between two logics that never talked to each other. The handoff finally has a checkpoint, and a technical team that uses the preview window to learn how it behaves in its own jurisdictions will be in a far better position than one that waits for GA and finds out the hard way.

#BusinessCentral #ShopifyIntegration #SalesTaxCompliance #ERPGovernance #DynamicsFinanceOps #EcommerceERP

Cross-Legal-Entity Fulfillment Enters Preview. Your Intercompany Setup Determines If It Works.

Operations team reviewing a network map dashboard showing warehouse fulfillment locations across a distributed retail supply chain

A retail operations director looks at a stalled online order and sees the maddening part immediately: the product is in stock, just not in the legal entity that took the sale. This happens constantly inside multi-entity retail and distribution organizations, the kind that grew by acquisition, by regional incorporation, or simply because tax and banking realities forced separate companies to hold separate inventory. To the customer, it looks like one brand. To Dynamics 365, it looks like several unrelated companies, each with its own stock ledger, unable to see past its own four walls without someone picking up a phone and negotiating a manual intercompany purchase order. Microsoft’s new cross-legal-entity fulfillment capability, built on top of Distributed Order Management (DOM), is aimed squarely at that gap. It reached private preview in version 10.0.48 this past August, with a public preview following in 10.0.49, and it is worth a serious look from any finance or operations leader running Dynamics 365 across more than one legal entity.

What Cross-Legal-Entity Fulfillment Actually Changes

DOM itself is not new. Dynamics 365 Commerce has used it for years to solve a narrower version of this problem: given an order and a set of warehouses inside a single legal entity, which location should fulfill it, based on inventory availability, distance to the customer, and cost. The new capability extends that same logic across company boundaries. DOM can now evaluate inventory sitting in a different legal entity entirely, and when it decides that location is the right one to fulfill from, it does not just flag the mismatch for someone to sort out manually. It automatically builds the full intercompany transaction chain: an intercompany purchase order in the entity that took the original sale, and a matching intercompany sales order in the entity actually holding the stock, synchronized so that when the fulfilling entity ships, both records update and the customer’s original order closes out correctly. For an organization that has been handling these situations with a spreadsheet and a Teams message between two warehouse managers, that is a real reduction in manual work, not just a marginal one.

The business case writes itself on the inventory side. Stock that would otherwise sit idle in one entity while a nearly identical order goes unfulfilled, or gets backordered, in another becomes usable. Organizations running regional legal entities for tax or regulatory reasons, but operating as one brand commercially, finally get a fulfillment engine that reflects how customers actually experience the business rather than how the org chart is drawn.

The mechanics matter just as much when things do not go according to plan. If a fulfilling entity cannot complete an order, whether because inventory shifted after DOM made its decision or a warehouse simply declines the assignment, DOM does not leave the order stranded. It marks the line rejected and attempts reassignment on its next scheduled run, first to another location within the same entity, then to a warehouse in a different one entirely. Partial fulfillment works the same way: if a location can only ship part of an order, the shortfall carries through the intercompany chain, and DOM can reassign the remainder on a later pass. For an operations leader weighing this against the status quo, that built-in retry logic is arguably as valuable as the initial sourcing decision, since it replaces exception handling that used to depend on someone noticing the problem before anyone could fix it.

The Setup Cost Nobody Puts in the Feature Announcement

None of this activates by flipping a single switch, and the gap between the headline and the configuration work is exactly where evaluation projects go wrong. The prerequisite that will consume the most calendar time is intercompany trading relationships. For every pair of legal entities that should be able to fulfill for each other, someone has to create and link a customer record in the selling entity and a vendor record in the fulfilling entity, then configure both for automatic intercompany order creation. With two entities that is a manageable afternoon of setup. With eight or ten, which is not an unusual footprint for a company that has grown through acquisition, the number of pairs that need configuring grows fast, and each one typically touches both an accounts payable and an accounts receivable process owner who may not have been in the room when this project got approved.

Beyond that, three technical dependencies are easy to miss until a pilot stalls on them. First, the DOM solver has to be set to Production Solver rather than Simplified Solver, because the simplified option cannot create intercompany orders at all, a detail that only surfaces after someone has already built out fulfillment groups and rules under the wrong configuration. Second, Azure Maps has to be enabled and licensed, because DOM uses it to calculate real distances between warehouses and delivery addresses when deciding which entity should fulfill an order, and that is a dependency an IT team evaluating this purely as an ERP feature might not budget for. Third, and most consequential for a phased rollout, every legal entity that should participate has to be explicitly added to the DOM fulfillment profile. Miss one, and DOM will not simply deprioritize its locations, it will not see them at all, which makes partial or staged rollouts across a large entity footprint riskier to get right the first time than the documentation implies.

Abstract illustration of warehouse facilities connected by a glowing digital inventory routing network

What’s Actually in Scope Today

It is worth being precise about where this feature currently draws the line, because a preview capability evaluated against the wrong assumptions leads to a rollout plan that has to be rewritten in six months. As of this preview, cross-legal-entity fulfillment covers retail order channels only: point of sale, e-commerce, call center, and headless Commerce Scale Unit orders. Sales orders originated directly in Supply Chain Management sit outside this scope for now. Microsoft has said SCM order support is on the roadmap, but roadmap language in a preview announcement is explicitly not a delivery commitment, and organizations that need cross-entity logic for B2B or wholesale sales orders processed natively in SCM should not build a 2027 plan around a capability that has not shipped yet.

The preview status itself carries the same caveat every Dynamics 365 preview does, and it is worth repeating because it gets skipped over in internal pitch decks more often than it should: preview features are for evaluation, are subject to change, and Microsoft’s own documentation is explicit that timing and functionality should not factor into purchasing decisions. Private preview in 10.0.48 moving to public preview in 10.0.49 is a normal, healthy cadence, not a signal that general availability is imminent.

How to Evaluate This Before You Pilot It

For a finance or operations leader deciding whether this belongs on next year’s roadmap, the useful first step is not a technical proof of concept. It is an honest audit of how complete the organization’s existing intercompany trading setup already is. Companies that have already done the work of linking customer and vendor records across their legal entities for other intercompany scenarios will find the DOM-specific configuration, the vendor mapping, fulfillment groups, and rules, relatively fast to layer on top. Companies where intercompany trade has been handled ad hoc, entity by entity, as problems came up, should expect the trading relationship setup itself to be the majority of the project timeline, not the DOM configuration.

It is also worth involving accounts payable and accounts receivable process owners earlier than a typical fulfillment feature would require, since this changes the volume and pattern of intercompany transactions those teams reconcile every period. A pilot scoped to a single, well-understood pair of legal entities, run alongside the existing manual process rather than replacing it immediately, gives a much clearer read on actual fulfillment savings and reconciliation impact than a broad rollout attempted on day one of public preview.

Cross-legal-entity fulfillment addresses a real and common operational gap, and the underlying DOM engine it builds on is mature technology, not an experimental one. The preview label applies to the cross-entity orchestration layer, not to order fulfillment optimization itself. Routeget Technologies has walked a number of multi-entity clients through intercompany trade configuration for other reasons, and the pattern holds here too: the technology adoption timeline is rarely the bottleneck. The completeness of the underlying intercompany setup is.

#DistributedOrderManagement #Dynamics365SCM #IntercompanyFulfillment #OmnichannelFulfillment #SupplyChainAutomation

The Dataverse Git Integration GitHub Preview Needs a Key Vault, Not Just a Login

An IT solutions architect presenting a software deployment pipeline diagram on a large office monitor

A Power Platform ALM engineer at a mid-market manufacturer spent a Tuesday afternoon trying to move a client’s Dataverse Git integration off Azure DevOps and onto GitHub, where the rest of the company’s engineering org already lived. The Azure DevOps connection had taken fifteen minutes to set up the year before: sign in, pick a project, pick a repository, done. She assumed GitHub would be the same flow with a different login screen. Four hours, one Azure Key Vault resource, one GitHub App registration, and one role assignment to a service principal she’d never heard of later, she had a working connection, and a much clearer idea of why Microsoft shipped Azure DevOps support first.

That gap between expectation and reality is worth understanding before any team commits to the GitHub option, because it is not a bug or an oversight. It reflects a real architectural difference in how the two providers authenticate, and it changes the planning and staffing conversation for anyone treating this as a same-day migration.

An IT solutions architect presenting a software deployment pipeline diagram on a large office monitor

What Dataverse Git integration actually does

Dataverse Git integration is Microsoft’s native, in-product answer to a problem that Power Platform teams have patched around for years: getting solution components out of an environment and into a real source control history without standing up a full pro-dev toolchain. Instead of relying solely on the Power Platform CLI, Azure Pipelines, and a developer’s local machine to export, unpack, and commit solution XML, makers and admins can now connect an unmanaged solution directly to a Git repository from inside make.powerapps.com, commit changes as they’re made, and let Power Platform Pipelines handle promotion to test and production from there.

The mechanics matter because they explain the limits. Only unmanaged solutions in development environments connect to Git; managed solutions still move downstream through Power Platform Pipelines, not through branch merges. Component changes sync to a human-readable, YAML-based file format designed to diff cleanly, a deliberate departure from the sprawling XML that classic solution exports produce. And a full solution commit is atomic: you cannot cherry-pick individual component changes within a solution the way you would stage individual files in a typical Git workflow. Teams coming from a code-first background, expecting Git semantics all the way down, tend to hit that ceiling first.

Azure DevOps was the first provider Microsoft supported, and it reached general availability well ahead of GitHub. The connection setup leans on infrastructure Azure DevOps and Dataverse already share inside the same Microsoft Entra tenant: create a project with Git version control enabled, confirm the connecting user has Contributor access to the repository, enable managed environments on both the source and target environments, and connect from the solution’s source control panel. There is no separate secrets store to provision and no custom application registration required, because the trust relationship rides on existing Azure identity.

Why the GitHub path looks different

GitHub support entered public preview in the 2026 release wave 1 cycle, and the setup reflects the fact that GitHub sits outside the Azure AD trust boundary that made the Azure DevOps connection comparatively simple. Rather than a native OAuth handshake alone, the documented path requires registering a dedicated GitHub App under organization settings, granting it read-and-write access to repository contents, generating a private key for that app, and then storing that key somewhere Dataverse can retrieve it securely. That somewhere is Azure Key Vault, in the same Microsoft Entra tenant as the Dataverse environment, which means a team without an existing Key Vault footprint is now standing one up specifically to support source control.

Abstract illustration of a secure vault connected to a code repository network and a cloud identity shield, representing credential management between GitHub and Dataverse

The chain continues from there. After the private key lands in Key Vault, the environment’s own managed identity, provisioned automatically as something like PPMI-githubappconfigmanagedidentity followed by a GUID, needs the Key Vault Crypto User role assigned to it through Key Vault’s access control settings before Dataverse can actually use the stored credential. Only after that RBAC assignment resolves does the GitHub connection in the solution’s source control panel have what it needs to authenticate. None of this is exposed as a single wizard; it’s a sequence across GitHub’s developer settings, the Power Apps maker portal’s Connections page, and the Azure portal, and a missed step in any of the three stops the whole chain cold with a generic authentication failure that doesn’t point back to which link broke.

Two additional constraints are worth flagging before a team plans around this path. GitHub-based connections are not currently compatible with Dataverse environments that have virtual network support enabled; if VNET injection is part of your environment’s security posture, the documented workaround is a GitHub personal access token instead of the OAuth connection, which trades one credential management problem for another. And if the organization has restrictions on third-party OAuth application access, which many regulated enterprises do by default, an org admin has to explicitly approve the GitHub App before any maker can complete the connection, adding an approval-queue dependency that Azure DevOps setups don’t carry.

Planning the rollout instead of the demo

None of this makes the GitHub option a bad choice. For an organization that has already centralized its application source, its pull request review culture, and its CI/CD runners around GitHub, keeping Power Platform solutions in a second, Azure DevOps-only silo creates its own governance problem: two source control systems, two access review processes, two places an auditor has to look. The GitHub preview closes that gap. It just closes it with real infrastructure work attached, not a checkbox.

Two prerequisites tend to get discovered late rather than planned for. Managed environments must be enabled on every environment in the chain, development and target alike, and that entitlement itself is included at no extra cost with standard Power Apps, Power Automate, Copilot Studio, Power Pages, and Dynamics 365 licenses, but explicitly excluded from the Developer Plan. A team piloting this in a free developer environment will hit a wall before they hit the GitHub App registration screen. Second, this is explicitly documented as a preview capability intended for development environments only, not test or production, so any rollout plan that assumes it is production-ready today is planning against documentation that says otherwise.

The practical sequencing that avoids the four-hour surprise looks like this: confirm managed environments are already enabled or budgeted for, decide up front whether VNET requirements in any target environment rule out the OAuth path in favor of a PAT, and treat the GitHub App registration, Key Vault provisioning, and managed identity role assignment as three discrete, ownable tasks rather than one setup step, ideally assigned to whoever already owns Key Vault and Entra app registrations in the organization rather than the Power Platform maker who happens to be doing the connecting. Teams that scope it that way tend to get through it in an afternoon. Teams that treat it like the Azure DevOps flow tend to get the same four-hour afternoon the engineer in the opening scenario had, just with more frustration attached.

Routeget Technologies has walked several clients through exactly this kind of ALM tooling decision, usually as part of a broader review of where Power Platform governance sits relative to the rest of an organization’s engineering practices. The right answer isn’t universally GitHub or universally Azure DevOps; it’s whichever one matches where the organization’s source of truth already lives, evaluated with the actual setup cost in view rather than the marketing description of “now supports GitHub.”

For architects scoping this now, the preview label matters less than the identity and secrets infrastructure it assumes you’re willing to stand up. If that infrastructure already exists in your tenant, the GitHub path is a reasonable few hours of work. If it doesn’t, budget for building it before you budget for the migration itself.

#DataverseGitIntegration #PowerPlatformALM #GitHubIntegration #EnterpriseDevOps #ITGovernance #PowerPlatform

Microsoft Agent 365 Governance Is GA. Is Your Copilot Studio Fleet Ready?

IT director reviewing an AI agent governance dashboard on a large office monitor

When a mid-market manufacturer’s IT Director asked her Power Platform administrators for a simple headcount this spring, how many Copilot Studio agents actually exist across the organization, the answer took three weeks to assemble and still arrived with an asterisk. Some agents had been built by finance analysts using maker licenses nobody remembered granting. A handful had default connections into Dataverse tables holding customer payment history. Nobody could say with confidence who owned any of them once the person who originally built them changed teams or left the company. That scramble is becoming a familiar story across Dynamics 365 and Power Platform shops, and it is exactly why Microsoft Agent 365 governance has become a live budget conversation since the platform reached general availability on May 1, 2026.

IT director reviewing an AI agent governance dashboard on a large office monitor

Agent 365 is Microsoft’s control plane for observing, governing, and securing AI agents across an enterprise, regardless of where those agents were built. It applies to prebuilt Microsoft 365 Copilot agents, agents built in Microsoft Foundry, and, most relevant to this audience, agents built in Copilot Studio. For IT Directors and CIOs who have spent the last eighteen months watching Copilot Studio adoption spread from a handful of IT-sanctioned bots into dozens of business-unit-built agents, Agent 365 is the first serious attempt at a single inventory and policy layer that sits over all of it. Whether it is worth the licensing commitment depends less on the feature list and more on how much organizational work a rollout actually requires, which is the part vendor briefings tend to gloss over.

What Agent 365 governance actually covers

The platform’s job splits into three functions: observing agent activity across apps, endpoints, and cloud services; governing agents through policy-based controls and lifecycle management, meaning admins can install, publish, block, or reassign ownership of an agent directly from a central registry; and securing agents against threats such as over-privileged actions or misuse of connected data sources. Microsoft Defender now assesses the security posture of Foundry and Copilot Studio agents specifically, flagging risky configurations, including agents wired up to Model Context Protocol tools that could open a path to privilege escalation, and surfacing prioritized recommendations rather than a raw vulnerability dump.

The governance layer also introduces a formal approval and publication flow. Before an agent built in Copilot Studio reaches end users, an admin can review its data access, permissions, and security posture from the registry, rather than relying on the maker’s own judgment about what the agent should be allowed to touch. For any IT Director who has inherited a Copilot Studio environment where publication controls were an afterthought, this is the feature that closes the gap between having a data loss prevention policy on paper and actually enforcing it before an agent goes live.

One capability worth flagging separately is shadow AI discovery. Agent 365 uses Microsoft Defender and Intune to identify locally running agents on Windows endpoints that were never provisioned through any sanctioned platform. At GA, this covers agents built on the OpenClaw framework, with support for GitHub Copilot CLI and Claude Code agents promised to follow. It is a genuinely new capability, since most governance conversations to date have focused on what happens inside Copilot Studio or Power Platform, not on the coding agents developers are quietly running on their own laptops. That said, it is worth treating Microsoft’s framing of how widespread this problem actually is with some skepticism. The prevalence figures behind the “agent sprawl” narrative are Microsoft’s own positioning, and no independent study has confirmed how common unmanaged local agents really are on a typical enterprise fleet. Before budgeting for this specific control, it is reasonable to ask your own security team whether they have actually observed it as a problem.

The licensing math is per person, not per agent

Agent 365 is priced at $15 per user per month as a standalone add-on, or bundled at no additional cost inside Microsoft 365 E7, which lists at $99 per user per month and also includes the Entra Suite. The billing model is worth understanding precisely: one Agent 365 license covers every agent that person owns, sponsors, manages, or interacts with, so deploying more agents does not by itself increase the license count. You are licensing the humans accountable for agents, not the agents themselves, which is a more forgiving model than the per-seat-per-bot pricing some competitors use.

The complication is prerequisites. As of June 1, 2026, Agent 365 requires a specific underlying license foundation: Microsoft 365 E5 on its own, or E3 combined with both the Defender and Purview suites, with equivalent tiers defined for frontline, SMB, and education licensing. For an organization still running E3 without the add-on security suites, the real cost of Agent 365 is not the $15 line item. It is the E5 upgrade, or the Defender and Purview additions, that have to happen first. Run the math both ways before presenting a number to finance: E5 plus Copilot plus Agent 365 lands around $105 per user, while E7 covers the same ground at $99. For organizations already leaning toward E5 or E7 for other reasons, Agent 365 is close to free. For organizations still on E3, it is a licensing tier change dressed up as a governance purchase, and that distinction changes who needs to sign off on it.

Abstract illustration of a network of AI agents protected within a security shield, representing agent governance

Governance is an operating model, not a toggle

Microsoft’s own internal rollout, described in its IT organization’s implementation notes, is the most useful data point for what a realistic deployment looks like. Microsoft Digital currently manages more than 500,000 agents across its environment, and the team is candid that its operating model is still incomplete. Their starting point was not turning on policy enforcement. It was building an accurate, centralized inventory, capturing each agent’s name, lifecycle status, type, ID, owner, creation platform, and where it is actually used, with the registry auto-ingesting metadata from Copilot Studio, Power Platform, SharePoint, and Azure AI Foundry.

Just as significant is the administrative structure Microsoft settled on. Rather than assigning agent governance to a single owner, the organization split responsibility across an AI administrator role overseeing the full tenant inventory and lifecycle, an Agent Identity administrator managing identities through Entra Agent ID, and security and compliance teams defining the actual guardrails and approval thresholds. Internally, Microsoft describes agent governance as needing a cross-functional weekly rhythm among IT, security, identity, product, and business unit stakeholders, framing it explicitly as a team sport rather than a single admin’s checklist. Notably, the company also acknowledges that much of its own approval and escalation workflow is still manual, and that programmatic automation is an ongoing engineering effort rather than something that ships finished on day one.

For a CIO evaluating Agent 365, the practical takeaway is to separate the licensing decision from the operating model decision. The license question is a spreadsheet exercise: check your current Microsoft 365 tier against the June 2026 prerequisite list, and compare standalone Agent 365 pricing against an E7 upgrade if you are close to that threshold anyway. The operating model question is harder and cannot be solved by procurement. It requires naming an accountable owner for the agent inventory, deciding who plays the Agent Identity administrator role, and establishing the recurring cross-team review Microsoft itself says was the actual unlock, before the count of Copilot Studio agents in your tenant grows past the point where anyone can govern it from memory.

Routeget Technologies has walked several Dynamics 365 and Power Platform clients through exactly this kind of governance stand-up, usually starting with the same inventory exercise that surprised the IT Director in the opening example. The tooling question tends to resolve quickly once the organizational one is answered honestly.

#Agent365 #CopilotStudio #AIGovernance #ShadowAI #AgenticAI #EnterpriseAI