The Power Automate RPA Licensing Math That Breaks Most Finance Automation Rollouts

Finance operations team monitoring automated workflow dashboards in a modern control room

A finance operations director we worked with last quarter had a good problem: her three-bot pilot for invoice matching had worked exactly as promised. Exceptions dropped, the AP team stopped re-keying vendor data, and the CFO wanted it rolled out across the whole shared services center by the next close cycle. Then IT came back with a licensing quote roughly eight times higher than what the pilot had cost per month, and the rollout stalled in budget review for six weeks while everyone tried to figure out what had changed.

Nothing had changed technically. What changed was the license type, and Power Automate RPA licensing is exactly where a surprising number of finance automation programs lose momentum right after they prove themselves.

Power Automate RPA Licensing: Attended Pricing Is the Pilot Price, Not the Production Price

Most Power Automate pilots run attended, meaning a real person is logged into the workstation and the desktop flow executes while they’re at their desk, often triggered manually or from a scheduled prompt during business hours. Attended automation is licensed through Power Automate Premium at $15 per user per month, and that single per-user cost is genuinely all it takes to build and run desktop flows on a registered machine, with access to premium connectors, process mining, and a healthy daily action allowance built in.

That price is why so many pilots clear budget approval without much friction. Fifteen dollars a month per analyst is a rounding error against the labor hours it replaces, and it’s the number finance teams anchor on when they start sizing a broader rollout.

The problem is that production finance operations rarely stay attended. Month-end close doesn’t wait for someone to be logged into a specific machine, and neither does an overnight AP batch or a weekend bank reconciliation run. The moment a bot needs to run unattended, meaning on a schedule or a trigger with nobody present to log in and supervise it, Microsoft requires a Power Automate Process license (the plan formerly marketed as “per flow”), priced at $150 per bot per month if you supply and register your own machine, or a Hosted Process license at $215 per bot per month if you want Microsoft to provision and manage the virtual machine instead. Attended and unattended aren’t tiers of the same product; they’re licensed as genuinely separate capabilities, and a pilot built on the cheap one tells you almost nothing about what the expensive one will cost.

Finance operations analyst reviewing an automation workflow diagram on a monitor

Concurrency Is the Multiplier Nobody Models in a Pilot

The second gap is even easier to miss, because it doesn’t show up until someone asks how many things need to happen at once. A single Process or Hosted Process license grants one unattended bot capable of one desktop flow run at a time, with a daily ceiling of 250,000 actions. That’s usually plenty of headroom for a single automation running serially through a queue.

Finance operations at scale rarely stays serial, though. During a close cycle, a shared services team might need five invoice-processing automations running in parallel to clear a backlog before a reporting deadline, not one automation running five times faster. Each concurrent execution requires its own license; Microsoft allows stacking up to ten Process licenses against a single flow definition for higher-volume scenarios, but the cost scales linearly with concurrency, not with automation count. A team that budgeted for “the AP bot” as a single line item, based on pilot behavior where one instance handled everything sequentially, will find that peak-period parallelism during close is exactly the scenario that multiplies the bill.

This is worth raising explicitly with finance leadership before the rollout budget goes to the board, because it’s the single most common reason an approved RPA business case comes back for revision. The question to ask isn’t “how many bots do we need,” it’s “how many need to run at the same moment at our busiest point in the month,” and the answer to that question is what actually drives the license count.

Hosted Machines Change Who Owns the Infrastructure Risk

There’s a third decision buried in that $150 versus $215 per bot spread that has nothing to do with automation logic and everything to do with who’s on the hook for infrastructure. A standard Process license assumes your organization registers and maintains the machine the bot runs on: a real or virtual Windows endpoint that someone patches, secures, and keeps available. For an IT team already running a mature VM management practice, that’s a marginal addition to existing work.

For a finance-led automation initiative without dedicated infrastructure support, though, that machine becomes an unbudgeted ownership problem. Microsoft’s Hosted Process model addresses this directly: Hosted Machine Groups run on Azure infrastructure provisioned from a custom VM image through Azure Compute Gallery, with dynamic load balancing across the group and automatic reprovisioning during maintenance windows, and credential management shifts from static usernames and passwords to secrets held in Azure Key Vault rather than a spreadsheet somebody has to remember to update. None of that requires a dedicated RPA infrastructure team to operate day to day.

The sixty-five-dollar-per-bot premium for Hosted Process is, in effect, the price of not needing that team. Whether that trade makes sense depends entirely on whether the automation program is going to stay a handful of finance workflows or grow into a broader shared-services capability that justifies its own operational ownership. Organizations that guess wrong in either direction end up either paying for managed infrastructure they had the staff to run themselves, or trying to bolt VM governance onto a finance team that was never set up to own it.

Budgeting the Rollout, Not the Pilot

None of this means Power Automate is a poor fit for finance automation; the platform’s architecture guidance for scaling RPA operations is specifically built around exactly these production patterns, with capacity planning, committed and maximum bot counts, and utilization thresholds designed for high-volume periods like quarter-end processing and seasonal order backlogs. The issue isn’t the platform. It’s that the pilot’s economics and the production rollout’s economics are different products with different pricing logic, and treating them as the same line item is what turns a successful proof of concept into a stalled budget conversation.

Before a finance automation pilot goes to the board for rollout funding, it’s worth walking through three questions with whoever owns the license budget. First, will production runs actually be unattended, and if so, has the Process or Hosted Process cost been modeled instead of the Premium per-user rate the pilot used. Second, what does peak concurrency look like during the busiest close or reconciliation window, since that number, not the total automation count, determines the license count. Third, does the organization want to own the machine infrastructure or pay Microsoft to manage it, and is that decision being made deliberately rather than defaulting to whichever option the pilot happened to use.

Getting those three answers before the budget request goes out doesn’t just prevent an awkward six-week delay. It’s the difference between an RPA program that scales predictably alongside the finance function’s actual workload and one that keeps getting re-approved a bot at a time because nobody modeled what production would really cost. We’ve walked several finance operations teams through exactly this exercise before their rollout budgets went to committee, and the pattern is consistent: the teams that model concurrency and hosting decisions up front rarely get sent back for revision, and the ones that don’t, almost always do.

#PowerAutomate #RPALicensing #FinanceTransformation #ERPGovernance #DigitalTransformation #EnterpriseAI

Why Business Central Webhook Notifications Go Missing, and How to Architect Around It

Solutions architect reviewing a network integration dashboard representing Business Central webhook notifications

A Business Central integration that sailed through testing starts dropping records three weeks into production, and nobody can explain why until someone finally opens the subscription logs and finds a long trail of silent deletions. This is one of the more common failure patterns solution architects run into once Business Central webhook notifications move from a sandbox demo into a live integration carrying order confirmations, inventory adjustments, or approval status changes. The webhook model itself is well documented, but a handful of its operational rules are easy to miss during initial build-out, and missing them is exactly what causes integrations to degrade quietly instead of failing loudly where someone would notice.

The Handshake Most Implementations Get Half Right

Every Business Central webhook subscription begins with a validation handshake, and it is stricter than most developers expect on first pass. When a subscription is created against the v2.0 API, Business Central sends a request to the registered notification URL with a validationToken appended as a query parameter. The receiving endpoint has to echo that exact token back in the response body with an HTTP 200 status, and this is not a one-time formality. The same handshake fires again every time the subscription is renewed, which matters because Business Central webhook subscriptions expire after three days by design. There is no way to extend that window through configuration; the only supported pattern is issuing a PATCH request to the subscription resource before expiration, which triggers a fresh validation round trip.

Teams that build their receiver as a lightweight Azure Function often hit trouble here because of cold starts. If the function has scaled to zero and the handshake response takes more than a few seconds to come back, Business Central treats it as a failed validation and the subscription is never established or renewed. Keeping the receiver warm, or at minimum handling the validation response as the very first branch in the function before any other logic runs, removes most of the flakiness teams report during initial rollout.

Why Business Central Webhook Notifications Stop Coming, With No Error in Sight

The part of the design that catches experienced integration teams off guard is what happens after a notification actually fails to deliver. Business Central will retry a failed notification for up to 36 hours, but only if the subscriber’s endpoint responds with HTTP 408, 429, or something in the 5xx range. Any other response code, including a 400 or a 404 that might result from a temporary bug in the receiver’s routing logic, causes the subscription to be deleted immediately with no further retry and no separate alert. From the Business Central side, everything looks fine because the delivery attempt technically completed. From the integration’s side, notifications simply stop arriving for that entity, and unless someone is actively polling the subscriptions endpoint to check for unexpected deletions, the gap can persist for days before anyone notices missing sales order lines or unsynced customer records downstream.

This is the mechanism behind the scenario at the top of this article. A receiver that returns a 500 during a genuine outage is actually in a safer position than one that returns a 400 because of a malformed payload edge case, since the 500 at least buys 36 hours of retry attempts while the underlying issue gets fixed. Teams that want resilience here should treat any unhandled exception in the receiver as a 5xx rather than letting it bubble up as a generic error page, and should build a scheduled check that compares active subscriptions against the expected list so a silent deletion gets flagged rather than discovered by a downstream data gap weeks later.

Developer workstation showing an abstract data synchronization diagram representing a Business Central API integration

The Records Webhooks Quietly Refuse to Support

Before troubleshooting delivery issues, it is worth confirming the subscribed entity was ever eligible for webhooks in the first place, since Business Central will let a subscription be created against certain API pages that then never fire a single notification. Webhooks are not supported for API pages built on temporary tables, for pages where the OData key consists of more than one field or is otherwise composite, for system tables above table number 2000000000, for anything exposed as an API type query rather than an API type page, or for the Job Queue Entry table specifically. An API page built for a custom extension needs ODataKeyFields set to a single field, typically SystemId, or the subscription will appear to register successfully while silently never delivering anything.

Document-style entities carry their own nuance worth designing around. A change to a sales invoice line does not generate its own notification; instead, Business Central notifies against the parent sales invoice header when any of its lines change. Integrations that subscribe only at the header level and assume line-level granularity will miss the specific detail of what changed and need to follow up with a GET request against the full document to reconstruct it, which is standard practice anyway since webhook payloads never carry the actual record data, only a pointer to it and the type of change that occurred.

Batching, Delay, and the Events That Let You Tune Both

Business Central does not fire a notification the instant a record changes. There is a default 30 second delay built in after the first change to a watched entity, which exists to let a burst of related changes settle before anything is sent. If more than 1,000 records change within that delay window, Business Central collapses the individual notifications into a single collection notification rather than sending a thousand separate payloads, which is a sensible default for bulk imports but can surprise a downstream system expecting one notification per record during something like a large data migration or batch order release.

Both behaviors are adjustable for AL developers who need finer control. The delay interval can be modified through the OnGetDelayTime integration event in the API Webhook Notification Mgt. codeunit, and the threshold that triggers collection-style batching can be adjusted through OnGetMaxNumberOfNotifications in API Webhook Notification Send. Extensions that need near-real-time delivery for smaller entities, such as a status flag that a warehouse floor system needs to react to within a couple of seconds, are reasonable candidates for tightening the delay through these events; extensions dealing with high-volume header tables like sales lines are usually better served leaving the defaults alone and designing the receiver to handle collection notifications gracefully.

Designing for the Gaps: A Hybrid Pattern That Actually Holds Up

Given all of the above, the honest engineering position is that Business Central webhooks were never meant to be the sole source of truth for keeping two systems in sync, and Microsoft’s own documentation is candid that delivery is not guaranteed. Subscriptions can lapse from a missed renewal, a receiver bug can trigger an unannounced deletion, and network conditions on either side can drop a notification outright. The pattern that holds up in production combines the two mechanisms rather than choosing one: webhooks handle the fast path, giving near-real-time propagation for the vast majority of changes, while a scheduled reconciliation job, often running hourly or nightly depending on data volume, polls the same API endpoints using a last-modified timestamp filter to catch anything the webhook layer missed.

This is a small amount of extra engineering for a meaningful reliability gain, and it also solves the operational blind spot described earlier: the reconciliation job can double as the subscription health check, verifying that expected subscriptions still exist and re-registering anything that was unexpectedly deleted. Teams that skip this step tend to discover the gap only when a customer or finance team member notices a record that should have synced and did not, which is a far more expensive way to find the same bug.

What This Means for Your Next Integration Build

None of these behaviors are hidden or undocumented, but they are scattered across API reference pages that most teams read once during initial scoping and rarely revisit once the integration is live. The practical takeaway is to treat the three-day renewal window, the narrow retry code list, the unsupported table types, and the batching thresholds as design inputs from day one rather than issues to debug after the fact. At Routeget Technologies, the integrations that hold up longest in production are the ones where the reconciliation safety net was scoped alongside the webhook subscriptions from the start, not bolted on after the first silent data gap got noticed. Getting that sequencing right the first time is usually the difference between an integration the business trusts and one that quietly needs babysitting.

#BusinessCentralAPI #WebhookReliability #ERPIntegration #DynamicsBusinessCentral #ALDevelopment #EnterpriseIntegration

Before You Budget for Predictive Lead Scoring in Dynamics 365, Fix Your Customer Data

Sales operations leaders reviewing a unified customer data visualization on a screen, representing predictive lead scoring built on clean CRM data.

A CFO signs off on a Dynamics 365 Sales Premium upgrade because the pitch is straightforward: let machine learning flag which leads are actually worth a rep’s time, and stop burning quota on prospects who were never going to buy. Three months later, the predictive lead scoring model is live, the scores are showing up in the lead grid, and the sales team is quietly ignoring them. Not because the sellers are resistant to AI. Because the scores don’t match what they already know about the pipeline, and once a rep catches the model ranking a dead lead above a warm one twice, they stop trusting it entirely.

This is one of the more predictable failure patterns in Dynamics 365 Customer Engagement rollouts, and it has almost nothing to do with the scoring algorithm itself. Predictive lead scoring in Dynamics 365 Sales is a genuinely capable feature. The problem is that most organizations turn it on before their underlying customer data is in any condition to be scored, and no model, however well built, can compensate for that.

Sales operations leaders reviewing a unified customer data visualization on a screen, representing predictive lead scoring built on clean CRM data.

What predictive lead scoring actually needs before it can work

Microsoft is explicit about the minimums required to train a usable model: an organization needs at least 40 qualified leads and 40 disqualified leads closed within a training window that can range from three months to two years, with a default of two years. That threshold isn’t a suggestion. Fall short of it and the model has too little signal to distinguish a pattern from noise, and Dynamics will show it as not ready to publish based on its AUC accuracy score. You can override that warning and publish anyway, but the documentation is blunt about the result: the model will perform poorly, and it will keep performing poorly until retrained on better data.

That’s the technical detail. The business detail underneath it is more interesting. Getting to 40 clean, correctly dispositioned qualified leads and 40 clean disqualified ones sounds trivial until you actually audit a pipeline that’s been running for a few years with inconsistent qualification criteria, sales reps who mark things “disqualified” for a dozen different unwritten reasons, and duplicate lead records created every time marketing and a partner both touch the same contact. In our experience, the audit is where most of these projects should start, and almost never do.

There’s also a sync delay worth planning around: newly closed leads take roughly four hours to reach the data lake the model trains against, so a lead closed this morning won’t influence training until the afternoon. That’s a minor operational detail on its own, but it matters when you’re trying to hit a launch date and someone asks why yesterday’s closed deals aren’t reflected yet.

Why the data problem is really a Customer Insights problem

Here’s the part that doesn’t show up in most conversations about lead scoring: the leads sitting in Dynamics 365 Sales are frequently duplicates of the same underlying customer, split across records because they came in through different channels, were entered by different people, or predate a CRM migration that never fully deduplicated. A predictive model trained on that kind of data isn’t learning “what makes a good lead.” It’s partly learning “what makes a good lead record that happens not to have been merged yet,” which is a very different and much less useful pattern.

This is precisely the gap Microsoft’s Customer Insights – Data is built to close, and it’s worth understanding as more than a marketing data tool. Data unification in Customer Insights – Data runs through four stages: mapping which source columns represent stable customer attributes rather than transactional activity, applying deduplication rules to collapse duplicate rows into a single representative record, defining matching conditions that reconcile the same customer across different source tables, and finally producing a unified view that merges overlapping fields, such as six different email columns from six different systems, into one authoritative value per customer. Each unified profile gets a stable CustomerId, and if the underlying data or matching rules change enough that records merge or split later, the platform tracks the lineage through a PreviousCustomerId field rather than silently losing the history.

Abstract visualization of duplicate customer profile records merging into a single unified record, representing data unification in Dynamics 365 Customer Insights.

For a sales operations leader, the practical takeaway is that unification isn’t a one-time cleanup task bolted onto a CRM migration. It’s an ongoing process that determines whether every downstream AI feature, lead scoring included, is working from a coherent view of the customer or from a fragmented one. Microsoft’s own direction for 2026 makes this connection explicit: Customer Insights – Data is being positioned as the grounding layer underneath AI agents and Copilot experiences across the Dynamics 365 Customer Engagement suite, delivering the real-time, unified profiles those tools depend on. That’s not a coincidence. It’s an acknowledgment that the AI features getting the most executive attention right now are only as reliable as the data foundation underneath them, and Microsoft is building the platform accordingly.

What this changes about the rollout sequence

The organizations that get predictive lead scoring right generally do the sequencing in reverse order from how it gets pitched in a sales deck. Rather than licensing Sales Insights, flipping on the scoring model, and treating data quality as a follow-up item, they start by asking whether the lead and opportunity data in the system is clean enough to be worth scoring at all.

Concretely, that means auditing lead volume against the 40/40 threshold before committing budget, since an organization generating fewer than roughly 40 disqualified leads a quarter may need a longer training window or a rethink of what “disqualified” even means in their process. It means reviewing how consistently qualification and disqualification are being recorded today, since a model trained on inconsistent labeling will learn the inconsistency as if it were a real pattern. It means checking whether the same customer exists as multiple duplicate lead or contact records, and if so, treating deduplication and unification as a prerequisite project rather than a nice-to-have. And it means being honest about the AUC score once a model is trained: a model flagged as not ready to publish should not be pushed live just to hit a go-live date, because the credibility cost of sellers distrusting an inaccurate model is higher than the cost of a short delay.

There’s a licensing dimension worth flagging for budget owners too. Predictive lead and opportunity scoring through the quick setup path is available with Dynamics 365 Sales Enterprise, which includes a monthly allotment of scored records; other editions require checking current pricing and licensing guides directly, since Microsoft revises these terms often enough that anything printed here would be stale within a quarter. The point isn’t the specific number. It’s that scoring capacity is metered, so an organization planning to score its full lead volume needs to confirm the licensed capacity matches the actual pipeline size before rollout, not after.

The decision in front of you

None of this is an argument against predictive lead scoring, or against investing in Customer Insights – Data as part of a broader AI strategy. Both are mature, well-documented capabilities that do what Microsoft says they do. The argument is against sequencing the investment backward: buying the AI feature first and treating the data foundation as an afterthought, then wondering why adoption stalls when sellers stop trusting scores that were never going to be reliable given what they were trained on.

If you’re the executive sponsor evaluating this kind of investment, the useful question isn’t “should we turn on predictive scoring.” It’s “do we currently have 40-plus clean, consistently labeled examples on both sides of the qualified and disqualified line, and is our customer data unified enough that a model trained on it reflects real customers rather than duplicate records.” Answer that honestly first. We’ve walked enough clients through this exact sequence at Routeget Technologies to know that the organizations willing to spend a few weeks on that audit before flipping the switch are the ones whose sales teams actually end up using the scores six months later.

#PredictiveLeadScoring #DynamicsSales #CustomerDataPlatform #CRMDataQuality #AIinCRM #DigitalTransformation

Configuring the Business Central MCP Server for Safer AI Agent Access

Solution architect reviewing an AI agent access and data governance diagram on a large screen in a modern office

A client’s IT director asked us a version of the same question three times in the last two months: can we let an AI agent look up sales order status without giving the BI team another integration to maintain? Until this year, the honest answer involved a scoping conversation about which client needed access, whether Copilot Studio, a custom GPT, or something built in-house, followed by a separate OData or API wiring job for each one. The Business Central MCP server, now generally available, removes most of that repeated integration work. What it does not remove is the need to think carefully about what you are actually authorizing, because the place where access gets decided is narrower and more consequential than most admins realize the first time they open the configuration page.

What the MCP Server Actually Replaces

The Model Context Protocol is an open standard for connecting AI applications to external systems through a single, predictable interface rather than a bespoke integration per client. Business Central’s implementation exposes a hosted endpoint at mcp.businesscentral.dynamics.com that any MCP-compliant tool can call once it authenticates. Microsoft’s own clients, Visual Studio Code with GitHub Copilot and Copilot Studio, are pre-registered and require no extra setup on the Entra side. Claude, ChatGPT, and other third-party or custom agents can connect too, though they require a one-time Entra ID app registration performed by someone with Application Developer rights in the tenant. The practical effect is that a solution architect no longer has to build and maintain a separate connector for every AI tool the business wants to try. One configuration, applied once inside Business Central, governs how every one of those clients sees the environment, and that consolidation matters more than the fact that an AI tool can now query an ERP system at all.

It is worth noting this applies to Business Central Online only. On-premises deployments are not in scope, which is consistent with how Microsoft has handled most of its recent Copilot and agent investments across the Dynamics 365 portfolio.

Developer configuring secured API access for an AI agent, shown as a connected node diagram with a lock icon on a monitor

Read Access Is the Easy Part, and It’s Already On

By default, the Business Central MCP server exposes read-only access to every API page already published in the environment, and this requires no configuration at all. For a reporting agent or a Copilot Studio bot meant to answer “what’s our open AR balance for this customer,” that default is genuinely useful out of the box. It also means that the moment the MCP server is enabled for a tenant, every exposed API page becomes queryable by whatever client successfully authenticates, so the meaningful early decision is not whether to allow reads, but which identity gets to authenticate and what that identity’s permission set already restricts. The MCP layer inherits Business Central’s existing role-based security, so a user whose permission set excludes payroll data will not see payroll data through an agent either. That inheritance is reassuring, but a poorly scoped Business Central user account handed to an agent is just as risky through MCP as through the web client itself.

Where the Business Central MCP Server’s Governance Boundary Lives

Write access is a different story, and this is where the configuration work actually matters. Administrators manage it through the Model Context Protocol (MCP) Server Configurations page, where each configuration record lists specific API page objects and, for each one, individual toggles for Allow Read, Allow Create, Allow Modify, Allow Delete, and Allow Bound Actions. Bound actions matter more than the name suggests: they let an agent trigger real business logic, such as posting a sales invoice or releasing a purchase order, rather than just editing a field. There is also a shortcut labeled “Add All Standard APIs as Tools,” genuinely convenient for standing up broad read access quickly. The trap is treating it as a shortcut for write access too. Flipping create, modify, or delete permissions across every standard API in one pass means an agent misinterpreting a prompt, or a poorly written custom skill, now has a blast radius spanning the entire ledger instead of the two or three record types the business case actually called for.

Environments with many exposed APIs can also turn on Dynamic Tool Mode, which discovers tools at runtime instead of registering all of them up front, paired with Discover Additional Objects to give agents read-only access to API pages that were not explicitly configured. That combination is sensible for read scenarios at scale. It becomes a governance question the moment someone also enables Unblock Edit Tools on that same broad configuration, since it is easy to lose track of exactly which of dozens of auto-discovered objects now also permit writes. The cleanest pattern we have used with clients keeps broad discovery strictly read-only, and adds write-enabled API pages one at a time, by object, as a named and reviewed decision rather than a blanket setting.

The OAuth Scope Doesn’t Match the MCP Permission Model

There is a nuance here worth flagging explicitly for anyone doing the Entra ID side of this setup. When a non-Microsoft client like Claude or a custom agent registers its application in Entra ID, the delegated permission it requests against Business Central is Financials.ReadWrite.All, granted once at admin consent. That is a broad grant at the identity and OAuth layer, and it does not change when someone later tightens or loosens the per-object CRUD flags on the MCP Server Configuration page back in Business Central. The actual restriction a business relies on day to day lives entirely in that configuration record, not in the OAuth consent granted months earlier, which will not prompt the user again. If a configuration is later expanded from read-only reporting to include modify rights on the customer API, for instance, nothing at the identity layer flags that expansion. That makes the MCP configuration closer to a firewall rule than a one-time setup step, and it argues for reviewing these configurations on the same cadence as any other integration user’s permission set, not just at go-live.

A Practical Rollout Pattern

For clients asking how to approach this without over-restricting the agent into uselessness or over-provisioning it into a risk, the pattern that has worked well starts narrow and expands deliberately. Begin with a configuration that leaves Unblock Edit Tools off entirely, relying on default read-only behavior across whatever API pages the business wants an agent to query, whether that is sales orders, item availability, or open AR. Name the configuration for its actual business purpose, such as SalesTeamConfig, rather than something generic, since that name is what shows up in Copilot Studio and in any audit trail. Once a specific write use case is identified and tested, such as letting an agent update expected ship dates on an open sales order, add only that API page with only the Modify flag enabled, leaving Create, Delete, and Bound Actions off unless there is a tested reason to need them. Treat bound actions, especially anything that posts a document or changes a financial status, as requiring a human approval step inside the agent’s own workflow logic before that permission is ever granted, since the MCP server itself has no concept of an approval gate. It simply executes what it is authorized to execute.

A Few Practical Limits to Plan Around

API pages of the ListPart and CardPart subtypes are not supported as MCP tools, so only top-level API pages can be exposed, which occasionally requires a small amount of extension work if the data an agent needs lives behind a part page rather than a standalone API. Copilot Studio also caps agents at seventy tools, which is the practical reason Dynamic Tool Mode exists for larger environments. And if a company or configuration name contains non-ASCII characters, most clients require that value to be Base64-encoded in the connection headers, with Copilot Studio being the one client that handles this automatically. None of these are dealbreakers, but they are the kind of detail that turns a quick proof of concept into a half-day debugging session if nobody catches them up front.

Where This Leaves Solution Architects

The interesting part of this release is not that an AI agent can now talk to an ERP system, since that capability has existed in various bespoke forms for a while. It is that Microsoft put a single, inspectable governance surface between every possible AI client and the underlying ledger, one that any admin can open and audit without understanding the internals of whatever agent is calling it. That is a meaningfully better starting position than trusting each client’s own integration code to enforce the right boundaries. We have started treating the MCP Server Configuration record the same way we would treat a new integration user’s permission set during a Business Central implementation: an artifact that gets documented, reviewed at go-live, and revisited whenever a new agent use case gets added. Firms that skip that step are not doing anything wrong on day one. They are just deferring a governance conversation that will eventually happen anyway, usually right after someone asks why an agent was able to do something nobody remembers explicitly approving.

Routeget Technologies has been helping clients scope these MCP configurations as part of broader Copilot and agentic AI rollouts across Dynamics 365, and the lesson so far is consistent: the technology is ready faster than most internal governance processes are, so the configuration discipline matters more than the initial setup.

#BusinessCentralMCP #DynamicsFinanceOps #AgenticAI #CopilotStudio #ERPGovernance #EnterpriseAI #DynamicsBusinessCentral

Dynamics 365’s 2026 Demand Planning Upgrades Are Real, But the Rollout Timeline Will Test Your Patience

Supply chain team reviewing AI-driven demand planning dashboards in a modern operations control room

A supply chain director at a mid-market manufacturer sat down last month to build the case for next year’s planning software budget. The pitch practically writes itself on paper: Dynamics 365 Supply Chain Management is adding generative AI to demand planning, tying pricing signals directly into forecasts, and protecting capable-to-promise dates so sales commitments stop getting quietly overwritten during nightly optimization runs. The finance team likes anything that reduces safety stock and expedite freight. The problem is that when she tried to pin down exactly what she could turn on, and when, the answer kept shifting depending on which Microsoft page she read. That confusion, more than the technology itself, is what deserves attention before anyone commits budget to this wave of updates.

What 2026 Wave 1 Actually Adds to Demand Planning

Microsoft’s 2026 release wave 1 for Dynamics 365 Supply Chain Management introduces a genuinely useful set of planning capabilities, and it’s worth separating the marketing language from what actually changes on the ground. Price-to-demand correlation lets planners factor pricing moves, and in some configurations broader signals like inflation trends or macroeconomic indicators, into forecast models rather than relying solely on historical sales history. For a business running seasonal promotions or facing input-cost volatility, that’s a meaningful shift away from forecasts that assume next quarter will look like the last one.

Alongside that, capable-to-promise date protection addresses a complaint that has followed planning optimization for years: a rerun of the planning engine could silently push back a delivery date a salesperson had already confirmed with a customer. The 2026 update adds controls so confirmed CTP dates hold during optimization, which sounds like a small technical detail until you consider how many customer service escalations start with “but your system told us September 3rd.” Microsoft has also added AI-generated explanations for forecast accuracy metrics, aimed at planners who currently treat forecast error percentages as a black box handed down from the system rather than something they can interrogate and act on.

The most attention-grabbing piece is generative demand insights, which uses AI to surface anomalies and emerging trends in demand data automatically, cutting down the manual pattern-hunting that occupies a lot of a demand planner’s week. It’s a legitimate capability. It is also, and this matters for budgeting purposes, delivered through the Demand Planning Power App rather than the core Supply Chain Management application.

Warehouse operations professional reviewing an inventory and demand forecast dashboard on a tablet

The Timing Detail That Changes Your Rollout Plan

Here is where the pitch gets complicated, and where a lot of organizations will misjudge their own readiness. The Demand Planning Power App runs on a separate release cadence from the main Dynamics 365 platform. That means a feature announced under the same “2026 Wave 1” banner as your core F&O updates can land on a completely different timeline, with its own public preview window and its own general availability date, sometimes months apart from the rest of the release you’re already tracking in your change management calendar.

Concretely, generative demand insights and the multi-source forecast enhancements are targeted for general availability around August 2026, while the AI explanations for forecast accuracy move from public preview in late July into general availability closer to October. CTP date protection follows its own path through preview in June and general availability in September. None of these dates are far off as this is written, but they are not simultaneous, and none of them are “already live everywhere” the way a headline about “AI in Dynamics 365” might imply to someone skimming a vendor newsletter.

This staggered rollout isn’t unique to demand planning. Microsoft has been shipping Copilot and agentic capabilities across the platform in phases for a couple of years now, and organizations that assume a single “go live” date for an entire wave consistently end up scrambling when a feature they’d promised to a business stakeholder turns out to still be in preview, restricted to certain regions, or gated behind a licensing tier they hadn’t budgeted for. Planning optimization running on Azure operated by 21Vianet, for instance, is a regional compliance feature that matters enormously if you operate in China and is entirely irrelevant everywhere else, yet it ships under the identical wave label as the demand insights features every planner is asking about.

What This Actually Means for the Business Case

None of this is a reason to skip the upgrade cycle. It’s a reason to build a business case around outcomes rather than feature names. The real value proposition behind price-to-demand correlation is fewer forecast overrides by planners who don’t trust the baseline number, which in turn means less time spent on manual spreadsheet adjustments that never make it back into the source system anyway. The value behind CTP protection is fewer service recovery costs and less friction between sales and operations when a promised date holds instead of moving. Framed that way, finance leaders can evaluate the investment against concrete line items: expedited freight spend, safety stock carrying cost, and the labor hours currently spent reconciling planner intuition against system output.

It’s also worth being honest about what generative AI forecast explanations will and won’t do. They will help a planner understand why the system produced a given number, surfacing the inputs and pattern it weighted most heavily. They will not, on their own, fix a forecast built on bad master data or incomplete demand history. Organizations that have struggled with forecast accuracy because of messy item hierarchies or inconsistent unit-of-measure conversions will get an AI explanation of a flawed number faster, not a better number automatically. That distinction matters when someone in the room suggests that turning on AI features can substitute for the data cleanup project that’s been deferred for two budget cycles.

Considerations Before You Commit

Before locking in a rollout date, it’s worth having a documented answer to a handful of specific questions rather than treating the wave as a single package to approve or reject. Confirm which of these capabilities are available in your specific environment and region today versus scheduled for later in the year, since preview and general availability dates differ by feature and the Power Platform components move on their own schedule separate from your core application updates. Establish a current forecast accuracy baseline, measured the same way the new AI explanation tooling will measure it, so that any improvement claim after go-live can be verified against your own numbers rather than taken on faith. Involve FP&A early, since price-to-demand correlation touches assumptions that finance already owns in budget and margin models, and a disconnect between what planning assumes about price elasticity and what finance has modeled will surface eventually, usually at a bad time. Finally, pilot with a limited, representative set of SKUs or product families before extending any new forecasting logic across the full catalog, because the categories most likely to benefit from pricing-aware forecasting, typically promotional or price-sensitive goods, are rarely representative of your entire portfolio.

Organizations that have gone through several of these Dynamics 365 upgrade waves tend to develop a healthy skepticism toward the words “coming this release,” and that skepticism is earned rather than cynical. The underlying capabilities in this wave are sound and address real, longstanding gaps in demand planning. Teams that have implemented and stabilized F&O supply chain modules across multiple release cycles, including groups like Routeget Technologies that work through these staggered rollouts regularly, tend to treat the release notes as a starting point for a conversation about sequencing rather than a checklist to execute all at once. The organizations that get the most out of this wave will be the ones that map each capability to a specific, measurable business problem before they touch a configuration screen, not the ones that switch everything on the day it appears in their tenant.

#DynamicsSCM #DemandPlanning #SupplyChainAI #D365FinanceOps #EnterpriseAI #DynamicsD365Implementation