Business Central’s New EDI Documents Feature Won’t Let You Cancel Your EDI Provider

Finance operations manager reviewing electronic document exchange status in a logistics office

If your finance team is currently paying an outside EDI provider a recurring fee to keep your Business Central environment talking to Walmart, a major distributor, or a third-party logistics partner, the preview notes for Business Central 2026 release wave 2 probably caught your eye. Buried in the update 29.0 feature list is the new EDI documents feature: the ability to exchange orders and payments, not just invoices, directly through the E-Documents framework using the Peppol BIS 3 standard. For a CFO or IT director who has spent years signing checks to a middleware vendor just to keep retail trading partner mandates satisfied, that sentence reads like an invitation to finally consolidate. It is worth understanding exactly what changed before anyone drafts a cancellation notice.

What the new EDI documents feature actually adds

Business Central’s E-Documents framework is not new. It has existed for several release cycles as the mechanism behind country-specific e-invoicing mandates: Peppol for Australia and New Zealand, OIOUBL in Denmark, XRechnung and ZUGFeRD in Germany, Factura-E in Spain, with France support arriving this year. Until this release, the framework’s job was largely to get sales invoices out the door and purchase invoices in, formatted correctly for whichever national authority or trading network required them.

What update 29.0 adds, currently in public preview as of September 2026 and scheduled for general availability in October, is support for exchanging orders and payments through that same framework, using the Peppol BIS 3 EDI standard specifically. In practical terms, that means a document type beyond the invoice can now move through E-Documents using a message format built for machine-to-machine exchange rather than a PDF attached to an email. That is a genuine expansion of scope, and for the right customer it closes a real gap.

The catch is in the phrase “Peppol BIS 3.” Peppol is a specific network and message specification, developed originally for European public procurement and now widely used for e-invoicing compliance across the EU, the UK, Australia, New Zealand, and a growing list of other jurisdictions. It is not the same thing as the ANSI X12 or EDIFACT standards that govern the EDI relationships most North American manufacturers, wholesalers, and distributors maintain with retail trading partners. A purchase order transaction set 850, an invoice 810, or an advance ship notice 856 sent through a retailer’s EDI network does not speak Peppol, and nothing in this release changes that.

Abstract illustration of electronic documents flowing between two connected trading partner networks

Why the connector layer still matters

There is a second detail worth flagging before anyone assumes this feature makes Business Central’s e-document capability self-sufficient. The E-Documents framework has always relied on named third-party service connectors to actually move documents onto whatever network the recipient uses. Pagero, Avalara, Logiq, SignUp’s ExFlow e-invoicing service, and B2BRouter are the currently supported options, and each requires its own separate contract and, in most cases, its own subscription cost. Microsoft’s documentation is explicit that these are external commercial relationships, not services Microsoft itself manages end to end.

That architecture does not change with the EDI feature. Adding order and payment support to E-Documents means the framework can now carry more document types over the Peppol BIS 3 rail, but a business still needs a connector relationship in place to actually reach a Peppol access point, just as it does today for invoices. For a company operating primarily in Peppol-covered geographies, that is a meaningful simplification: one framework, one set of document types, and potentially fewer point-to-point integrations for order confirmations and payment status messages that previously ran through a separate mechanism entirely.

For a company whose EDI obligations run through a North American retail network instead, the calculus barely moves. The dedicated EDI platforms built around Business Central, names like TrueCommerce, SPS Commerce, and the various Business Central-specific EDI ISV solutions on AppSource, exist precisely because they translate between Business Central’s data model and the X12 and EDIFACT transaction sets that retailers, grocers, and big-box trading partners require, along with the value-added network relationships those partners often mandate. None of that is addressed by extending Peppol BIS 3 coverage to orders and payments. If your EDI provider’s invoice is for connecting to a VAN and translating X12 850s into sales orders, this preview feature does not touch that relationship at all.

What to actually check before wave 2 reaches general availability

The practical work here is not deciding whether to switch, it is figuring out which category your organization falls into, and that requires a document-by-document inventory rather than a guess. Start by pulling the list of every trading partner your company currently exchanges electronic documents with through Business Central, and note the standard each one actually uses. A subsidiary invoicing government or large enterprise customers in the EU, Australia, or New Zealand through a Peppol access point is a strong candidate to benefit directly once this feature reaches general availability, since order and payment documents for those same relationships may be consolidatable into the same connector and the same E-Documents setup already in place for invoicing.

A distribution or manufacturing business fulfilling retail purchase orders through a VAN-based EDI relationship should not expect this update to reduce that spend. It is worth raising the question directly with your existing EDI provider anyway, since some of them are exploring hybrid support that bridges Peppol and traditional EDI standards, and a provider roadmap conversation now costs nothing and might surface options before your next contract renewal.

It is also worth remembering that this is a preview feature, not a shipped one. General availability is not expected until October 2026, and preview functionality in Business Central has a track record of shifting in scope, licensing treatment, or connector support between preview and GA. Testing this in a sandbox environment against a real Peppol-connected trading partner, rather than assuming the release notes describe the final behavior, is the responsible way to validate whether it does what your business actually needs before making any commercial decision tied to it.

One more consideration deserves a place on the evaluation checklist: cost. Connector-based e-document exchange through Avalara, Pagero, or similar providers is typically priced per transaction or per connection, separate from Business Central licensing itself. Adding order and payment document types to that same connector relationship may increase transaction volume through the connector without necessarily reducing your total third-party spend, particularly if your current EDI provider is priced on a flat annual basis rather than per document. Getting an updated quote from your connector provider that reflects the expanded document scope, before assuming the math works in your favor, avoids an unpleasant surprise on the next renewal invoice.

The gap this does close

None of this is a criticism of the feature itself. Extending E-Documents to cover orders and payments, and doing it through a widely adopted international standard rather than a proprietary Microsoft format, is a sensible direction for a platform that increasingly serves multinational subsidiaries alongside single-entity small businesses. Firms with meaningful European, UK, Australian, or New Zealand operations that have already invested in Peppol-based invoicing now have a credible path to extend that same investment to a broader set of transaction types, which is exactly the kind of incremental platform improvement that reduces the number of point integrations a lean IT team has to maintain over time.

The mistake would be treating a preview release note as a green light to unwind an existing EDI relationship without first confirming which standard that relationship actually runs on. Routeget’s engagements with Business Central customers on electronic document strategy typically start with exactly that inventory: mapping every trading partner document exchange against the standard it uses, before any conversation about consolidating connectors or renegotiating contracts. That groundwork takes a few days, and it is the difference between a genuine cost reduction and a canceled contract that gets reinstated three months later once a retail partner’s EDI compliance team sends a noncompliance notice.

#BusinessCentral #EDIIntegration #PeppolBIS3 #ElectronicDocuments #TradingPartnerCompliance #DigitalTransformation

The Business Central SOAP Retirement Deadline Is Closer Than It Looks

IT director reviewing a systems integration architecture diagram on a monitor in a modern office

The Business Central SOAP Retirement Deadline Is Closer Than It Looks

An IT director doing an annual vendor risk review recently found an integration nobody on her team remembered building. A bank feed connector, installed years earlier by a consultant who has long since moved on, was quietly pulling transaction data into Business Central through a SOAP endpoint pointed at a standard Microsoft page. It had run without incident since before her tenure started. The discovery only mattered because of one line buried in a Microsoft release note: that endpoint, and every other SOAP connection built the same way, stops working the moment Business Central version 29 reaches general availability in the first week of October 2026.

That is the practical shape of the Business Central SOAP retirement. It is not a single dramatic cutoff so much as the final step in a multi-year phase-out that a lot of IT teams filed away as a developer’s problem and never revisited. Microsoft introduced a feature key called “Disable SOAP web services on Microsoft UI pages” in the 2025 release wave 1 update, version 26, and it has been switched on by default ever since, blocking any new attempt to publish a standard Microsoft page as a SOAP endpoint. What made that default setting survivable for older integrations was the fact that an administrator could still go into Feature Management and turn the key back off, keeping the legacy behavior alive. Version 29 removes that feature key entirely. Once it is gone, there is no setting left to flip back on, and any integration still pointed at a Microsoft UI page over SOAP simply stops receiving responses.

The Business Central SOAP Retirement Only Touches Microsoft’s Own Pages

The scope here matters more than the deadline itself, because it is easy to overreact or underreact depending on how the news reaches you. What is actually being removed in version 29 is narrower than “SOAP support in Business Central.” Microsoft’s own justification, stated plainly in its developer documentation, is that a UI page was never designed to function as a stable API contract: a field can move, a control can be renamed, and none of that counts as a breaking change from Microsoft’s perspective, even though it can silently break an integration built directly against that page’s SOAP surface. So the retirement targets exactly that pattern: standard, out-of-the-box Microsoft pages exposed as SOAP web services.

Two other patterns are not affected by this particular change. SOAP endpoints built on codeunits keep working, since a codeunit is intentionally structured as a stable interface rather than a UI surface. SOAP endpoints built on custom, per-tenant extension pages also continue to function, because your organization controls that page’s schema and accepts responsibility for changes to it. If your integration inventory turns out to be built entirely on one of those two patterns, version 29 will not touch it. Many organizations, though, will find that at least one long-running integration, often the oldest one, was built the simple way: pointing directly at a Microsoft page because that was the path of least resistance when someone set it up years ago.

Abstract illustration of a legacy data connector being replaced by a modern API connector

The Stopgap That Isn’t a Real Exemption

Microsoft’s own migration guidance includes an option that looks like an easy out: copy the source of the affected Microsoft page into a per-tenant extension, republish that copy as your own page, and expose the copy as a SOAP endpoint instead. Technically, this works, and it buys time without touching whatever consumes the integration on the other end. It is worth treating as exactly what it is, a stopgap, and not as a long-term architectural decision.

Two things argue against leaning on it permanently. First, you now own and maintain that copied page yourself, including any future logic changes Microsoft makes to the original that you will need to track and replicate by hand, which is precisely the maintenance burden the API-first approach was designed to avoid. Second, this is not the only deprecation moving through the same pipeline. Microsoft has already issued the equivalent warning for exposing Microsoft UI pages as OData endpoints, with removal currently targeted for the 2027 release wave 1 update, version 30. The pattern is consistent: UI-page-based web services of any protocol are being phased out in favor of purpose-built API pages and queries. A team that spends its 2026 budget re-platforming a SOAP integration onto a per-tenant extension, rather than onto a proper API page, is likely to be back doing similar work again in 2027 for the same underlying reason.

What This Means for Your Integration Portfolio

For a CIO or IT director, the practical risk is less about any single connector breaking and more about not knowing how many connectors exist in this pattern in the first place. SOAP-based integrations against Microsoft pages tend to cluster in a few high-value, low-visibility categories: bank statement and payment feeds set up early in an ERP implementation, EDI order intake with a long-standing trading partner, warehouse scanning or shop-floor tools built from an older sample or tutorial, and ISV add-ons purchased years ago from a vendor who may or may not have modernized their own connector since. None of these show up on a typical application inventory unless someone specifically goes looking for the transport protocol underneath them, which is exactly why this kind of deprecation tends to surface as an incident rather than as a planned project.

The financial exposure is concentrated, not diffuse. A broken bank feed means a manual reconciliation process returns overnight, right when finance least wants to discover it. A broken EDI intake means orders stop flowing from a partner who is unlikely to be sympathetic to an internal software upgrade as an excuse. Compare that to, say, a reporting dashboard built the same way, where a short outage is an inconvenience rather than a revenue event. Triage should follow that same logic: not every SOAP endpoint deserves equal urgency, but the ones tied to cash and order flow deserve attention well before the October deadline, not the week of it.

A Practical Sequence Before October

The starting point is visibility, not migration. Business Central logs incoming web service requests, and that telemetry can be pulled to show exactly which endpoints are being called, how often, and by page or codeunit type, before anyone commits engineering time to fixing something that may not even be at risk. From there, the sequence is straightforward in outline even if the execution takes real effort: separate the SOAP calls hitting Microsoft UI pages from those hitting codeunits or per-tenant extensions, since only the first category is on the clock; rank the affected integrations by business impact rather than by ease of fixing them, so a low-effort reporting connector does not quietly jump the queue ahead of a bank feed; and for anything ranked high, start the conversation with whoever owns the other end of the integration; internal developer, systems integrator, or third-party vendor, well before the release actually lands, since REST API pages or OData V4 endpoints for the same data may already exist and simply were never adopted when the integration was first built.

For integrations tied to a purchased ISV app, it is worth a direct question to the vendor rather than an assumption either way: ask specifically whether their connector talks to Business Central over SOAP against a standard page, and if so, what their own migration timeline looks like. A vendor who has not addressed this yet is effectively asking your organization to inherit their technical debt on their schedule, not yours.

Treat This as a Cleanup Project, Not a Fire Drill

The organizations that come out of this in good shape are the ones that treat the Business Central SOAP retirement as the forcing function for an integration inventory they should have had anyway, rather than as an isolated ticket to close before a deadline. We have seen the alternative version of this play out with prior Business Central deprecations: a scramble in the final weeks, a rushed fix that solves the immediate protocol problem without addressing the underlying design, and the same conversation repeating itself at the next deprecation cycle. Version 29 is a good moment to ask the larger question once, properly, rather than answering the narrow one twice.

#BusinessCentral #SOAPRetirement #ERPIntegration #APIModernization #IntegrationGovernance #DigitalTransformation

The Power Pages Security Model Is Changing. Your Table Permissions Still Need an Audit.

IT security professional reviewing an abstract portal permissions and access-control dashboard on a widescreen monitor

A CIO at a mid-size insurer found out about the problem during a routine vendor risk review, not from an internal alert. A claims-intake portal built two years earlier by a business analyst on the operations team, using Power Pages because it was faster than waiting for a developer sprint, had an Anonymous Users role configured with Global Access read permission on a table that included policyholder contact information. Nobody had touched the site’s permissions since launch. Nobody on the security team had reviewed it either, because it had never appeared on a list of applications anyone was tracking. That is the quiet risk of low-code external portals: they get built quickly, they work, and they slip out of the governance perimeter that would normally catch a misconfiguration like this one. It is also the backdrop against which every CIO should be reading Microsoft’s current overhaul of the Power Pages security model, because the two changes underway solve different halves of that same problem.

This is not a hypothetical. In late 2024, researchers at AppOmni disclosed that a large number of Power Pages sites across industries, including a UK National Health Service contractor, were exposing sensitive data because of exactly this pattern: table permissions granted at Global Access to the Anonymous Users or Authenticated Users role, on sites where self-registration meant “authenticated” effectively meant “anyone who signed up.” One case alone reportedly exposed contact information for more than a million people. Microsoft’s own documentation on table permissions has warned about this since Power Pages existed under its earlier name, but the setting is easy to get wrong and easy to forget about once a site is live.

Two Different Problems Wearing the Same Name

Microsoft’s response to date has taken two distinct forms, and it is worth CIOs and IT directors being precise about which one solves which problem, because the two get conflated in vendor briefings more often than they should.

The first is a genuine security tool: the Security Scan and Security Hub capability, which reached general availability in the back half of 2025. It scans a site’s configuration and flags the exact patterns AppOmni’s researchers were finding by hand, such as Anonymous or Authenticated roles with unusually broad table access. This is the tool that actually catches the problem described above, and if your organization has Power Pages sites in production and has not run this scan against every one of them, that is the first governance action to take this quarter, independent of anything else in this article.

Abstract close-up of a laptop screen showing a glowing network authorization diagram with role and permission nodes

The second is architectural, and it is easy to mistake for a security fix when it is really a plumbing change. Power Pages has always run two separate authorization systems side by side: Web Roles, which govern what a portal visitor can see and do on the site itself, and Dataverse Security Roles, which govern access to the underlying data. They were related but not unified, which meant a portal’s activity in Dataverse was historically attributed to a shared application user rather than the individual who was actually signed in, and administrators had to document, reason about, and troubleshoot two parallel permission models for the same site. Starting with a preview that shipped July 8, 2026 and targeted for general availability in November 2026, Microsoft is merging the two: each Power Pages user is now represented as both a Dataverse Contact and a Dataverse System User, and each Web Role maps directly to a corresponding Security Role. When a portal visitor calls Dataverse, the request now carries that visitor’s own identity rather than a generic service account.

What Changes in the Power Pages Security Model, and What Doesn’t

For a CIO evaluating whether this matters, the honest answer is that it is a governance quality-of-life improvement, not a vulnerability patch. The practical benefits are real but specific. Audit trails improve meaningfully, because actions taken through a portal now show up in Dataverse tied to the actual visitor rather than a shared identity, which matters for any organization that has to answer a compliance question like “who accessed this record and when.” Administrative overhead drops somewhat, because a security team no longer has to maintain a mental model of two loosely coupled permission systems and explain the seams between them to auditors or new hires. And because Microsoft describes this as a structural consolidation rather than a breaking change, existing sites are not expected to require a manual permissions migration when the rollout reaches them.

What it does not do is retroactively fix an Anonymous role that already has Global Access to a sensitive table, add column-level masking to a site that never configured it, or catch a wildcard entry in a site’s Web API field allowlist. Those are governance decisions, made by whoever configured table permissions when the site was built, and they persist through the unification exactly as they were. A cleaner, more auditable authorization backbone makes it easier to see a bad permission grant once someone goes looking for it. It does not go looking on its own.

What This Means for the Portal Sitting in Your Environment Right Now

If your organization has any Power Pages sites in production, three actions are worth taking before the November GA date, not because the unification itself is risky, but because it is a natural forcing function to finally do the review that should have happened at launch.

Start with an inventory question that is more often skipped than answered: does IT actually have a current list of every Power Pages site running in the tenant, who built it, and what data it touches? Citizen-developer tools succeed precisely because they let business teams build without waiting on IT, which also means those teams do not always think to tell IT what they built. A Power Platform Center of Excellence setup, or even a simple quarterly export from the admin center, closes this gap cheaply.

From there, run the Security Scan against every site on that list and treat any Global Access finding on the Anonymous or Authenticated role as a same-week fix, not a backlog item. Pair that with a manual check the automated scan will not catch on its own: whether column-level security profiles are configured on any table that includes personally identifiable information, since AppOmni’s testing found this control essentially unused across every site they reviewed, scanned or not.

Finally, treat the unification’s traceability improvement as an opportunity rather than a compliance checkbox. Once portal actions in Dataverse are attributed to individual users instead of a shared application identity, that data becomes genuinely useful for security operations and for internal audit, but only if someone owns pulling and reviewing it. Assign that ownership now, while the change is still new, rather than assuming a dashboard will surface it automatically.

We have run this exact audit sequence, security scan first, then a manual table-permission and column-security review, for several clients ahead of their own Power Pages authorization changes this year, and the pattern holds every time: the sites that fail are the ones nobody had looked at since the day they launched. A consolidated security model makes that oversight easier to catch. It does not make it disappear on its own, and the organizations that treat the two as the same thing are the ones that will still be explaining an exposure to their board next year.

#PowerPages #PowerPlatformGovernance #DataverseSecurity #CitizenDevelopment #DataProtection #DigitalTransformation

Business Central Assumes Infinite Capacity. Your Shop Floor Doesn’t.

Manufacturing operations manager reviewing a production scheduling timeline display in a plant office

A plant manager pulls up a production order in Dynamics 365 Business Central on a Tuesday morning and finds the scheduled start date sitting three days in the past. Nothing is wrong with the data. Business Central’s scheduling engine did exactly what it was designed to do: it calculated lead times backward from a promised ship date, ignored what else was already booked on that work center, and produced a plan that assumes the shop floor has unlimited hours to give. The manager now has two choices. Spend the next hour manually rearranging operations by eye, or accept a schedule that was never realistic in the first place. Multiply that by every work center, every week, and the real cost of Business Central capacity planning becomes visible: not a software defect, but a design decision that a lot of growing manufacturers eventually outgrow.

This is not a knock on Business Central as an ERP platform. For finance, inventory, and general operations, it does what a mid-market system should do. But its native production scheduling was built around a simpler assumption than most discrete or process manufacturers actually operate under, and understanding exactly where that assumption breaks is the first step toward deciding whether to live with it, work around it, or bring in something purpose-built to close the gap.

How Business Central Capacity Planning Works Today

Business Central schedules production orders using routing times, work center and machine center calendars, and either a forward or backward scheduling direction depending on whether the driving date is the order start or the promised delivery date. By default, this runs as infinite capacity scheduling: the engine calculates when an operation should happen based on lead times and sequencing, without checking whether the work center is already booked during that window. It is fast, and for a single order in isolation it produces a clean answer. The trouble starts when dozens of orders compete for the same handful of machines.

Business Central does offer a step toward realism through capacity constrained resources. A planner can register a work center or machine center as capacity constrained, which shifts scheduling to account for existing load rather than assuming the resource is always free. Manufacturers can also open the load matrix on a work center card and view capacity against load by day, week, or month, in either a net-change or cumulative view, which is genuinely useful for spotting a bottleneck before it becomes a missed ship date. What this setup does not do is resolve the conflict automatically. It surfaces the overload and leaves the planner to fix it, one operation at a time, inside a grid rather than a visual timeline.

That distinction, between a system that flags a problem and one that helps you solve it, is where the native tool set runs out of runway for a lot of manufacturing operations.

Manufacturing operations manager reviewing a production scheduling timeline display in a plant office

Where the Gap Actually Shows Up

The practical failure modes tend to look the same across different manufacturers, regardless of industry. Sequencing decisions, such as which of three competing orders gets the CNC machine first on Thursday afternoon, are left entirely to the planner’s judgment rather than being informed by setup time, tooling changeovers, or downstream dependencies the system already has data on. Machine breakdowns, absenteeism, and rush orders are realities that the schedule has no mechanism to absorb once it has been generated, so a single disruption cascades into an afternoon of manual replanning rather than a quick recalculation. And because the standard interface presents schedule data as rows in a list rather than bars on a timeline, a planner cannot see at a glance that moving one operation two hours later would clear an overload three operations downstream. Every one of these is solvable inside Business Central’s data model. None of them is solvable inside its native screens without a meaningful amount of planner effort and institutional memory about which orders always cause trouble.

For a small job shop running a handful of work centers, this is manageable with discipline and a good planner. For an operation running double-digit work centers with mixed routings, alternate machines, and customers who expect accurate ship dates, the manual overhead compounds fast, and it tends to land on the same one or two people who become a single point of failure for the entire schedule.

What a Visual Scheduling Layer Adds

This is the gap that a category of AppSource-listed manufacturing extensions has grown up to fill, and it is worth understanding as two distinct tiers rather than one undifferentiated feature.

The first tier is visual scheduling: a Gantt-style planning board that sits on top of Business Central’s existing production order and routing data, showing operations as draggable bars against work centers and machine centers rather than as list rows. NETRONIC’s Visual Production Scheduler, now part of Boyum IT following its 2024 acquisition, is the best-known example of this approach. Moving a bar reschedules the operation and writes the change back to the underlying production order immediately, with capacity histograms showing utilization by day or week so a planner can see an overload forming before committing to a change. This does not automate the scheduling decision. It makes the decision visible and fast to execute, which for many operations is the actual bottleneck rather than the underlying math.

Production planner reviewing a visual scheduling board with machine and work center bookings at a workstation

The second tier adds an automated finite capacity engine on top of that visualization. Insight Works’ MxAPS and NETRONIC’s Visual Advanced Production Scheduler both fall into this category, generating a schedule that accounts for machine and labor availability, tooling constraints, and material readiness without manual sequencing, and allowing planners to run multiple what-if scenarios before publishing one to the live schedule. This tier is a genuinely different proposition than visual scheduling alone. It is closer to the finite capacity planning Microsoft already offers natively in Supply Chain Management for enterprise customers, delivered instead as a third-party layer for the Business Central side of the product family, which does not include an equivalent built-in optimizer.

Neither tier is free, and neither is a drop-in decision. MxAPS, for example, requires the Business Central Premium edition, which itself carries a per-user cost difference from Essentials that should be part of the licensing conversation before a manufacturing operations leader gets attached to a specific tool. The right question is not which named product to buy. It is which tier of capability the operation actually needs, because a company struggling mainly with schedule visibility and manual drag-and-drop effort may get most of the value from the first tier at a fraction of the cost and implementation complexity of the second.

Deciding Whether This Is Worth Solving

Before budgeting for either tier, it is worth running a short internal audit. How many hours per week does a planner spend manually rearranging the schedule after it is first generated, and what is that time worth against a subscription cost measured in the low thousands per year. How often does a customer-facing ship date change because of a scheduling conflict that only became visible after the fact, rather than being caught in advance. And how much of the current process depends on one person’s memory of which machines, operators, or tooling combinations tend to cause problems, since that is institutional risk regardless of what software is in place.

If the answer to those questions points to real, recurring cost, a visual scheduling layer is one of the more straightforward manufacturing investments to justify, because the software sits directly on top of data Business Central already has rather than requiring a new implementation project. If the disruption is occasional and a disciplined planner is already managing it well with the load matrix and capacity constrained resources, it may be entirely reasonable to hold off and revisit the question as order volume or work center count grows.

Routeget Technologies has walked manufacturing clients through exactly this evaluation, weighing native capability against the two tiers of scheduling extensions before a licensing dollar is spent, and the pattern holds across most engagements: the decision is rarely about which vendor has the flashiest demo. It is about matching the tier of automation to the actual planning problem on the shop floor, and being honest about how much of that problem discipline alone can solve versus how much genuinely requires a different tool.

#BusinessCentral #ManufacturingScheduling #ProductionPlanning #ERPCapacityPlanning #DiscreteManufacturing #DigitalTransformation

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

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