Seven Azure reference architectures for AI on Dynamics 365…

Seven Azure reference architectures for AI on Dynamics 365 — and the eighth we refused to draw

Dynamics 365 records your prices, buffers, work orders and shipments. It does not compute the optimal ones. These are the reference architectures we build to close that gap — the Azure services, the exact D365 surfaces each pattern reads and writes, what it costs to run, and where it stops working. They are patterns, stated as patterns.

Every one of them shares a spine, so here it is once:

Bulk history comes from the lake. Link to Fabric [GA] carries F&O data into OneLake

without an export pipeline.

The live position comes from the transactional surface. Business performance analytics

pre-transforms run twice daily — a 12-hour cycle per Microsoft's documentation — so anything a decision depends on within the day is read live, never from the analytics copy.

The optimization runs on Azure. The ERP is not the compute tier.
Every write is a proposal behind human approval, through the ERP MCP server [GA] (the

Model Context Protocol endpoint that lets an agent call F&O, live since 27 January 2026), scoped by a purpose-built security role. The role is the agent's entire blast radius — there is no separate agent-permission layer.

We don't touch the ERP core. We surround it with intelligence, on the stack IT already governs.

1. The buffer write-back loop — safety stock that stops being a typed number

The decision it optimizes: the safety-stock level per SKU-location, written into the coverage fields the planning engine already reads.

Azure services: Link to Fabric (history: demand, PO receipts, item coverage) · Azure Machine Learning (demand and lead-time distribution fits, service-level costing) · Azure Functions (orchestration) · Dataverse + Power Apps (the proposal-and-approval queue) · Application Insights.

Reads / writes on D365: reads demand history and receipt history from OneLake; reads the live stock position from the transactional surface. Writes proposed minimum quantities into item coverage through ERP MCP data_update_entities, behind planner approval — Planning Optimization [GA], the in-memory planning service, then consumes them on its next run. No second system.

Cost shape: a nightly serverless burst that scales with SKU-location count, on top of the Fabric capacity the customer already runs. The LLM meter fires only on explanation text, never inside the statistics. Priced as a departmental line, not per-seat.

Where it stops working: on-premises — Planning Optimization is not supported there and the legacy engine is [DEPR], unsupported since March 2023, so the buffer is not an on-prem customer's first problem. And on thin, intermittent history, where the honest output is an "insufficient history" flag, not a confident fit.

§0 filter: passes — buyers ask "why is our safety stock still wrong", Microsoft has no page on recomputing it, and the pattern needs no figure at all.

2. Custom-algorithm injection — your model inside Microsoft's forecasting app

The decision it optimizes: the demand forecast for intermittent, service-parts demand — the SKUs that sell a handful of times a year and punish general-purpose fits.

Azure services: Azure Machine Learning only. Demand planning [GA] documents support for custom Azure Machine Learning algorithms — you register your own model and the app runs it inside its own forecast profiles.

Reads / writes on D365: none that you build. The app supplies the time series to the model and publishes the forecast into SCM demand forecasts through its own pipeline. This is the rare pattern with zero custom integration surface — which is exactly why we reach for it first.

Cost shape: AML compute during training and scoring windows, nothing at rest. No integration infrastructure to own. The cheapest pattern on this page by an order of structure, not just size.

Where it stops working: when the dimension grain of the model and the plan disagree, the aggregation is silently wrong. And its lifetime is bounded: Best fit model v3 [PP] already adds Croston's method for intermittent demand in preview — when that reaches GA, this pattern retreats to statistics the platform still cannot fit. We say that out loud and design for it.

§0 filter: passes — "how do I plug my own model into D365 demand planning" is asked, documented only as a reference page, and never written up as a working pattern.

3. The line-stop predictor — the shortage that is already in your data

The decision it optimizes: which production orders to protect this week — the expedite call, made before the line stops instead of after.

Azure services: Azure Functions or Container Apps (the nightly join) · Azure SQL (state and history) · Azure Service Bus fed by F&O business events [GA] (production-order status changes trigger recomputation) · Azure OpenAI in Foundry (the one-paragraph explanation per flagged order) · a Copilot Studio agent over the ERP MCP server as the question-answering surface.

Reads / writes on D365: reads BOM, production orders, on-hand, open purchase orders and planned orders through data entities [GA]; from 10.0.48 the MCP server's SQL-based read (data_find_entities_sql) does the multi-entity join in one call. Writes nothing — the v1 is deliberately read-only. The output is a ranked list with the single blocking part named per order.

Cost shape: one nightly batch scaling with open production orders, plus event-driven recomputation bursts. LLM cost tracks the length of the flagged list, not the size of the ERP.

Where it stops working: on rotten master data — the BOM line with a blank site silently drops from the planning run, and no predictor sees a part the plan itself ignores. Fix the master data first; the pattern makes that visible rather than papering over it.

§0 filter: passes — "the ERP says we have the parts, the line says we don't" is a question with no Microsoft answer; Planning Optimization emits action messages, not a ranked line-stop list.

4. The price-proposal engine — the engine's price versus the optimal one

The decision it optimizes: the margin-optimal price and discount on the next order line — the last mile past the list price the ERP correctly enforces.

Azure services: Azure API Management (the façade and rate limiter in front of F&O) · Azure Functions (scoring) · Azure Machine Learning (elasticity and willingness-to-pay models trained on invoice history from Link to Fabric) · Azure OpenAI in Foundry (the explanation a sales manager reads before approving).

Reads / writes on D365: reads the ERP's own calculated price through Calculate prices for external systems through API [GA] since 5 June 2026 — so the comparison is against what the engine would actually charge, not a reconstruction of it. Writes proposed price and discount changes as draft trade-agreement journals through data entities, posted by a human.

Cost shape: per-line scoring is small and synchronous; the real cost is the model retrain cadence, which runs on a schedule you choose, not per transaction. APIM sits in front so a chatty consumer throttles at the gateway, not inside the ERP.

Where it stops working: without price variation in the history there is no elasticity to estimate — a book of long-term contracted prices needs a different pattern (leakage audit, not optimization). And it proposes; it never silently reprices. A price a human cannot explain to a customer is a price we do not ship.

§0 filter: passes — the pricing API is new, unwritten-about, and the pattern that pairs it with an elasticity model exists nowhere else in the ecosystem.

5. Maintenance backlog triage — this week's work orders, ranked and defensible

The decision it optimizes: which maintenance work orders to run this week, ranked by asset criticality, spare-parts readiness and cost of failure.

Azure services: Azure Functions (the scoring job) · Azure SQL (score history, so the ranking is auditable over time) · Azure OpenAI in Foundry via a Copilot Studio agent (the "why is this ranked first" answer, grounded through the ERP MCP server) · Teams as the delivery surface.

Reads / writes on D365: reads work orders, assets and maintenance history from the Asset Management module through data entities [GA], and spare-parts on-hand for readiness scoring. Writes an approved scheduling priority back behind a supervisor gate — or stays read-only, which is how a pilot should run. Relevant context: Microsoft's own Asset Management mobile app is [DEPR] as of 1 June 2026, which tells you where the module sits on their investment curve.

Cost shape: a small scheduled job whose cost tracks open work orders per site. Flat per site, no per-seat meter — maintenance teams do not buy seats.

Where it stops working: without asset criticality recorded, the ranking degrades to overdue-ness — honest, but not the product. And it is deliberately not sensor-based prediction: Sensor Data Intelligence has sat in [PP] for an extended period, and we do not build foundations on a long-running preview.

§0 filter: passes — proven demand (the largest AI category on SAP Store is maintenance), no native prioritisation logic, no figures needed.

6. Supplier-event impact traversal — from "supplier X has a problem" to "these six orders break"

The decision it optimizes: which purchase orders, production orders and customer lines to re-plan when a supplier event hits — the response, not the risk score.

Azure services: Azure Logic Apps (ingesting whatever risk or news feed the customer already subscribes to) · Azure Service Bus (buffering) · Azure Functions (the traversal: vendor → item → BOM → open orders → customer lines) · Azure OpenAI in Foundry (the drafted internal briefing) · Teams for delivery.

Reads / writes on D365: reads vendor master, item-vendor links, BOM lines, open purchase orders, production orders and sales lines through data entities [GA]. Writes nothing to the ERP — the output is a briefing and a task list, because the response to a supplier fire is a human decision with an ERP-shaped evidence pack.

Cost shape: near-zero at rest, bursts on events. The risk feed stays on the customer's existing contract — we do not resell risk data, so the pattern carries no data-licence cost of ours.

Where it stops working: at tier 2. The ERP knows your suppliers, not your suppliers' suppliers, and we do not pretend to a multi-tier graph we do not have. Risk vendors sell that; we sell the last mile from their alert to your order book.

§0 filter: passes — risk vendors stop at the alert; nobody writes the ERP-side response architecture.

7. The write-governance gateway — the pattern the other six pass through

The decision it optimizes: which agent-proposed write commits to the system of record, with what blast radius, reviewed by whom.

Azure services: Dataverse (the proposal queue — every optimization above writes here first) · Power Automate (approval routing) · Azure SQL or Cosmos DB (append-only audit of proposal, approval, commit and compensating rollback) · Azure DevOps (agent regression tests in the release pipeline, because the MCP form contract moves with the application and an update can change an agent's behaviour).

Reads / writes on D365: all agent access rides the ERP MCP server [GA]: a purpose-built security role per agent (never a broad one — Microsoft's own guidance, and a narrower role also improves tool selection), client access controlled on the Allowed MCP clients form, system-admin forms excluded by design so an agent can never widen its own permissions. Commits go through data_update_entities only after approval.

Cost shape: a thin control plane — approval flows and an audit store. The spend is engineering discipline, not compute. This is also the pattern that makes the other six auditable enough for a CISO to sign.

Where it stops working: it cannot make a broad role safe — the role is the API surface, and governance added on top of over-permission is decoration. And it only governs what routes through it: a legacy OData integration that bypasses the gateway is outside its audit line, and we say so in the design review.

§0 filter: passes — "how do I control what an AI agent can write to my ERP" is asked in every security review, and no marketplace product or Microsoft page answers it end to end.

The eighth pattern, and why we refused to draw it

The obvious eighth is demand-sensing enrichment — piping EDI releases, point-of-sale data and external signals into the forecast. It fails the filter, and the receipt is dated: Microsoft's 2026 release wave 1 plan lists Enhance demand forecasts with multiple data inputs [PLAN] for GA in August 2026, alongside generative demand insights. The platform ships this plumbing in weeks, from data it already holds, for every industry at once. An architecture we publish today would be Microsoft's feature announcement by autumn.

So it fails test 2 — we cannot answer it better than Microsoft for long enough to matter — and the absorption test that governs everything we build. The signal-enrichment story is an article, not a pattern. Where a customer's statistics genuinely outrun the platform, pattern 2 — Microsoft's own custom-algorithm slot — is the durable way in.

Fact-check

Unverified / to check

Claim 11: the Asset Management module description traces to the internal domain menu, which

carries no Learn URL for it. Pull the Asset Management overview page into 01-knowledge-base/ and add the URL to sources before this draft is imported.

Azure OpenAI in Foundry / Copilot Studio service naming is stated at pattern level from the

knowledge base, not from a fetched Azure page this week; re-verify product names against current Azure documentation at import time.

Seven Azure reference architectures for AI on Dynamics 365 — and the eighth we refused to draw