The Warehouse App V3 to V4 Migration Is an Infrastructure Project, Not an App Update

Warehouse worker scanning a barcode with a handheld mobile device in a distribution center

A distribution center running a fleet of Zebra handhelds on the Warehouse Management mobile app got a call from the floor supervisor in late July: barcode scans on inbound receiving were suddenly failing on about a third of devices, right after an over-the-air Android update pushed through despite the fleet being enrolled in Intune with update deferrals configured. The IT team opened a support ticket. The answer that came back wasn’t a patch. It was a reminder that the app on those devices, version 3, had been out of support since May, and the fix wasn’t going to be a hotfix to V3. It was going to be the V3 to V4 migration the team had scheduled for “sometime in Q3” and then quietly let slide.

That scenario is playing out at more distribution operations than Microsoft’s release notes would suggest, because the framing around this migration has made it sound smaller than it is. Under the hood, this isn’t a UI refresh. Microsoft rebuilt the Warehouse Management mobile app from scratch, moving it off Xamarin, a framework Microsoft itself retired from general support back in 2024, and onto React Native. That single architectural fact explains almost everything else about why this migration behaves differently from a normal app update, and why solution architects planning a fleet rollout need to treat it as an infrastructure project rather than an app-store bump.

Why This Isn’t a Simple App Update

Xamarin’s own end of life is the real driver here, not a desire to add dark mode. A framework built on Mono and .NET for cross-platform mobile development, Xamarin stopped receiving Microsoft support in May 2024, which put every product still built on it, including the warehouse app, on a clock. React Native gets Microsoft a modern, actively maintained foundation, and it shows up concretely in the release cadence: since V4’s staged rollout completed in early 2026, point releases have shipped roughly monthly, each carrying real functional changes rather than just security patches.

The rewrite also changed the authentication stack, replacing legacy libraries with MSAL and OneAuth, and that change has consequences that have nothing to do with barcode scanning. On Windows, the redirect URI registered in Azure AD app registrations needs to include ms-appx-web://microsoft.aad.brokerplugin/{clientId} for the broker flow to work. For on-premises deployments authenticating through AD FS, both Windows and Android need new redirect URIs registered before a single device can sign in to V4, which means this migration touches identity configuration owned by a different team than the one running the warehouse floor, and that handoff is where a lot of rollouts stall.

Abstract visualization of a mobile device platform migration on a handheld scanner screen

What Actually Breaks During a V3 to V4 Migration

Three things trip up fleet migrations that the high-level release notes gloss over, and all three are worth budgeting time for before a rollout window opens rather than during it.

The first is device eligibility. V3 supported Android 5 and later, while V4 requires Android 7. Any handheld still running Android 5 or 6, which is not unusual in a warehouse fleet with a five-to-seven-year hardware refresh cycle, simply cannot run V4 and has to keep running V3 until it’s replaced. That forces a mixed-fleet reality during the transition window: V3 and V4 can run side by side on different devices without conflict, but they cannot coexist on the same device, so the migration has to be planned and executed per device, not as a single global cutover.

The second is the iOS experience, which behaves noticeably worse than Android or Windows during migration. On those two platforms, connection settings carry over automatically from V3 to V4 as long as the device was already on V3 version 3.0.8 or later before the switch. On iOS, none of that carries over. Every connection has to be manually reconfigured after installing V4, and Device Code authentication, which a lot of iOS deployments relied on, isn’t supported in V4 at all; iOS is limited to username and password. The practical workaround worth building into a migration plan is generating QR codes or JSON configuration files ahead of time for each site or device group, so floor staff aren’t hand-typing server URLs and warehouse codes on a phone screen during a go-live window.

The third is the support-window structure itself, which changed again after V4 launched. Starting with version 4.1.1.0, Microsoft introduced a rolling twelve-month support window, effective May 2027, meaning only V4 releases published within the previous twelve months are eligible for support at any given time. A fleet migrated to V4 in early 2026 and left untouched will fall out of that support window well before 2027 arrives, so the actual deliverable of this project isn’t “get to V4.” It’s “get to V4 and keep a patch cadence going,” which is a different kind of ongoing commitment than most IT teams budget for an app migration.

A Practical Migration Sequence

The sequence that has worked cleanly across the fleet migrations worth learning from starts with an inventory, not an install. Pull every device’s current OS version and current app version before scheduling anything, because that inventory determines three separate migration paths: devices already eligible for direct upgrade, devices that need a V3 update to 3.0.8 or 3.0.9 first to preserve their configuration, and devices that need hardware replacement before they can run V4 at all.

For the Android and Windows devices in the first two paths, the upgrade itself is close to routine: push the V4 install through Intune or another MDM tool without uninstalling V3 first, since choosing the in-place upgrade path is what preserves the existing connection settings. Stage this in waves by site or by shift rather than as a single fleet-wide push, because the one-time reauthentication requirement per device means a help desk fielding sign-in questions from three hundred devices simultaneously is a bad night for everyone involved, whereas fifty devices at a time is manageable.

For iOS, treat it as its own project inside the larger migration rather than an afterthought. Confirm every affected user has username and password credentials provisioned before the cutover, since Device Code won’t be available as a fallback. Build the QR code or JSON configuration files in advance, and consider disabling auto-update on iOS devices until those configuration artifacts are ready, so a device doesn’t land on V4 mid-shift with no way to reconnect.

Keep the rollback path in mind but don’t lean on it as a safety net for the whole fleet. Individual devices can be downgraded to V3.0.9 if V4 surfaces a blocking issue during testing, which is useful for a pilot group, but Microsoft has been clear that once a region has fully migrated, that region-level rollback isn’t available. Pilot on a genuinely small, representative slice of the fleet, not just the devices sitting on IT’s desk.

Closing the Loop After Go-Live

The migration doesn’t end when the last device reports in on V4. Recent point releases have shipped capability that’s worth actively adopting rather than ignoring once the fleet is stable: a ProGlove arm scanner bridge for hands-free scanning workflows, editable client settings that let enterprise environments enforce TLS 1.2 and forced sign-in policies centrally, and expanded barcode format support including GS1 batch number separators that some receiving workflows depend on. None of that shows up automatically; it requires staying inside that rolling twelve-month support window Microsoft built into the V4 support model, which means assigning someone ownership of the update cadence the same way a team would own patch management for any other production system.

Routeget has run this exact device-inventory-first sequencing for several clients moving mixed Android and iOS fleets this year, and the pattern holds: the migration itself is mechanical once the inventory and identity prerequisites are sorted out. What actually determines whether it goes smoothly is whether someone treated it as an ongoing operational commitment from the start, rather than a one-time app-store update to check off a list.

#WarehouseManagementApp #DynamicsSCM #MobileFleetMigration #XamarinToReactNative #ERPGovernance #SupplyChainAutomation

Business Central’s Outlook Integration Deadline Is October 1, 2026

IT professional reviewing an email and calendar dashboard, representing Business Central Outlook integration

An IT Director at a distribution company we work with found out about this deadline the way most people do: from a support ticket, not a Microsoft email. A sales rep’s Outlook add-in stopped letting her attach a quote from Business Central mid-thread, and the contact she’d synced from BC to Outlook six months ago had quietly vanished from the folder it used to sit in. Nothing had changed on her machine. What had changed was that her company’s Business Central environment was still two release waves behind, and Microsoft had already started tightening the plumbing underneath a feature nobody in IT had flagged as fragile.

That plumbing is Exchange Web Services, the aging protocol Outlook add-ins and contact sync in Business Central have leaned on for over a decade. Microsoft is retiring it, and the resulting Outlook integration deadline that Business Central’s own product team has set is considerably firmer than the platform-wide retirement schedule most IT leaders have heard about. If your organization runs Business Central and anyone in sales, purchasing, or accounting touches customer or vendor contacts through Outlook, this is worth twenty minutes of your attention before the end of the month.

IT professional reviewing an email and calendar dashboard, representing Business Central Outlook integration

What’s Behind the Outlook Integration Deadline

Exchange Web Services, usually shortened to EWS, is the API that has quietly connected Outlook to a long list of Microsoft and third-party applications since the mid-2000s. Microsoft first announced its deprecation back in 2018, but the timeline accelerated meaningfully after the Midnight Blizzard security incident in January 2024 pushed the company toward faster retirement of legacy authentication and API surfaces across Exchange Online. The result, as published by the Exchange engineering team, is a phased shutdown: EWS begins to be disabled globally starting in October 2026, with full disablement across all tenants by April 2027.

Business Central’s product group didn’t wait for that full window to close. Because the older Exchange-based contact synchronization and Outlook add-in deployment in Business Central depend directly on EWS calls, the team attached a much nearer deadline to its own 2026 release wave 1 features: organizations need to be on Business Central version 28.0 or later, and Microsoft has stated plainly that after October 1, 2026, Outlook add-in functionality and contact sync built on the older Exchange connection may stop working in earlier versions. That is a considerably tighter window than the broader EWS retirement calendar, and it is the one that actually matters if you’re planning around this.

What Breaks in Practice, Not in Theory

For a company still running a pre-28.0 version, the practical failure points are the ones your sales and finance teams touch daily rather than anything IT usually monitors. The Outlook add-in that lets a salesperson pull up a customer’s Business Central record, attach a quote, or check open invoice balances without leaving their inbox depends on that Exchange connection to authenticate and retrieve data. The legacy Exchange Sync. Setup page, which many mid-market Business Central customers configured years ago and then never touched again, uses EWS to keep a “Business Central” folder of synced contacts current in each user’s Outlook. Automatically tracking email correspondence against a customer record, a feature accounting and account management teams tend to rely on more than they realize until it’s gone, runs through the same plumbing.

None of this fails with a dramatic outage. It fails quietly: an add-in that used to load now times out, a contact that used to sync now sits stale, an email that used to log itself against a customer record now just sends. That’s a worse failure mode for a CIO to manage than a hard outage, because it doesn’t generate an incident ticket. It generates a slow trickle of user complaints that get diagnosed as one-off glitches for weeks before anyone connects them to a platform deprecation that IT technically knew about.

Abstract visualization of data synchronization flowing between two connected systems on a laptop screen

What Version 28 Actually Replaces It With

Business Central 2026 release wave 1, generally available since April 1, 2026 and auto-enabled for all users on that version, rebuilds this integration on Microsoft Graph instead of EWS. The most visible change is a new “Synchronize with Outlook” action added directly to the Contacts list, which copies selected contacts from Business Central into Microsoft 365, making them usable in both Outlook and Teams. Unlike the old Exchange Sync. Setup configuration, which required a separate admin setup flow and validated an Exchange connection before anything would sync, this action sits where sales and account teams already work, and it supports syncing in either direction if an organization wants contacts created in Outlook to flow back into Business Central.

The other change worth flagging to your security and IT operations teams directly is that Outlook add-in installation now requires a one-time additional setup step to verify the account, a deliberate friction point Microsoft added for account protection reasons rather than a bug. If your organization uses centralized deployment to push the Business Central add-in to users automatically rather than relying on individual installs, that deployment process still works, but the added verification step means it is worth testing the rollout against a pilot group rather than assuming a push that worked in 2025 will behave identically in 2026.

Who Is Actually at Risk

If your Business Central environment is a standard SaaS deployment on Microsoft’s evergreen update cadence, there’s a reasonable chance you’re already on version 28.0 or close to it, since Microsoft pushes two release waves a year to every SaaS tenant on a schedule customers don’t fully control. The organizations that should be checking their version today rather than assuming they’re covered fall into a narrower but not small group: companies running Business Central on-premises, where upgrades are a deliberate IT project rather than an automatic platform event; companies that migrated from Dynamics GP, NAV, or SL in the last two years and may still be running an early post-migration version they haven’t touched since go-live; and any organization that has deliberately delayed a release wave update because of a customization or third-party integration compatibility concern, which is common enough in manufacturing and distribution environments with heavily extended BC implementations.

Checking your version takes a few minutes: in Business Central, the Help and Support page shows the current version and build number directly, and any IT Director who can’t answer “what release wave are we on” from memory should treat that itself as a minor governance gap worth closing regardless of this specific deadline.

What to Do Before October 1

The organizations that will sail through this deadline without incident are the ones treating it as a two-part check rather than a single upgrade task. The first part is confirming the Business Central version itself, since anything at 28.0 or later already has the Graph-based integration and doesn’t need to do anything further beyond being aware the old Exchange Sync. Setup pages are being phased out and shouldn’t be reconfigured going forward. The second part, and the one that gets missed, is validating that Outlook add-in deployment and any automated email-tracking workflows actually work end to end after an upgrade, not just that the version number changed. An upgrade that technically completes but leaves the add-in’s new security verification step unaddressed for most users produces the same quiet failure pattern as not upgrading at all, just with a shorter fuse. For any organization using EWS-dependent integrations beyond Business Central itself, Microsoft’s own EWS Usage Reports in the Microsoft 365 admin center are worth a look this month, since Business Central is rarely the only application in a tenant still calling that API.

None of this requires a large project. It requires someone in IT confirming a version number, someone in sales or finance confirming the add-in still authenticates cleanly, and roughly three weeks of runway that is shrinking by the day. Routeget Technologies has walked several clients through exactly this check in the past month, and in every case the fix was smaller than the anxiety the deadline initially produced, provided someone looked at it before October 1 rather than after.

#BusinessCentral #OutlookIntegration #ExchangeWebServices #ERPGovernance #Microsoft365Integration #DynamicsMigration

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

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