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

Power Automate’s Object-Centric Process Mining Is GA. Your Bottleneck Data Still Needs a Pipeline First.

A finance operations leader reviewing a process mining dashboard showing connected order, invoice, and payment flows

A finance operations director running Dynamics 365 Finance and Operations recently walked into a budget review with a straightforward automation pitch: build Power Automate flows to shorten the order-to-cash cycle. The CFO’s response was less straightforward. Before funding new flows, she wanted proof of where the cycle actually breaks down, not an assumption based on which team complains loudest. That question, where is the process actually stalling and why, is precisely what Microsoft’s object-centric process mining capability in Power Automate was built to answer. It reached general availability on June 5, 2026, and it changes what a process mining exercise can tell a finance or operations leader. It also comes with a data engineering requirement that most teams have not budgeted for yet.

A finance operations leader reviewing a process mining dashboard showing connected order, invoice, and payment flows

Why Case-Centric Process Mining Kept Missing the Real Bottleneck

Power Automate has offered process mining for several years, and Dynamics 365 Supply Chain Management customers on version 10.0.35 and later already have a purpose-built entry point: a warehouse material movement analysis template that reads closed warehouse work records straight out of Dataverse, no custom configuration required. That capability is genuinely useful, and it works because it treats a process as a single, well-defined case, such as one warehouse work order moving through a fixed sequence of steps.

The limitation shows up the moment a process stops being a clean sequence. An order-to-cash cycle is not one case moving through one lane. A single sales order can spawn multiple shipments, each shipment can be tied to more than one invoice, and a payment can settle across several invoices at once. Traditional case-centric mining forces all of that into one case identifier, which means analysts either duplicate events across cases to preserve accuracy, or they flatten the relationships and lose the very dependency that caused the delay. Microsoft’s own framing of the problem is direct: a shipment held up because an unrelated invoice on the same customer account went unpaid is exactly the kind of cross-object dependency that a single-case view cannot represent cleanly. Object-centric process mining, or OCPM, is built to keep orders, invoices, payments, and shipments as separate but linked object types within one process map, so an analyst can see where those flows intersect and where the actual delay originates.

What Object-Centric Process Mining Changes Once It’s Running

The practical difference for a finance or supply chain leader is that root cause analysis stops requiring a manual reconciliation project. Instead of pulling separate reports for orders, accounts receivable, and logistics and asking an analyst to manually trace where they intersect, OCPM keeps those relationships intact in the underlying data model from the start. Microsoft describes the intended outcome as compressing root cause investigations that used to take weeks down to hours, along with the more familiar benefits of shorter cycle times, lower operational cost, and better resource utilization once the actual constraint is identified rather than guessed at.

For a CFO evaluating where to spend the next automation budget, that matters more than it might first appear. A process improvement initiative built on a flattened, case-centric view risks automating the wrong step: speeding up invoice approval, for instance, when the true constraint is a shipment reconciliation process three steps downstream that only becomes visible once orders, invoices, and shipments are analyzed together. Object-centric process mining is designed to surface that kind of hidden dependency before a Power Automate build begins, which is a materially better position than discovering it after a flow has already been deployed and the expected cycle-time improvement doesn’t show up.

An abstract illustration of connected order, invoice, and payment objects intersecting in a process map

The Data Pipeline Nobody Is Budgeting For

Here is the part that tends to get skipped in the pitch. The Dataverse-native warehouse analysis template mentioned earlier works because case-centric process mining can read Dataverse tables directly. Object-centric process mining, as it stands today, does not offer that same direct connection to Dataverse or to Dynamics 365 tables. It ingests data as a CSV file structured according to Microsoft’s object-centric event log, or OCEL, format, stored in either Azure Data Lake Gen2 or OneLake. Fabric Lakehouses with schema support enabled are explicitly not yet supported as a source, which rules out one path some teams might assume would work.

Building that OCEL file is not a trivial export. The mapping step requires at least one activity attribute, at least one start event attribute, and at least two object type attributes, with optional end event, resource, and additional event or object-level attributes layered on for richer analysis. In practice, that means someone, whether an internal analytics team or an implementation partner, needs to design an extraction and transformation process that pulls order, invoice, payment, and shipment events out of Dynamics 365 and Dataverse, aligns them to a shared activity and object model, and lands the result as a correctly structured CSV before OCPM can analyze anything. That is a real data engineering task, and it is separate from, and in addition to, the Power Automate Premium licensing already required to use process mining at all.

What the Licensing Actually Covers

On the cost side, process and task mining are bundled into the Power Automate Premium per-user license, which includes both capabilities along with a starting capacity pool: each licensed user contributes 50 MB toward a shared tenant-wide limit that caps at 100 GB. Organizations that outgrow that pool can add the Power Automate Process Mining add-on, priced at the tenant level, which adds another 100 GB of process mining capacity along with additional Dataverse database and file storage. Customizing the reporting layer against your own Power BI workspace requires a separate Power BI Premium license. None of that licensing changes because a team chooses object-centric analysis over case-centric analysis, which means the incremental cost of adopting OCPM is almost entirely the data pipeline work, not the software itself.

What’s Coming That Should Factor Into Timing

Two features on Microsoft’s own roadmap are worth factoring into a rollout decision rather than treating OCPM as a finished, static capability. Support for exporting object-centric process mining data to a Microsoft Fabric semantic model is planned for August 2026, which would let this data flow into existing Power BI and Fabric reporting rather than staying siloed inside the process mining tool itself. Normalized schema import support for data ingestion, also targeted for August 2026, is intended to ease some of the current data preparation burden, though it has not been detailed in enough depth yet to know how much of the CSV construction work it actually removes. A broader Process Intelligence Studio experience is set to preview in September 2026 and reach general availability the following month, consolidating process mining, task mining, and related analysis into a single workspace. Teams weighing whether to invest in the manual OCEL pipeline now versus waiting a quarter for these dependencies to mature have a legitimate reason to ask that question before committing engineering time.

Where This Leaves a Decision-Maker Today

None of this argues against object-centric process mining. It argues for treating it as what it is: a genuinely more accurate way to see how a multi-object process like order-to-cash or procure-to-pay actually behaves, paired with a data preparation cost that is easy to underestimate when the feature is pitched as simply “available now.” Before funding an OCPM initiative, it is worth confirming which specific cross-object process is causing the most cost or delay, whether that process’s underlying data already exists in a form close to the OCEL structure or will require meaningful transformation work, and whether waiting for the Fabric export and normalized schema import features changes the math on doing this now versus later this year. Routeget Technologies has walked several Dynamics 365 clients through exactly this kind of data readiness assessment before committing to a process mining build, and the pattern holds consistently: the mining tool itself is rarely the bottleneck. The data getting to it is.

#PowerAutomate #ProcessMining #AutomationROI #OrderToCash #DataverseIntegration #PowerPlatform

The Dynamics 365 Sales MCP Server Isn’t the Whole Picture

Solution architect reviewing a Dynamics 365 Sales AI agent integration architecture diagram on a monitor

A solution architect on a recent Dynamics 365 Sales engagement did what the documentation told him to do: he pointed a GitHub Copilot session in VS Code at the newly GA’d Dynamics 365 Sales MCP server, asked it to pull up a stalled opportunity, and watched it come back with a clean summary and a suggested outreach email. Then he asked it to update the opportunity’s close date. Nothing happened. No error, no record change, just a polite explanation that the tool wasn’t available. He had connected the right server. He just hadn’t connected both of them.

That gap trips up more than one team standing up agent access to Dynamics 365 Sales for the first time, because the Dynamics 365 Sales MCP server, which reached general availability in February 2026 after a preview that started in mid-2025, was never designed to be the only door into the system. It is a purpose-built layer that exposes a narrow set of sales-specific actions: retrieving a lead summary, qualifying a lead into an opportunity, generating an outreach email, listing leads assigned to a seller. Anything that looks like ordinary create, read, update, or delete work against Dataverse records sits behind a separate, general-purpose Dataverse MCP server. Architecting AI access to Sales properly means treating these as two components of one system, not as interchangeable options.

What the Dynamics 365 Sales MCP server actually exposes

The Sales MCP server groups its tools into three functional clusters that mirror existing Copilot experiences inside the app: Sales Qualification Agent tools, Sales Opportunity Agent tools, and the broader Copilot in Sales tool set. In practice this means an MCP client authenticated against this server can list a seller’s leads, pull a structured summary of a specific lead or opportunity, move a qualified lead into an opportunity record, and draft or send an outreach email using the same generative logic that powers Copilot inside the Sales workspace. These are opinionated, workflow-shaped actions. They encode the same business rules a seller would hit clicking through the UI, which is exactly the point: an external agent gets sales-process guardrails for free instead of raw table access.

What it deliberately does not expose is a general write path. There is no “update any field on any opportunity” tool here, and that is not an oversight so much as a design choice that keeps the blast radius of an agent request contained to well-understood sales actions.

Where Dataverse MCP fills the gap

For anything outside that workflow shape, whether it’s a custom Power Apps process reading a related quote table or an agent that needs to write directly to a Dataverse entity, the connection point is the separate Dataverse MCP server, reachable at https://<OrgURL>/api/mcp. It exposes four core operations: read_query, create_record, update_record, and describe, the last of which lets a client inspect table and column schema before it attempts a write, which matters a great deal in a Dataverse environment where customizations can mean the “standard” schema an agent expects has drifted from what is actually deployed.

One detail worth building into any design review: the Dataverse MCP server is enabled by default for Microsoft Copilot Studio but disabled by default for every other client. If a team is connecting GitHub Copilot, a custom agent, or any third-party MCP-compliant tool, an admin has to go into the Power Platform admin center, open the target environment’s Settings, navigate to Product > Features, and turn on “Allow MCP clients to interact with Dataverse MCP server,” then explicitly allow-list each client under Advanced Settings. Nothing connects by accident, which is a reasonable default for a capability that can write to production data, but it also means a “why isn’t this working” support call is often really a “did anyone flip this switch” question.

Abstract illustration of two connected server nodes representing the Sales MCP server and Dataverse MCP server architecture

Configuring both servers side by side

For a VS Code or other mcp.json-driven client, the practical setup is two separate server entries pointed at two different endpoints rather than a single unified connection string. The Sales server entry targets the Agent 365 service path scoped to the environment and the Sales MCP server registration, something like https://agent365.svc.cloud.microsoft/mcp/environments/<EnvironmentID>/servers/msdyn_SalesMCPServer, while the Dataverse entry targets the organization’s own API surface directly. Both are declared as HTTP-type MCP servers. Getting an agent to feel like it has coherent access to “Dynamics 365 Sales” as a single system is really a matter of configuring both endpoints correctly and letting the client route each request to the appropriate one, which most MCP-aware clients handle transparently once both connections are live.

It’s worth noting explicitly for architects scoping this work that Claude Desktop is not on Microsoft’s list of supported clients for the Sales MCP server as of this writing; Copilot Studio, GitHub Copilot in VS Code, and other MCP-compliant clients are. That’s a constraint worth confirming before a client commitment gets made in a statement of work.

Security enforcement isn’t a separate layer, it’s the same one

The question every security-conscious stakeholder asks first is whether an AI agent connected through MCP can see or touch more than the person who authorized it could. Microsoft’s own documentation is direct on this point: the Dataverse MCP server respects existing Dataverse security roles and row-level security, meaning a connected agent can only access the tables and records that the authenticated user’s security role already permits. There is no parallel permission model to reason about, no separate access control list to maintain for agent traffic. The security model an organization has already built for its human users through business unit hierarchies, field-level security, and role-based table access extends automatically to MCP-connected agents acting on that user’s behalf. That’s a meaningfully simpler governance story than a lot of teams expect walking into this, and it’s worth stating plainly to a CISO who assumes agent access requires a whole new access-control project.

What isn’t yet documented in detail is rate limiting or granular audit logging specific to MCP calls, and that’s a fair gap to flag rather than paper over. Teams putting this into production should validate logging behavior in their own tenant and treat detailed throttling behavior as something to test empirically rather than something to design around from a published number that doesn’t exist yet.

The licensing detail that changes the cost conversation

Since December 15, 2025, Dataverse MCP tool calls made by AI agents built outside Microsoft Copilot Studio are billed against Copilot credits, unless the organization already holds qualifying Dynamics 365 Premium licensing or a Microsoft 365 Copilot User Subscription License, in which case that usage is included. Agents built inside Copilot Studio are exempt from this particular charge model. The Sales MCP server has its own credit consumption structure layered on top, with different tool categories, such as basic text and generative AI tools versus generative answer tools, billed at different Copilot Studio credit rates. For an architecture that mixes a Copilot Studio-native agent with a custom VS Code-based developer tool hitting the same environment, that means two different cost models are running in parallel, and a licensing conversation that used to be a single line item now needs to account for which client is making which call.

What to check before this goes into a proposal

Confirm which specific tools a client actually needs before assuming both servers are required. A workflow that only needs lead qualification and outreach drafting may never need Dataverse MCP write access at all, which simplifies both the security review and the licensing conversation considerably. Where write access genuinely is required, treat the admin center toggle and client allow-listing as a discrete deployment step with its own change ticket, not an assumed side effect of installing an MCP client. And build the Copilot credit cost of both servers into a pilot’s budget from day one, since credit consumption for generative tools scales with usage in a way that a fixed per-seat license does not.

Teams at Routeget Technologies have walked several clients through exactly this two-server design decision over the past few months, mostly because the documentation, while accurate, spreads the full picture across three or four separate Learn pages that don’t obviously reference each other. Getting the architecture right the first time saves a rework cycle that otherwise shows up a few weeks into a pilot, right around the point someone asks the agent to actually change a record instead of just describing one.

#DynamicsSalesMCP #DataverseMCP #AIinCRM #CopilotStudio #EnterpriseAI #D365SalesArchitecture