IoT Intelligence Is Out in Dynamics 365 Asset Management. Sensor Data Intelligence Moves the Azure Bill to You.

IT operations manager reviewing an asset health and sensor monitoring dashboard in a manufacturing control room

An IT director running Dynamics 365 Supply Chain Management for a mid-size manufacturer recently got a message she wasn’t expecting: the IoT feature her maintenance team had been quietly piloting inside Asset Management was being replaced. Not patched, not extended. Replaced, with a new name, a new architecture, and a new owner for the Azure infrastructure underneath it. Microsoft’s own documentation is blunt about it: “Do not start any new projects based on the existing IoT Intelligence feature.” The successor, Sensor Data Intelligence, is where new work is supposed to go instead.

This isn’t a minor renaming exercise. It’s a genuine shift in who is responsible for the cloud plumbing behind predictive maintenance in Dynamics 365, and it lands squarely on any organization that has connected sensors, meters, or PLCs to Asset Management, or has been planning to. For CIOs and IT directors weighing whether to invest in condition-based maintenance on the Dynamics 365 platform, the mechanics of this transition matter more than the rebrand suggests.

What Actually Changed

IoT Intelligence was the original bridge between physical assets and Asset Management inside Dynamics 365 Supply Chain Management. Sensor readings, whether from a vibration monitor on a pump or a temperature probe on a cold-storage unit, flowed into Azure IoT Hub and then into Supply Chain Management, where they could trigger alerts, feed maintenance plans, or update asset condition records. Critically, Microsoft managed much of that Azure infrastructure on the customer’s behalf. It worked, but it was rigid: limited room to customize the data pipeline, and friction when a customer wanted to bring in sensor data from a system that wasn’t a clean fit for the prebuilt model.

Sensor Data Intelligence, now in preview and documented as an updated, renamed version of IoT Intelligence, rebuilds that pipeline with a different deployment philosophy. Instead of Microsoft hosting and managing the Azure components, the organization deploys them into its own Azure subscription. Setup runs through an onboarding wizard rather than the manual configuration in Lifecycle Services that IoT Intelligence required. On paper, that is a usability improvement. In practice, it also means the Azure resources involved, connecting sensors through Azure IoT Hub and the broader industrial IoT ingestion pattern Microsoft points customers toward, now belong to the customer’s tenant, not Microsoft’s.

Wireless industrial sensor mounted on factory equipment with a technician viewing vibration data on a tablet

Why Microsoft Restructured It This Way

The stated reasons are customization and integration. A Microsoft-managed pipeline is easy to stand up but hard to bend. Organizations that wanted to route sensor data through an existing Azure Digital Twins model, apply their own retention and encryption policies, or connect equipment from a vendor whose telemetry format didn’t match the built-in assumptions were working against the platform rather than with it. Moving deployment into the customer’s own subscription removes that ceiling. It also happens to align with a broader pattern across the Dynamics 365 and Power Platform ecosystem this year, where more of the underlying Azure footprint is being handed to customers to own and configure directly, rather than abstracted away entirely.

That tradeoff is worth naming plainly, because it changes who needs to be in the room for this decision. Adopting Sensor Data Intelligence is no longer purely a Dynamics 365 configuration project that a functional consultant can carry alone. It is an Azure architecture decision, and it needs a cloud engineering resource involved from the start, someone who can make calls about network isolation, subscription structure, and how sensor telemetry ingestion fits into the organization’s existing Azure governance model.

The Six Scenarios Sensor Data Intelligence Is Built Around

Microsoft’s documentation frames the preview around six specific business scenarios, and each one maps to a different maintenance or production pain point rather than being a generic “connect your sensors” pitch. Asset downtime tracking uses sensor readings to measure actual machine efficiency against expected performance, giving maintenance planners a real-time efficiency signal instead of relying on manually logged downtime events after the fact. Asset maintenance ties incoming sensor readings directly to the goal of reducing maintenance cost, which in practical terms means condition data can inform when a maintenance plan should actually trigger rather than running purely on a fixed calendar schedule. Machine status notifications alert production planners the moment equipment goes down, cutting the lag between a physical failure and a scheduling response. Product quality scenarios compare live sensor readings against defined quality thresholds, catching drift before it turns into a batch of rejected output. Production auto-reporting uses sensor thresholds to automatically report finished quantities, removing a manual data-entry step from the shop floor. And production delay tracking compares actual cycle time against planned cycle time, surfacing bottlenecks that would otherwise only show up after the fact in a variance report.

None of these six scenarios require a from-scratch build. They come as templates within the new model, which is a meaningful head start for organizations that don’t have the internal bandwidth to design an IoT-to-ERP data pipeline from first principles. But a template is not the same as a finished solution, and each one still needs to be mapped against the specific sensors, thresholds, and maintenance workflows already in place at a given plant.

What Belongs on a Decision-Maker’s Checklist

The preview status is the first thing worth sitting with. Microsoft’s own terms are explicit that preview features aren’t meant for production use and carry restricted functionality, so any organization currently relying on IoT Intelligence for live maintenance decisions is not looking at a drop-in replacement they can adopt today. They are looking at a migration to plan for, on a timeline Microsoft has not published in its formal deprecation schedule. Checking Microsoft’s removed and deprecated features documentation for Supply Chain Management shows plenty of other retired capabilities listed with version numbers and dates; IoT Intelligence, as of this writing, is not one of them. That gap between “don’t build new things on this” and an actual scheduled retirement date is exactly the kind of ambiguity that should push a cautious organization toward an early conversation with Microsoft or its implementation partner rather than a wait-and-see approach.

Budget conversations need to happen earlier than usual, too. When Microsoft manages the Azure components behind a feature, the cost of that infrastructure is effectively invisible to the customer, folded into the overall service. Once the deployment sits in the customer’s own subscription, IoT Hub throughput, storage, and any downstream compute for the sensor data pipeline become line items the organization has to provision, monitor, and pay for directly, governed by whatever cost management and tagging discipline already applies to the rest of its Azure estate. That is not necessarily a bad outcome. Full ownership of the infrastructure also means full visibility into what it costs and full control over where it runs, which matters for organizations with strict data residency or network segmentation requirements that a Microsoft-managed black box never let them satisfy cleanly.

Finally, this is a good moment to audit what IoT Intelligence usage already exists in the environment, even informally. A maintenance team that connected a handful of sensors as a proof of concept two years ago may not have flagged that project to IT as a dependency, and a preview migration is the wrong time to discover a shadow deployment that nobody owns.

The Bigger Pattern Behind the Rename

Sensor Data Intelligence is a small feature in the context of the broader Dynamics 365 Supply Chain Management platform, but it is a clear example of a decision Microsoft is making more often across the ecosystem: put the Azure infrastructure in the customer’s hands and trade managed simplicity for architectural control. That is generally the right long-term direction for organizations with mature cloud governance. It is a heavier lift for organizations that treated Dynamics 365 as a self-contained ERP system and never built out the Azure engineering capability to match. Teams at Routeget Technologies that have supported Asset Management deployments through platform transitions like this one typically start by mapping the existing sensor footprint and the target Azure subscription model before touching the Sensor Data Intelligence onboarding wizard itself, since getting that architecture right the first time avoids a second migration a year later.

#AssetManagement #SensorDataIntelligence #IoTinERP #PredictiveMaintenance #AzureGovernance #SupplyChainAutomation

Cross-Legal-Entity Fulfillment Enters Preview. Your Intercompany Setup Determines If It Works.

Operations team reviewing a network map dashboard showing warehouse fulfillment locations across a distributed retail supply chain

A retail operations director looks at a stalled online order and sees the maddening part immediately: the product is in stock, just not in the legal entity that took the sale. This happens constantly inside multi-entity retail and distribution organizations, the kind that grew by acquisition, by regional incorporation, or simply because tax and banking realities forced separate companies to hold separate inventory. To the customer, it looks like one brand. To Dynamics 365, it looks like several unrelated companies, each with its own stock ledger, unable to see past its own four walls without someone picking up a phone and negotiating a manual intercompany purchase order. Microsoft’s new cross-legal-entity fulfillment capability, built on top of Distributed Order Management (DOM), is aimed squarely at that gap. It reached private preview in version 10.0.48 this past August, with a public preview following in 10.0.49, and it is worth a serious look from any finance or operations leader running Dynamics 365 across more than one legal entity.

What Cross-Legal-Entity Fulfillment Actually Changes

DOM itself is not new. Dynamics 365 Commerce has used it for years to solve a narrower version of this problem: given an order and a set of warehouses inside a single legal entity, which location should fulfill it, based on inventory availability, distance to the customer, and cost. The new capability extends that same logic across company boundaries. DOM can now evaluate inventory sitting in a different legal entity entirely, and when it decides that location is the right one to fulfill from, it does not just flag the mismatch for someone to sort out manually. It automatically builds the full intercompany transaction chain: an intercompany purchase order in the entity that took the original sale, and a matching intercompany sales order in the entity actually holding the stock, synchronized so that when the fulfilling entity ships, both records update and the customer’s original order closes out correctly. For an organization that has been handling these situations with a spreadsheet and a Teams message between two warehouse managers, that is a real reduction in manual work, not just a marginal one.

The business case writes itself on the inventory side. Stock that would otherwise sit idle in one entity while a nearly identical order goes unfulfilled, or gets backordered, in another becomes usable. Organizations running regional legal entities for tax or regulatory reasons, but operating as one brand commercially, finally get a fulfillment engine that reflects how customers actually experience the business rather than how the org chart is drawn.

The mechanics matter just as much when things do not go according to plan. If a fulfilling entity cannot complete an order, whether because inventory shifted after DOM made its decision or a warehouse simply declines the assignment, DOM does not leave the order stranded. It marks the line rejected and attempts reassignment on its next scheduled run, first to another location within the same entity, then to a warehouse in a different one entirely. Partial fulfillment works the same way: if a location can only ship part of an order, the shortfall carries through the intercompany chain, and DOM can reassign the remainder on a later pass. For an operations leader weighing this against the status quo, that built-in retry logic is arguably as valuable as the initial sourcing decision, since it replaces exception handling that used to depend on someone noticing the problem before anyone could fix it.

The Setup Cost Nobody Puts in the Feature Announcement

None of this activates by flipping a single switch, and the gap between the headline and the configuration work is exactly where evaluation projects go wrong. The prerequisite that will consume the most calendar time is intercompany trading relationships. For every pair of legal entities that should be able to fulfill for each other, someone has to create and link a customer record in the selling entity and a vendor record in the fulfilling entity, then configure both for automatic intercompany order creation. With two entities that is a manageable afternoon of setup. With eight or ten, which is not an unusual footprint for a company that has grown through acquisition, the number of pairs that need configuring grows fast, and each one typically touches both an accounts payable and an accounts receivable process owner who may not have been in the room when this project got approved.

Beyond that, three technical dependencies are easy to miss until a pilot stalls on them. First, the DOM solver has to be set to Production Solver rather than Simplified Solver, because the simplified option cannot create intercompany orders at all, a detail that only surfaces after someone has already built out fulfillment groups and rules under the wrong configuration. Second, Azure Maps has to be enabled and licensed, because DOM uses it to calculate real distances between warehouses and delivery addresses when deciding which entity should fulfill an order, and that is a dependency an IT team evaluating this purely as an ERP feature might not budget for. Third, and most consequential for a phased rollout, every legal entity that should participate has to be explicitly added to the DOM fulfillment profile. Miss one, and DOM will not simply deprioritize its locations, it will not see them at all, which makes partial or staged rollouts across a large entity footprint riskier to get right the first time than the documentation implies.

Abstract illustration of warehouse facilities connected by a glowing digital inventory routing network

What’s Actually in Scope Today

It is worth being precise about where this feature currently draws the line, because a preview capability evaluated against the wrong assumptions leads to a rollout plan that has to be rewritten in six months. As of this preview, cross-legal-entity fulfillment covers retail order channels only: point of sale, e-commerce, call center, and headless Commerce Scale Unit orders. Sales orders originated directly in Supply Chain Management sit outside this scope for now. Microsoft has said SCM order support is on the roadmap, but roadmap language in a preview announcement is explicitly not a delivery commitment, and organizations that need cross-entity logic for B2B or wholesale sales orders processed natively in SCM should not build a 2027 plan around a capability that has not shipped yet.

The preview status itself carries the same caveat every Dynamics 365 preview does, and it is worth repeating because it gets skipped over in internal pitch decks more often than it should: preview features are for evaluation, are subject to change, and Microsoft’s own documentation is explicit that timing and functionality should not factor into purchasing decisions. Private preview in 10.0.48 moving to public preview in 10.0.49 is a normal, healthy cadence, not a signal that general availability is imminent.

How to Evaluate This Before You Pilot It

For a finance or operations leader deciding whether this belongs on next year’s roadmap, the useful first step is not a technical proof of concept. It is an honest audit of how complete the organization’s existing intercompany trading setup already is. Companies that have already done the work of linking customer and vendor records across their legal entities for other intercompany scenarios will find the DOM-specific configuration, the vendor mapping, fulfillment groups, and rules, relatively fast to layer on top. Companies where intercompany trade has been handled ad hoc, entity by entity, as problems came up, should expect the trading relationship setup itself to be the majority of the project timeline, not the DOM configuration.

It is also worth involving accounts payable and accounts receivable process owners earlier than a typical fulfillment feature would require, since this changes the volume and pattern of intercompany transactions those teams reconcile every period. A pilot scoped to a single, well-understood pair of legal entities, run alongside the existing manual process rather than replacing it immediately, gives a much clearer read on actual fulfillment savings and reconciliation impact than a broad rollout attempted on day one of public preview.

Cross-legal-entity fulfillment addresses a real and common operational gap, and the underlying DOM engine it builds on is mature technology, not an experimental one. The preview label applies to the cross-entity orchestration layer, not to order fulfillment optimization itself. Routeget Technologies has walked a number of multi-entity clients through intercompany trade configuration for other reasons, and the pattern holds here too: the technology adoption timeline is rarely the bottleneck. The completeness of the underlying intercompany setup is.

#DistributedOrderManagement #Dynamics365SCM #IntercompanyFulfillment #OmnichannelFulfillment #SupplyChainAutomation

The 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