Configuring Task-Level Schedule Mode and Calendars in Dynamics 365 Project Operations

Solution architect and project manager reviewing a task-level project schedule Gantt chart on an office display

A solution architect building out a work breakdown structure for a multi-region systems integration engagement runs into the same wall almost every time: one task in the schedule needs to behave differently from the rest of the project, and Project Operations won’t let it. Maybe it’s a client sign-off milestone that has to hold a fixed external date no matter how upstream tasks slip. Maybe it’s a QA cycle staffed by an offshore team working a five-day week that doesn’t match the delivery team’s four-day compressed schedule back home. Whatever the cause, the workaround has historically been the same: add a dummy predecessor, hardcode a constraint, or manually re-enter the date every time the auto-scheduling engine recalculates and quietly overwrites it. None of those are real fixes. They’re patches on a scheduling model that, until now, only let you set schedule mode and calendar once, at the project level, and apply it uniformly to every task underneath. A new task-level schedule mode option in Dynamics 365 Project Operations is about to make most of those workarounds unnecessary.

That constraint is finally loosening. Two features shipping in Dynamics 365 Project Operations 2026 release wave 1, task-level schedule mode and task-level calendars, let architects override both settings on individual tasks within a work breakdown structure instead of inheriting them from the project as a whole. It’s a small-sounding change with real consequences for how technical teams design schedules on programs that mix regions, vendors, or compliance-driven milestones.

Why the project-level-only model breaks down

To understand why this matters, it helps to be precise about what the existing scheduling engine actually does. Every task in a Project Operations WBS runs in one of two modes: automatically scheduled or manually scheduled. In automatic mode, the engine calculates start and end dates from predecessors, effort, and resource count, using the project’s working-day calendar to convert effort hours into a duration. A task without a predecessor defaults to the project’s scheduling start date; a task with one inherits the latest end date among its predecessors. Duration itself is derived by dividing effort by the number of assigned resources and the hours in a standard workday. Manual mode stops that recalculation for everything except one thing: predecessor relationships still force a task’s start date to shift when an upstream task moves, regardless of whether the dependent task is set to manual or automatic. That detail trips people up constantly, because manual mode feels like it should freeze a task completely, and it doesn’t.

Calendars sit underneath all of this. Working days, for the purpose of scheduling, have only ever come from the project’s own calendar, which every task in the WBS shares. On a single-region project staffed entirely from one delivery center, that’s a reasonable simplification. On anything more complex, it isn’t. A program with an offshore QA function, a subcontracted installation crew on a different regional holiday calendar, or a phase gated by an external auditor’s fixed calendar has always had to force those realities into one shared calendar or manage them entirely outside the tool.

What task-level schedule mode and calendars actually change

Assign task-level schedule mode for precise planning entered public preview on May 22, 2026 and reaches general availability in September 2026. It lets an architect set manual or automatic scheduling on a per-task basis within the same WBS, rather than the mode being a single project-wide toggle. Assign task-level calendar for precise planning follows the same timeline, moving from preview to GA in September 2026, and does the equivalent for working-day calendars: a specific task can now be assigned its own calendar, separate from the project’s default, so duration calculations for that task respect its actual working pattern instead of the project’s.

Both features land in the task details pane, which is itself getting a usability pass this same wave through the “customize task details pane” feature, so the timing isn’t coincidental. Microsoft is clearly treating granular task configuration as a connected set of improvements rather than one isolated fix.

Technical consultant workstation showing a project timeline and calendar grid representing task-level scheduling configuration

Practically, this means the offshore QA example stops requiring a workaround. The architect sets the delivery team’s tasks to inherit the project calendar as usual, then assigns the QA task its own calendar reflecting the actual working days of the team executing it. The engine now calculates that task’s duration correctly against its real calendar while everything else in the WBS continues to resolve against the shared one. The fixed-date compliance milestone gets set to manual mode with an explicit date, and because predecessor logic still governs start-date shifts as described above, the architect still needs to understand that an upstream slip will attempt to push that task’s start date forward even in manual mode. The fix here is architectural, not a way to disable dependency logic altogether: teams should model the compliance gate as a task with no dependency on the volatile predecessor chain, or accept that a genuinely fixed external date needs an explicit constraint plus a monitoring routine rather than pure reliance on manual mode.

Where this interacts with resource scheduling and bookings

Task-level calendars change effort distribution at the task level, but they don’t automatically touch the resource-scheduling layer sitting above the WBS. Project Operations still treats bookings, the organization-wide allocation of a resource’s capacity across projects, as conceptually separate from assignments, which are the task-level commitments derived from the schedule itself. The platform doesn’t enforce that the sum of a resource’s bookings equals the sum of their assignments; it gives you a reconciliation view to catch the difference. Task-level calendars add a new way for that gap to open, since a resource’s task-level effort can now be spread across working days that don’t match the calendar their organizational booking was built against. This wave also ships bulk reconciliation of bookings directly from the UI, moving from preview to GA on the same September 2026 timeline, and teams adopting task-level calendars should plan to lean on it more than they have before.

Two adjacent features round out the picture. Time-zone-agnostic fields in resource planning, moving to GA in September 2026 after a March 2026 preview, removes a category of timezone-conversion bugs that used to compound whenever a schedule spanned regions, exactly the scenario where task-level calendars get used most. And create time entries from assignment and booking views, previewing in June with GA targeted for October 2026, lets consultants log time directly against the assignment or booking record rather than hunting for the matching project and task separately. It’s a minor convenience on its own, but it matters more once schedules are precise enough that the assignment record reflects when someone was actually supposed to be working.

Implementation guidance for architects rolling this out

The temptation with any new override capability is to use it everywhere, and that’s the wrong instinct here. A WBS where half the tasks carry custom calendars and mixed schedule modes becomes hard for a project manager to read at a glance. The better pattern is to treat task-level overrides as an exception mechanism reserved for tasks with a genuinely different working pattern or a fixed external constraint, and to document why each override exists in the task description field, since the WBS view won’t flag the deviation on its own.

Because both features move through public preview before GA, teams getting ahead of the September 2026 date should validate behavior in a sandbox first, particularly how existing Power Automate flows or custom Dataverse plugins that read schedule fields react to per-task overrides they weren’t built to expect. A plugin assuming every task inherits the project calendar could produce incorrect duration calculations once a subset of tasks references a different one.

Finally, revisit the reconciliation process as part of the rollout, not after problems surface. Teams that have been loose about running bookings-to-assignments reconciliation can get away with it when everything shares one calendar. That gap gets more expensive once task-level calendars are in play, since small drifts can hide inside legitimately different working patterns instead of showing up as an obvious mismatch.

Conclusion

Task-level schedule mode and calendars won’t change how most single-region, single-team projects get built in Project Operations, and that’s fine; they aren’t meant to. Where they matter is on the programs that have always been awkward to model correctly: multi-region delivery, subcontracted work on a different cadence, and milestones anchored to an external party’s calendar rather than the internal team’s. Getting real value out of the change means pairing it with the reconciliation and governance discipline it makes newly necessary, not just flipping the setting on because it’s available. Routeget has been walking clients through exactly that kind of rollout sequencing on active WBS redesigns, and the pattern holds regardless of industry: model the exception deliberately, document it, and verify the resourcing math still adds up before trusting the schedule it produces.

#ProjectOperations #ResourceScheduling #WBSPlanning #TaskLevelScheduling #DynamicsProjectOps #ERPGovernance

The Power Platform CoE Starter Kit Is No Longer Maintained. Here’s What Actually Replaces It.

IT governance director reviewing a Power Platform tenant governance dashboard on an office display

An IT Director at a mid-size manufacturer pulled up her Power Platform governance dashboard last month expecting the usual weekly refresh: new app registrations, a handful of DLP policy violations, a queue of flows awaiting review. Instead she found version numbers that hadn’t moved since February. The Center of Excellence Starter Kit her team built three years ago, the tool that had quietly governed more than 400 apps and flows across the tenant, had gone dormant. Nobody had announced a shutdown. It simply stopped getting updates, and the team only noticed because a routine compatibility check flagged an error the kit’s outdated code couldn’t handle.

That scenario is playing out across a lot of Power Platform tenants right now, because Microsoft has quietly, officially confirmed that the Power Platform CoE Starter Kit is no longer being actively maintained.

IT governance director reviewing a Power Platform tenant governance dashboard on an office display

What Changed With the Power Platform CoE Starter Kit

The language matters here, because a lot of the discussion around this shift has overstated what happened. Microsoft’s own documentation, updated April 30, 2026, states plainly that the Power Platform CoE Starter Kit is no longer actively maintained: issues submitted against the GitHub repository are no longer reviewed, and any genuine security concern should now be routed to the Microsoft Security Response Center rather than the project’s issue tracker. Monthly releases, which had shipped reliably in the first week of nearly every month for years, stopped after February 2026.

That is not the same as a retirement. Microsoft has not published an end-of-life date, has not blocked new deployments, and explicitly states the kit “remains available for both new and existing deployments.” Organizations running it today won’t wake up to a broken environment. What they will face, gradually, is a governance tool that stops keeping pace with platform changes: new connector types it doesn’t recognize, new environment settings it can’t report on, and eventually compatibility issues with Dataverse or Power Automate updates that nobody is fixing on the other side. For a CIO, this is a slower and in some ways more dangerous problem than a hard cutoff, because there’s no forcing deadline to put a migration project on the calendar.

The Native Replacement Microsoft Is Building

Microsoft’s stated direction is to fold CoE-style governance directly into the Power Platform admin center rather than leaving it to a community-maintained Dataverse solution. Four capabilities make up that shift, and they’re at different stages of maturity, which matters for anyone trying to plan around them.

Inventory gives tenant-wide visibility into every app, flow, and now agent across the organization, replacing one of the CoE kit’s original core functions: knowing what exists. Usage entered public preview on February 13, 2026, and Microsoft has targeted general availability for August 2026; it tracks adoption patterns, surfaces top resources and their owners, and sits in the licensing and capacity category of the admin center, which is a signal about where Microsoft sees the primary value: helping organizations understand what they’re actually consuming before a renewal conversation. Monitor, focused on detecting operational health issues across Power Platform resources, entered public preview in August 2026 with no GA date yet confirmed. And Actions, sometimes referred to as Power Platform Advisor, organizes personalized recommendations into four categories: security, operational efficiency, licensing and capacity, and performance, with the ability to remediate inline, automate a fix through Power Automate or PowerShell, snooze non-security items for up to two months, and share a recommendation into Teams for follow-up.

Separately, Microsoft previewed the concept of an “Agentic Center of Enablement” entering public preview in July 2026, framed as a longer-term, AI-driven successor to the CoE model built for a world where agents, not just apps and flows, need governance. It’s worth watching, but it is a preview-stage concept today, not something to build a 2026 governance budget around.

Solution architect reviewing a cloud governance and inventory dashboard alongside code at a dual-monitor workstation

Where the Native Tools Still Fall Short

None of this means the admin center is a drop-in replacement yet, and CIOs who treat it as one will find gaps. Partner analysis from governance specialists who have compared the two toolsets in detail, most notably Rencore’s review of the transition, points to real coverage gaps: shadow IT detection, the app and flow lifecycle and ownership-transfer workflows that let a departing employee’s assets get reassigned cleanly, visibility that spans multiple tenants for organizations with a multi-tenant structure, tracking of DLP policy violations across environments over time rather than as a point-in-time snapshot, and analysis of connector misuse or risky customization patterns. Those were never edge-case features in a mature CoE deployment; they were often the reason the kit got built in the first place.

This is the practical takeaway for anyone budgeting a governance program this year: the native tools are genuinely useful and getting better on a defined Microsoft release cadence, but they are not yet a full substitute for a well-built CoE kit deployment, particularly on the lifecycle and cross-environment tracking side.

What This Means for Budget and Governance Planning

The right response isn’t a rushed migration off the CoE kit, and it isn’t ignoring the situation either. A few decisions are worth making deliberately rather than by default. First, audit what your current CoE deployment is actually doing for you today: which dashboards get used weekly, which automated flows are load-bearing for compliance reporting, and which components have quietly gone unused since they were set up. Second, map that list against the admin center capabilities on their current timeline: Usage moving to GA in August 2026 is close enough to plan around now, while Monitor and the Agentic Center of Enablement are still preview-stage and shouldn’t be treated as committed infrastructure for this fiscal year. Third, price in the hidden cost most organizations forget: the CoE kit runs in its own dedicated Dataverse environment with its own capacity and maintenance overhead, and if native admin center tools can absorb even part of that workload, there’s a real capacity and licensing saving on the table, separate from the governance question entirely.

Finally, don’t assume the gap-filling has to be all-or-nothing. A common pattern emerging among organizations further along in this transition is a hybrid model: keep a thinned-down CoE kit running specifically for the lifecycle, ownership-transfer, and cross-environment tracking that Microsoft hasn’t natively replaced yet, while shifting license and capacity monitoring, security recommendations, and day-to-day operational health checks over to the admin center as those features reach general availability. That approach avoids both extremes: clinging to an aging toolkit out of inertia, or ripping out functioning governance infrastructure before its replacement is actually ready.

There’s also a licensing angle worth surfacing to a CFO, not just an IT Director. Because Usage sits in the admin center’s licensing and capacity category, it’s designed to answer a question most Power Platform tenants can’t currently answer with confidence: which licensed users, premium connectors, and per-flow capacity allocations are actually driving cost, and which are legacy grants nobody has revisited since a pilot project ended two years ago. A CoE kit deployment can surface some of this with custom Power BI reporting built on top of it, but that reporting has to be built and maintained by someone. Getting the equivalent view natively, once Usage reaches general availability, removes a maintenance burden that a lot of governance teams have been quietly carrying for years without budgeting time for it.

The Takeaway for IT Leadership

Governance programs built on the CoE Starter Kit haven’t failed and don’t need to be dismantled this quarter. But they do need a documented transition plan, because “no longer actively maintained” is Microsoft’s way of saying the clock is running even without a published deadline. Organizations that treat this as a planning input now, rather than an emergency later, will have the easier migration. We’ve helped several clients work through exactly this kind of platform transition, mapping existing governance investments against Microsoft’s native roadmap so nothing gets rebuilt twice, and it’s a conversation worth having before a compliance audit forces it.

#PowerPlatformGovernance #CoEStarterKit #DataLossPrevention #LicenseOptimization #PowerPlatformAdmin #EnterpriseAI

Power Pages Server Logic Is GA: Time to Stop Shipping API Keys to the Browser

Solution architect reviewing a secure server infrastructure and API governance diagram on an office display

Every Power Pages solution architect who has built an external-facing portal knows the workaround. A customer portal needs to check inventory in an external warehouse system, validate an account number against a legacy AS/400, or pull a credit score from a third-party service. Client-side JavaScript can’t do that safely, because anything it calls, including the API key or bearer token needed to authenticate the call, is sitting in plain view in the browser’s network tab the moment a curious (or malicious) visitor opens developer tools. For years the answer was to stand up a dedicated Azure Function as a proxy, just to keep a secret out of the page. It worked, but it meant every external integration came with its own deployment pipeline, its own monitoring, and its own set of credentials to rotate somewhere other than the Power Pages site itself.

Power Pages Server Logic, which Microsoft moved to general availability on April 1, 2026 after introducing it in preview the previous October, removes the need for that detour in a lot of cases. It lets developers write server-side JavaScript that runs inside the Power Pages runtime itself, callable from a page but invisible to it. For architects who have been maintaining a small fleet of Azure Function proxies purely to hide credentials, this is worth a real evaluation, not just a note for next quarter’s backlog.

Solution architect reviewing a secure server infrastructure and API governance diagram on an office display

Why the client-side workaround was never actually secure

It’s worth being precise about what Server Logic fixes, because the risk it addresses is easy to underestimate until someone actually demonstrates it. Web roles and table permissions in Power Pages do a solid job of controlling what a visitor can read or write in Dataverse. They do nothing, however, for a call your client-side script makes to an outside system. If that call needs an API key, and the key lives in a JavaScript file the browser downloads and executes, the key is exposed to anyone who opens the console, regardless of how tightly the portal’s Dataverse permissions are configured. Teams have worked around this by obfuscating scripts, by routing calls through Azure API Management with its own key, or by standing up the proxy function described above. All three approaches work, but all three also add infrastructure that has nothing to do with the actual business problem the portal was built to solve.

What Power Pages Server Logic actually executes

Server Logic scripts run in a constrained JavaScript environment, not a full Node.js sandbox. Microsoft’s documentation specifies ECMAScript 2023 compliance with browser-only APIs such as fetch, XMLHttpRequest, and direct DOM access deliberately blocked, along with other patterns considered unsafe for a multi-tenant hosted runtime. In practice, this means a script author can’t accidentally (or deliberately) reach outside the sanctioned execution model the way they could in an open Node environment.

The authoring flow itself lives inside the standard Power Pages workspace. From the site’s Set Up area, a developer selects Server Logic, creates a new entry with a name that also becomes its API resource identifier, assigns the web roles allowed to invoke it, and then opens the code editor directly in Visual Studio Code from that same screen. Each server logic resource is addressed at a predictable endpoint, /_api/serverlogics/<name>, and the script itself maps HTTP verbs to exported functions: get() for reads, post() for creates, put() and patch() for updates, and del() for deletes. That mapping alone tends to push teams toward cleaner API design than the grab-bag of ad hoc client functions many portals accumulate over a few years of incremental requests.

Developer workstation with a code editor and cloud API architecture diagram on dual monitors

Two ways to call it, and they’re not interchangeable

There are two supported invocation paths, and choosing the wrong one for a given scenario creates unnecessary friction. From a client-side script, you call server logic through shell.safeAjax(), which automatically attaches the CSRF token Power Pages requires for authenticated calls originating from the browser. This is the right pattern any time a form submission, button click, or dynamic page interaction needs to trigger the logic in response to something the visitor does.

The second path is the serverlogic Liquid tag, invoked directly inside a Liquid template during page rendering. Because Liquid itself already executes server-side, there’s no CSRF token to manage, and no round trip back to the browser is needed before the result is available to render. This path fits scenarios where a page needs to show data pulled from an external system, or Dataverse data transformed by business logic, as part of the initial page load rather than in response to a later interaction. Architects who default to the client-side call for everything, out of habit, end up adding an unnecessary network hop and a loading-state UI element for content that could have been resolved before the page was even sent to the browser.

The governance settings that decide whether this is safe to turn on

Server Logic ships with a handful of site settings that determine how much latitude the feature has, and a rollout plan should account for all of them before the first script goes live. ServerLogic/Enabled is the master switch, defaulting to true once the capability is available on a site. ServerLogic/AllowedDomains restricts which external hosts a script is permitted to call, which matters because the default behavior otherwise permits outbound calls to any domain. ServerLogic/TimeoutInSeconds caps execution time, defaulting lower but configurable up to 240 seconds for scripts doing heavier data transformation or waiting on a slow upstream API. Perhaps most importantly for security-conscious organizations, tenant administrators retain the ability to block outbound HTTP calls entirely on a per-site basis, which stops a compromised or misconfigured script from being used to exfiltrate data to an attacker-controlled endpoint. None of these settings are exotic, but skipping the review of even one of them before go-live is how a well-intentioned feature turns into a new attack surface instead of closing an old one.

Access itself is still governed by the same web roles and table permissions that already control the rest of the site, which is a deliberate design choice. Server Logic doesn’t introduce a parallel authorization model; it inherits the one your portal already has, so the roles you’ve already defined for a given customer or partner segment carry through to what that segment can trigger.

What this replaces, and what it doesn’t

It’s tempting to treat Server Logic as a wholesale replacement for custom plugin code, but that’s not quite the right mental model. Dataverse plugins written in C# still own the synchronous event pipeline, the true pre-operation and post-operation hooks that fire on record create, update, or delete regardless of which client touched the record. Server Logic operates at the Power Pages layer, invoked explicitly by a page or a Liquid template, not as a reaction to a Dataverse platform event. What it does replace cleanly is the narrower, very common pattern of a proxy built purely to keep a secret off the client: that use case moves into Server Logic with less infrastructure and one less deployment pipeline to maintain.

It’s also worth flagging that Microsoft’s own preview announcement listed several capabilities as planned ahead of general availability, including unbound Dataverse custom API support and a dedicated debugging playground. Given how quickly this ecosystem iterates, architects evaluating a migration should confirm the current state of those specific capabilities against the live Microsoft Learn documentation rather than assuming everything mentioned in the original preview post has shipped by the time they read this.

A practical starting point

For teams carrying one or two Azure Function proxies that exist solely to shield an API key from a Power Pages portal, Server Logic is a reasonable first migration candidate rather than a full platform overhaul. Pick the simplest existing proxy, rebuild its logic as a server logic resource, route the corresponding client call through shell.safeAjax(), and validate the governance settings against your organization’s actual security requirements before promoting it to production. Routeget Technologies has been walking clients through exactly this kind of targeted migration as Server Logic has moved from preview to GA, and the pattern holds regardless of industry: start with the integration that’s easiest to test, confirm the timeout and domain restrictions match what the proxy was already enforcing, and expand from there once the first one is running cleanly in production.

#PowerPages #ServerSideJavaScript #DataversePortals #APIGovernance #PowerPlatformSecurity #LowCodeDevelopment

Dynamics GP End of Life: The Deadline That Actually Matters Isn’t 2029

Finance executive reviewing an ERP migration timeline and dashboard on a boardroom screen

A CFO at a mid-market distribution company pulled up Microsoft’s own lifecycle page during a recent budget meeting and pointed to a single date: December 31, 2029. Three years out. The room relaxed, the Dynamics GP migration got pushed to next year’s capital plan, and everyone moved on to the next agenda item. That reaction is common, and it is also the most expensive assumption a finance organization can make about Dynamics GP end of life, because the date printed on Microsoft’s support page and the date that actually determines your migration cost have very little to do with each other.

What Microsoft Has Actually Published

The published timeline is straightforward enough on its face. Microsoft stopped selling new perpetual Dynamics GP licenses on April 1, 2025, and stopped selling new subscription licenses on April 1, 2026, a milestone that has already passed as of this writing. Mainstream support, which covers product enhancements, hotfixes, and the annual regulatory and tax updates that keep payroll and compliance functions running, ends on December 31, 2029. Extended support, which is limited to security patching, runs until April 30, 2031, after which Microsoft stops renewing Service Plans entirely and organizations cannot add new named users even under an existing perpetual license.

The detail that gets lost in the headline date is the year-end update schedule. The final Dynamics GP year-end update, the one that carries payroll tax tables and statutory reporting changes, ships in December 2029. Any organization still processing payroll or filing statutory reports on GP for the 2030 tax year is doing it without vendor-supplied compliance updates. For a finance team, that is not a software problem anymore. It is an audit and regulatory exposure problem, and it arrives well before the 2031 security cutoff most people assume is the real wall.

Planning Around the Dynamics GP End of Life Timeline, Not the Calendar

Here is where the practical math diverges from the published dates. Implementation firms that track the remaining GP install base have started making a specific argument in public analysis of this transition: a realistic Dynamics GP to Business Central migration, for any organization with meaningful manufacturing, multi-entity, or ISV complexity, takes nine to eighteen months from initial discovery to go-live. That is not a technology estimate so much as a change-management one, and it assumes a partner with available bandwidth and a project team that isn’t fighting for attention against a dozen other clients running the identical calculation at the identical time.

That last part is the actual constraint. Thousands of organizations are still on Dynamics GP, and a meaningful share of them are working from the same 2029 anchor date. If a large portion of that population waits until 2028 to start looking for a migration partner, the market for consultants who have done a GP-to-BC conversion more than once gets tight precisely when demand peaks, and both project cost and timeline suffer for whoever arrives late. None of this shows up in Microsoft’s lifecycle documentation, because it isn’t a Microsoft constraint. It’s a services capacity constraint, and it behaves the way capacity constraints always do: predictably, and badly for latecomers. Treat that as informed industry judgment rather than a vendor-confirmed figure, but it lines up with what most organizations experience whenever a large installed base is forced toward a shared deadline.

What the Migration Tool Actually Moves, and What It Doesn’t

Microsoft’s own GP Company Migration Configuration tooling handles a fair amount of the data conversion automatically, and it is worth understanding the scope before anyone assumes this is a lift-and-shift exercise. On the financial side, it converts fiscal periods into Business Central accounting periods, maps the chart of accounts with GP segments becoming BC dimensions, and brings over summary GL balances for both open and historical years. On the master data side, it migrates customer and vendor records with their addresses, inventory items with costing method and lot or serial tracking intact, checkbooks with unreconciled transactions, and outstanding receivables and payables at their remaining balance. Open purchase orders come across with remaining quantities, and 1099 vendor information migrates for tax years starting in 2024.

What it explicitly does not do matters just as much. Posted transaction history beyond what’s needed to support open balances stays behind. Unit of measure schedules don’t migrate, because Business Central doesn’t have an equivalent concept and only carries individual units of measure. Undeposited cash receipts have to be deposited in GP before the migration runs, and fully received or fully invoiced purchase order lines don’t come across at all. Historical years also land in Business Central still open, and someone has to close them manually afterward rather than assuming the conversion handled it.

None of that is a flaw in the tooling. It’s a reminder that the tool moves data, not business logic, and for organizations with any manufacturing footprint, that distinction is the whole ballgame. Bills of material, routings, production scheduling, shop-floor barcode workflows, and the EDI connections built up over a decade of GP customization don’t show up as rows in a migration mapping table. They have to be redesigned, either as native Business Central configuration or as extensions, and that redesign work, not the data conversion itself, is what consumes most of the nine-to-eighteen-month window described above.

Finance and IT team reviewing an ERP migration project timeline on a large office display

Building the Business Case Before the Window Narrows

A few decisions are worth making now rather than after the next budget cycle. First, inventory every ISV module and third-party add-on currently attached to Dynamics GP, since vendor investment in that ecosystem is already shrinking as those partners redirect their own roadmaps toward Business Central and other platforms, and a module that works fine today may not have a maintained successor by the time your migration starts. Second, decide deliberately how much transaction history actually needs to live inside Business Central versus a low-cost historical archive, since dragging every year of GL detail forward adds conversion effort without changing anything about how the business operates going forward. Third, treat the subscription licensing cutoff as a practical planning input rather than a footnote: because new subscription sales already stopped in April 2026, any organization that hasn’t already secured its Business Central licensing path needs that conversation now, not as a line item to revisit later.

It’s also worth resisting the instinct to replicate GP’s chart of accounts and segment structure exactly as it exists today. Business Central’s dimension model works differently from GP’s segment approach, and a migration is a rare opportunity to simplify a chart of accounts that has usually accumulated more complexity than the business actually needs. Carrying forward every workaround from the old system just because it’s familiar tends to recreate the same reporting friction in a new platform.

The Deadline That Actually Governs Your Timeline

The number that should drive a migration decision isn’t December 31, 2029. It’s the point at which your organization can still secure an experienced implementation partner, complete a realistic discovery-to-go-live cycle, and close out the project before the broader GP install base creates a capacity bottleneck that Microsoft’s support calendar has nothing to do with. In our own conversations with finance and IT leaders working through this decision, the organizations that end up with the smoothest transitions are consistently the ones that started evaluating options well ahead of any hard deadline, because the parts of the project that actually take time, process redesign, ISV replacement, and chart-of-accounts cleanup, are the same parts that no amount of urgency can compress once the clock is closer to running out.

Setting an internal decision point in the next quarter or two, and working backward from a 2027 or 2028 go-live rather than a 2029 support cutoff, is a more honest way to plan than trusting a date on a lifecycle page to tell you when to act.

#DynamicsGP #BusinessCentralMigration #GPEndOfLife #ERPModernization #FinanceTransformation #CloudMigration

Configuring the Scheduling Operations Agent in Dynamics 365 Field Service

Field Service dispatcher reviewing an AI-generated schedule optimization on a control room display with map routes

A dispatcher watching a Field Service schedule board on a Tuesday afternoon knows the pattern well. A technician calls in sick, three appointments need to move, and the promised arrival windows on two of them are already tight. The old workflow is manual triage: scan the board, check who’s nearby, check who has the right certification, and start dragging bookings around while the phone keeps ringing. Microsoft’s answer to that specific moment is the Scheduling Operations Agent, and as of this month it’s rolling out wider public preview capability inside Dynamics 365 Field Service, built to sit on top of Resource Scheduling Optimization rather than replace it.

For technical teams supporting Field Service deployments, the agent is worth understanding now, before it reaches general availability in March 2027 and before dispatchers start asking why their schedule board has a Copilot side pane suggesting changes. This is a configuration and tuning guide aimed at the people who will actually turn it on: solution architects and Field Service administrators who need to know what it touches, what it costs, and where it will quietly produce bad suggestions if the underlying data isn’t clean.

What the Scheduling Operations Agent Actually Does

Standard Resource Scheduling Optimization has existed in Field Service for years as a batch engine: define a scope of resources and requirements, set objectives like minimizing travel time, and let the solver produce a schedule. The Scheduling Operations Agent extends that same underlying optimization logic into two modes that behave very differently in practice.

Interactive optimizations run in the moment. A dispatcher selects one or more resources from the schedule board, the resource list, or the Copilot side pane, and the agent proposes a revised schedule for just those resources, ready for review before anything is applied. This is the mode built for the sick-technician scenario: fast, scoped, and reversible. Batch optimizations are closer to classic RSO, asynchronous runs across a defined scope, goal, and plan, with results either reviewed before applying or applied automatically depending on how the plan is configured. The agent can also be scheduled to run on a recurring basis, which matters for organizations that want a standing overnight optimization pass rather than only reactive adjustments.

What makes this an agent rather than a scheduling report is the layer that interprets what the dispatcher is asking for through natural language in the Copilot pane, and then translates that into a scope, a goal, and a set of objectives and constraints under the hood. The optimization math is the same solver logic Field Service has used for RSO; what’s new is the interface and the ability to trigger narrow, ad hoc runs without building a saved schedule first.

Field Service dispatcher reviewing an AI-generated schedule optimization proposal on a schedule board with a map view

Prerequisites and Licensing That Change the Rollout Math

Before enabling anything, confirm the environment is on Field Service version 8.8.133.214 or later and Universal Resource Scheduling 3.12.149.15 or later, with location and map settings turned on. The feature itself is off by default and gets enabled from Resources, then Scheduling Parameters, then Resource Scheduling, then the Agents tab, where a single toggle turns on both interactive and batch optimizations together. There’s no way to enable one mode without the other, which is worth flagging to a dispatch manager who might want to pilot only the batch side first.

The part that catches architects off guard is billing. Unlike the RSO add-in, which runs as part of the Field Service license, the Scheduling Operations Agent consumes Copilot Studio messages, and those are billed separately through either prepaid capacity purchased as a message pack in the Microsoft 365 admin center, or pay-as-you-go consumption tied to an Azure subscription linked to the Power Platform environment. Both models can run side by side in the same environment, with prepaid capacity drawn down first. A single optimization request consumes messages roughly in proportion to how many resources are included in the run, so a dispatcher who gets in the habit of running interactive optimizations against ten technicians at a time burns through capacity noticeably faster than one running narrow, two-or-three-resource adjustments. Anyone budgeting a rollout should treat message consumption as an operating cost line item, not an afterthought, and set up consumption alerts in the Power Platform admin center before dispatchers get access.

Security Roles and Data Access

Two new security roles govern the feature: Scheduling Operations Agent Administrator, which allows creating, editing, and deleting scopes, goals, and plans, and Scheduling Operations Agent User, which allows running optimizations and viewing results. Administrators typically get the first role, dispatchers the second, and both need a standard Field Service dispatcher role layered on top for baseline access to scheduling tables. There’s a detail here that’s easy to miss during setup: the agent itself runs as an application user inside a Scheduling Operations Agent Team, and that team needs security roles matching what dispatchers have, including any field security profiles in play for column-level security. Skip that step and the agent will silently fail to see the fields it needs to evaluate, producing incomplete or nonsensical suggestions with no obvious error pointing back to the permissions gap.

Tuning Goals, Objectives, and Booking Statuses

Getting useful output out of the agent depends heavily on configuration work that has nothing to do with the agent itself and everything to do with how the environment’s scheduling data is set up. Every booking status needs an explicit optimization method: Optimize for bookings that can be moved or deleted, Do Not Move for anything in progress or with a committed arrival time, and Ignore for canceled bookings the agent should be free to write over. Leave a status unconfigured and it defaults to Do Not Move, which quietly limits what the agent can touch without anyone deciding that on purpose. The same discipline applies to priority values: every priority needs a numeric value from 1 to 100, and Microsoft’s own guidance is to keep the range narrow and distinguishable, something like 1 for low, 10 for medium, and 100 for emergency, rather than spreading values across extremes that cause the solver to fixate on emergency work at the expense of everything else. Notably, the agent ignores the Level of Importance field entirely, so any organization that has been using that field as a proxy for priority needs to migrate that logic into Priority Value before expecting sensible results.

On the goal side, the practical approach is to start narrow: a small resource set, a short time range, and a plan set to review-before-apply rather than auto-apply, so nothing changes on the live schedule while weights are being tuned. Objectives like completing more high-priority work, reducing travel time, and minimizing idle time each take a weight, and the temptation to crank one objective far above the others produces exactly the failure mode you’d expect, schedules that chase priority scores while generating long drives and large idle gaps between bookings. Microsoft’s own tuning guidance recommends starting with similar weights, changing one at a time, and comparing runs before widening scope. That iterative loop, not a one-time configuration, is what actually determines whether dispatchers trust the suggestions enough to keep using the tool past the first week.

Solution architect configuring scheduling optimization goals and constraints in a Dynamics 365 Field Service admin interface

Where It Still Breaks

The agent works online only, with no offline fallback, and prompt detection in the Copilot pane has been tested in English, so multilingual dispatch teams should verify language support before rolling this out broadly rather than assuming parity with other Copilot experiences. Large batch optimizations that pull in thousands of open requirements will run slower and are more likely to hit truncation limits, so requirement views scoped by territory or skill group consistently perform better than one broad query covering the whole operation. And because the agent still respects promised time windows over Do Not Move status, a booking locked to protect it can still get removed if its promise window has already expired, which is a nuance worth documenting for dispatchers who assume “locked” means permanently untouchable.

None of this makes the Scheduling Operations Agent a plug-and-play replacement for dispatcher judgment, and Microsoft is explicit that it’s preview functionality not intended for production reliance yet. What it does offer, for teams willing to do the configuration work now, is a testable path toward faster same-day rescheduling without waiting for the next major RSO batch run. Routeget Technologies has been walking Field Service clients through exactly this kind of pre-GA configuration work, mapping booking status and priority data into a state the agent can actually reason about before the March 2027 general availability date arrives and dispatch teams are expected to already know how it behaves.

#FieldServiceDispatch #SchedulingOperationsAgent #ResourceScheduling #DynamicsFieldService #CopilotStudio #AgenticAI

The AI Builder Copilot Credits Shift Is Rewriting Invoice Automation

Abstract visualization of an AI system extracting structured data fields from a scanned invoice, displayed on an office monitor

A Dynamics 365 Finance and Operations customer running automated AP invoice capture on AI Builder’s invoice processing model will not notice anything different on November 2, 2026. The flow will still trigger, the fields will still extract, and finance will still get its exception queue for anything below the confidence threshold someone set two years ago. What changes on that date is not the model. It is whether the credits paying for every one of those extractions still exist, and for a lot of organizations that built this automation quietly, without anyone tracking which license line item was actually funding it, the honest answer right now is that nobody knows.

Microsoft has been unwinding AI Builder’s original credit system since November 2025, when it stopped selling new AI Builder capacity add-ons, and the second half of what amounts to an AI Builder Copilot Credits transition lands on November 1, 2026: every seeded AI Builder credit bundled into Power Apps Premium, Power Automate Premium, and Dynamics 365 Finance and Operations licenses gets removed on that date. Copilot Credits take over as the funding mechanism going forward, and Microsoft has been explicit on one point: there is no automatic conversion. Whatever balance an organization is sitting on today does not roll into a Copilot Credits balance tomorrow. It has to be purchased separately, allocated deliberately, or the automation simply stops running.

Abstract visualization of an AI system extracting structured data fields from a scanned invoice, displayed on an office monitor

What Actually Sunsets, and What Doesn’t

It’s worth being precise about what this deadline touches, because the shorthand “AI Builder is going away” is wrong and it leads teams toward the wrong response. The invoice processing model, the document processing custom-model tooling, and the AI Builder connector actions inside Power Automate are not being retired. What’s ending is one specific funding source for them. Today, AI Builder actions in Power Apps and Power Automate draw first against AI Builder credits, whether that’s the 500 seeded into Power Apps Premium, the 5,000 in Power Automate Premium, or the 20,000 bundled into a Dynamics 365 Finance and Operations license, and only fall back to Copilot Credits once that pool is exhausted. After November 1, 2026, that first pool disappears entirely for anyone who hasn’t separately purchased an AI Builder capacity add-on before the cutoff, and Copilot Credits become the only meter running. Existing add-on holders get a longer runway, since those add-ons stay valid through their current contract terms even past the end-of-life date, but nobody can buy or renew one after November 1.

How the AI Builder Copilot Credits Rate Table Changes the Prebuilt-vs-Custom Decision

The part of this transition technical teams should actually care about isn’t the deadline itself, it’s the pricing structure underneath it, because it quietly resolves a tradeoff a lot of architects have been living with for years. Under the legacy AI Builder credit system, running a page through the prebuilt receipt or invoice model cost 32 credits, while running that same page through a custom-trained document processing model cost 100 credits, roughly three times as much. That gap pushed a lot of implementations toward the prebuilt invoice model even in cases where a custom model, trained on one vendor’s actual invoice layout, would have extracted fields more reliably. Under Copilot Credits, both capabilities are priced identically at 8 credits per page. The three-to-one penalty for training a custom model is gone.

That’s a real architectural decision point, not a footnote. If an AP automation pipeline has been leaning on the prebuilt invoice model and routing a meaningful share of extractions to manual review because one vendor’s layout doesn’t match the model’s expectations well, whether that’s multi-column line items, remittance details in an unusual spot, or a logo block that confuses the header fields, it’s worth revisiting whether a custom collection trained on that vendor’s actual documents would now clear review automatically instead. The cost argument that used to say no has mostly disappeared, and for high-volume vendors specifically, the accuracy gain from a purpose-trained model can be worth the labeling effort even before factoring in the credit parity.

Reconfiguring the Flow Itself

For teams staying on the prebuilt path, the “Extract information from invoices” action inside the AI Builder connector remains the fastest route to a working pipeline. It returns more than forty fields: invoice ID, vendor name, purchase order, subtotal, tax, and total among them, each in both a raw text form and a standardized number or date form. The standardized fields are the ones worth wiring into a Business Central or F&O AP posting call; the raw text versions exist mainly for audit trails and for surfacing to a human reviewer. Every field also carries its own confidence score between 0 and 1, and the model doesn’t enforce a threshold on your behalf, so that logic has to live in the flow itself. Anything below roughly 0.8 confidence, a starting point worth tuning against your own vendor mix rather than treating as gospel, should route to an approvals step instead of posting automatically. One configuration detail trips up new implementations more than any other: the page-range parameter needs to isolate exactly one invoice per extraction call. Feeding it a multi-invoice batch PDF and letting it run across every page returns fragmented, unusable data, so any intake process that scans a stack of invoices into a single file needs a splitting step before the AI Builder action ever runs.

Solution architect reviewing an automation pipeline diagram and scanned document previews on dual monitors

For teams building or reconsidering a custom document processing model given the new pricing, a few practical constraints are worth knowing before starting. Microsoft’s own guidance puts five documents as the technical minimum to train a collection, but fifteen to twenty is what actually produces usable accuracy, and that number climbs further when the source scans are lower quality. Each collection needs a single, consistent layout, which means a vendor sending three different invoice templates needs three separate collections rather than one, and a model can hold up to 200 collections, generous enough to cover a large and varied vendor base once the labeling work is done properly. High-volume AP operations should also plan around the platform’s processing ceiling of 360 documents per environment every 60 seconds; a month-end batch run that dumps thousands of invoices into a flow all at once will hit that limit and needs to be throttled or staggered rather than fired in a single burst.

Budgeting the Migration Before the Deadline

The practical work between now and November 1 starts with knowing what’s actually being consumed today. The AI Builder Consumption Report in the Power Platform admin center breaks usage down by environment, day, and user, and it’s the fastest way to find out whether a given AP automation flow is currently riding on seeded Dynamics 365 credits, a Power Automate Premium allocation, or an add-on nobody quite remembers purchasing. That figure, recalculated against Copilot Credit rates rather than legacy AI Builder credit rates, is the real basis for a Copilot Credits purchase, not a guess pulled from a vendor conversation. It’s also worth checking whether credits have already been allocated to specific environments in the admin center, because once an environment has an allocation, it only draws against that allocation. There’s no automatic fallback to a tenant-wide pool if it runs dry, which means a production AP flow deserves its own guaranteed allocation rather than sharing an unassigned pool with every sandbox and test environment in the tenant.

The failure mode is also worth testing deliberately rather than discovering it in production. When both AI Builder and Copilot Credits are exhausted, the action doesn’t degrade gracefully; it returns an EntitlementNotAvailable or QuotaExceeded error and the flow run fails outright. For an AP pipeline finance depends on to keep invoices moving, that’s a materially different failure than a low-confidence extraction routed to manual review. It’s a stalled queue with no automatic recovery path until someone notices and tops up credits. Building an explicit fallback now, an error-handling branch that logs the failure and alerts AP operations rather than letting the flow simply stop, is a small addition that avoids a genuinely disruptive incident in November.

None of this is a reason to walk away from AI Builder-based invoice automation, and the pricing shift actually opens up a better architecture for organizations that outgrew the prebuilt model years ago but never revisited the decision. It does mean the flows can’t keep running unattended the way they may have since they were first built. Anyone operating AP automation on this stack should treat the next several weeks as a genuine architecture review rather than a routine licensing renewal, and organizations that have worked through document capture pipelines like this with clients, Routeget Technologies among them, tend to find the credit math is rarely the hard part. It’s the vendor-layout audit and the fallback handling that actually takes the time.

#AIBuilder #CopilotCredits #PowerAutomate #InvoiceAutomation #DynamicsFinanceOps #EnterpriseAI

France’s E-Invoicing Mandate Is Now Live. Here’s What Dynamics 365 Finance Teams Still Need to Check.

Abstract visualization of connected electronic invoices flowing on a monitor in a European finance office, representing the France e-invoicing mandate for Dynamics 365 Finance.

On September 1, 2026, France’s e-invoicing mandate stopped being a future compliance project and became an active legal requirement. Large and mid-sized companies operating in France are now required to issue structured electronic invoices for domestic B2B transactions, and every company doing business in the country, regardless of size, must now be able to receive them. If your Dynamics 365 Finance environment was still treated as “on the roadmap for later this year,” that roadmap has already run out.

This is the third deadline France has set for this reform. The original target was January 2023. It slipped to July 2024, then again to September 2026, and each delay gave finance and IT teams a reasonable excuse to deprioritize the work. That excuse no longer applies. Microsoft shipped the France e-invoicing mandate feature for Dynamics 365 Finance to general availability on July 24, 2026, after a public preview that opened in late April, and the enforcement clock is now running against a live requirement rather than a projected one.

What France’s E-Invoicing Mandate Actually Changed, and What Didn’t

The French reform bundles two distinct obligations that are easy to conflate. E-invoicing covers the structured exchange of invoices for in-scope domestic B2B transactions: sales orders, free text invoices, project invoices, credit notes, and customer prepayment invoices between French entities. E-reporting covers everything that falls outside that scope, including B2C sales, cross-border transactions, and exports, where a full structured invoice isn’t required but transaction data still has to reach the tax authority. A transaction that is exempt from e-invoicing is not automatically exempt from e-reporting, and this distinction is where a lot of otherwise well-prepared finance teams get tripped up during scoping.

The size-based phasing matters too, but not in the way most people assume. Large enterprises and ETIs (entreprises de taille intermédiaire) are the ones on the hook to start issuing compliant e-invoices as of September 1, 2026. Small and mid-sized businesses and micro-enterprises get until September 1, 2027 before they carry the same issuing obligation. What applies to everyone immediately, regardless of size, is the receiving requirement: any company transacting in France must be capable of accepting a structured electronic invoice today. A smaller French subsidiary that assumes it has another year of breathing room is only half right, and the part it got wrong is the part most likely to cause a stalled transaction with a supplier who has already moved to full compliance.

What Microsoft Actually Built Into Dynamics 365 Finance

The GA feature routes outbound and inbound invoices through the Electronic Reporting framework inside Globalization Studio, using pre-built configurations for the French electronic invoice format and its associated status reporting. Invoices are transmitted in a UBL-based structure aligned to the EN 16931 European standard, and the system enforces the mandatory lifecycle statuses that French regulation requires: an invoice has to move through states such as deposited, refused, and payment received, with status round-trips flowing back into Dynamics 365 rather than living only on the transmission platform. On the inbound side, vendor electronic invoices arrive through the same integration and land in Finance as structured documents rather than PDFs that someone has to key in manually.

The transmission itself runs through EDICOM, which functions as what the French system calls a plateforme agréée, or approved platform, the current designation for the state-registered platforms that handle invoice validation, formatting, and delivery to both trading partners and the tax authority’s central directory. Businesses don’t submit invoices directly to the government portal. The approved platform does that on their behalf, which is the architectural reason Microsoft built its out-of-box configuration around a specific provider rather than a generic connector.

The Part That Deserves More Scrutiny Than It’s Getting

Here is the catch that a lot of go-live plans are glossing over: Microsoft’s out-of-box configuration is built specifically around EDICOM, and the Globalization Studio artifacts, the electronic reporting formats, the response processing logic, name EDICOM directly rather than treating it as one interchangeable option among the more than 120 platforms France has approved. For an organization that wants to standardize on a different provider, whether for existing commercial terms, regional coverage, or an established relationship elsewhere in the business, implementation partners working with early adopters have described the effort to extend the configuration to a second platform as a genuine build project, involving new XML format work and direct API integration with that provider, not a parameter change in a setup form.

There’s also a cost dimension that’s easy to miss because it sits outside the base ERP license. Electronic Invoicing in Dynamics 365 Finance is a metered add-on service that requires separate enrollment even for organizations already licensed for Finance, Supply Chain Management, or Project Operations, and it’s billed on transaction volume rather than bundled into the platform subscription. One Microsoft partner’s published implementation analysis pegged the metering at roughly $300 per 1,000 transactions per tenant per month, with response and status submissions counted as separate billable events from the original invoice, on top of whatever commercial fee the approved platform itself charges. Those figures will vary by contract and shouldn’t be treated as a universal rate card, but the structural point holds regardless of the exact number: this is a usage-based cost line that finance leaders should be sizing against actual invoice volume before assuming the feature is a simple checkbox to enable.

What to Verify This Quarter

A finance professional reviewing an electronic invoicing compliance dashboard on a monitor in a modern office.

Given that enforcement is already active, the practical task for finance and IT leadership isn’t deciding whether to comply. It’s confirming that what’s configured actually matches what the business needs, before a blocked transaction or a failed status round-trip surfaces the gap for you. Start by confirming receiving capability is genuinely live in production, not just configured in a sandbox, since that obligation applies to every size of business as of the September deadline that has already passed. Next, walk through your actual transaction mix against the e-invoicing versus e-reporting boundary described above, because it’s common to find that project invoices or prepayment transactions were left out of the initial scope simply because they’re less frequent than standard sales orders. Confirm which legal entities in your Dynamics 365 environment are actually in scope based on size thresholds, and don’t assume a smaller subsidiary is safe until 2027 without checking whether it crosses the ETI threshold on a consolidated basis. Finally, if EDICOM isn’t already your organization’s platform of choice for other reasons, have an honest conversation now about whether standardizing on the out-of-box provider is the pragmatic choice for this deadline, with a migration to another platform evaluated later as a deliberate project rather than something attempted under deadline pressure.

France won’t be the last major economy to force this kind of structural change into how ERP systems handle invoicing. Similar mandates are already active or advancing in Poland, Germany, and elsewhere in the EU, and organizations that build a repeatable internal process for evaluating and validating these Globalization Studio configurations, rather than treating each country as a one-off fire drill, will spend less time scrambling the next time a deadline like this one arrives. Routeget Technologies has worked through several of these localization rollouts alongside finance teams who needed the configuration validated against their real transaction data rather than just the release notes, and that verification step is usually where the actual risk gets found.

#FranceEInvoicing #D365FinanceCompliance #ElectronicInvoicing #TaxCompliance #ERPGovernance #EUTaxReform

Export to Data Lake Migration: Fabric Link or Synapse Link Before the November Cutoff

Cloud data architecture visualization showing data streams flowing through an enterprise server environment, representing Dataverse and Azure data lake integration

Somewhere in your Dataverse environment, or bolted onto Dynamics 365 Finance and Operations through Lifecycle Services, there is probably a data pipeline that has been quietly exporting records to Azure Data Lake Storage for years without anyone touching its configuration. That pipeline stops working for good on November 30, 2026. Microsoft has confirmed there will be no further extensions past that date, which means any architect or BI team still running the legacy Export to Data Lake add-in needs an Export to Data Lake migration plan in motion now, not a vague intention to “look at it before year end.” With roughly eleven weeks left on the clock as of this writing, the practical question is not whether to move, but which of the two supported replacements to move to, and what actually breaks in the schema when you do.

The confusion around this deprecation runs deeper than most Microsoft retirements, largely because the naming has changed twice in the last two years and the marketing language has blurred two genuinely different services into one. It is worth being precise about what is actually going away before touching any configuration.

What Is Actually Being Retired

Export to Data Lake, the LCS-installed add-in that let finance and operations apps write entity data directly into a customer’s Azure Data Lake Storage Gen2 account, was marked deprecated back in October 2023 and stopped accepting new adopters on November 1, 2024. What has not been widely understood is that existing customers were allowed to keep running it on a grace period, and that grace period ends permanently on November 30, 2026. After that date, no further data lands in the lake through that pipeline. Downstream Synapse pipelines, Power BI datasets, and any custom ETL jobs reading from that storage account simply stop receiving updates, with no error thrown anywhere obvious enough to trip an alert.

What is not retiring, despite frequently being confused with the legacy add-in, is Azure Synapse Link for Dataverse itself. Microsoft has stated plainly that Synapse Link is a long-term supported service. The naming has shifted again as of the July 2026 UX refresh: the feature is now presented under a unified “Link data” page in Power Apps, split into “Fabric Links” as the recommended path and “Other Links” covering the Azure Synapse option. If your team has been searching documentation for “Export to Data Lake” and finding nothing current, that rename is why.

Cloud data architecture visualization showing data streams flowing through an enterprise server environment, representing Dataverse and Azure data lake integration

Fabric Link or Synapse Link: The Decision That Actually Matters

Once the rename is out of the way, the real architectural decision is between two genuinely different integration models, and picking the wrong one for your organization’s actual downstream consumers is the most common mistake we see in migration planning.

Link to Microsoft Fabric is a no-copy model. Data stays inside Dataverse’s managed storage and is exposed to Fabric and Power BI through OneLake shortcuts rather than being physically copied into a separate account you control. Setup is fast: a four-step wizard handles workspace identity authentication (now the recommended method over service principals, since Microsoft’s own release notes describe it as removing “the most common Fabric link setup failure mode”), table selection, and initial sync, which typically completes within about sixty minutes for moderate data volumes. The tradeoff is that you do not own the underlying storage account, table selection for non-system tables is largely automatic rather than admin-curated, and any custom pipeline tooling outside the Microsoft Fabric ecosystem has no direct file-level access to the data.

Azure Synapse Link for Dataverse, by contrast, continuously exports data as Delta Parquet files into a storage account your organization owns and controls. If your analytics estate depends on non-Microsoft tools, custom Spark jobs reading raw Parquet, or an existing Synapse workspace with pipelines your team has already built and tuned, this is almost always the correct choice, and it remains fully supported going forward. The tradeoff is that you take on more operational responsibility: managing the storage account, its firewall rules, and eventually a private endpoint migration if your organization needs one (a related but separate deadline, the trusted-services firewall exception for private link configurations, retires August 1, 2027, so build that into planning if it applies to you).

Where the Export to Data Lake Migration Breaks Existing Pipelines

This is the part of the Export to Data Lake migration that catches teams off guard even after they have chosen a replacement path, because the schema produced by Fabric Link and Synapse Link is not a drop-in replacement for what the legacy add-in produced. Several changes will break any downstream job written against the old CSV-based output.

The most disruptive change for finance and operations data is that the primary identifier field, previously exposed simply as ID, is now surfaced as FnO_Id. Any view, stored procedure, or Power Query step that hard-codes the old column name will fail or silently return nulls after cutover, and this is worth grepping for across your entire analytics codebase before you flip the switch, not after. Time zone identifier (TZID) fields, which were largely unused legacy artifacts in the old export anyway, have been dropped entirely. Binary data columns are no longer included in the export at all, and nvarchar(max) fields are truncated at 2,000 characters, which matters if any process was relying on long free-text fields such as notes or descriptions coming through intact. On the positive side, the new format adds a proper isDelete flag for row-level soft-delete tracking, which the legacy CSV export never handled cleanly, so reconciliation logic that used to infer deletions by diffing snapshots can often be simplified.

There is also a prerequisite that trips up more migrations than the schema differences themselves: only tables with the Track Changes property enabled will appear as selectable in either Fabric Link or Synapse Link. A meaningful number of legacy finance and operations entities were never configured for change tracking, and some cannot have it enabled without developer involvement to extend the entity definition. Audit which tables your current pipeline depends on and confirm change tracking status on each one before you assume the new link will simply mirror what you already have.

Solution architect reviewing a cloud data pipeline migration diagram on a monitor in an office setting

Sequencing the Cutover Without a Data Gap

The safest sequencing we recommend is to stand up the replacement link in parallel with the legacy export while both are still functional, rather than decommissioning the old pipeline first and troubleshooting the new one under deadline pressure. Run both for at least one full reporting cycle, ideally a month-end and quarter-end close if the data feeds financial reporting, and reconcile row counts and key totals between the two outputs before cutting anything over. Microsoft’s FastTrack team publishes two open-source transition tools worth using rather than building your own equivalents from scratch: a SQL Analytics Endpoint tool for validating Fabric Link output against expectations, and a Virtual Data Warehouse tool for Synapse Link migrations. Both are available through the Dynamics 365 FastTrack Implementation Assets repository and can shortcut a meaningful amount of validation work.

Two configuration details are also worth checking before you commit to a path: profiles that were originally set up in CSV format cannot be linked forward to Fabric, and profiles secured with managed identities have the same restriction. Both require a fresh setup rather than an in-place conversion, so factor that into your timeline if either applies to your current configuration. Once the new link is validated and running cleanly, the legacy Export to Data Lake add-in itself should be formally uninstalled through Lifecycle Services rather than simply left dormant, both to avoid confusion for the next person who inherits the environment and to remove a component that will stop functioning anyway once November 30 passes.

Where This Leaves Architecture Teams

None of this is a difficult migration in isolation. A Fabric Link setup for an organization with modest data volumes and no custom storage requirements can realistically be completed in a day, including validation. What makes this deprecation worth taking seriously now rather than in October is the schema drift buried inside it: the ID field rename alone is enough to quietly break a Power BI model or a downstream integration that nobody has looked at closely in over a year. We have walked several clients through this exact transition at Routeget Technologies, and the pattern holds consistently: the technical setup is fast, but finding every place the old schema was assumed to be permanent takes the real time. Start that inventory now, while there are still weeks to spare rather than days.

#ExportToDataLake #AzureSynapseLink #MicrosoftFabric #DataverseIntegration #CloudArchitecture #ERPGovernance

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