Demand planning app or master planning

Demand planning app or master planning — where does the forecast actually live?

Neither. The forecast lives in a forecast model in Supply Chain Management — a named container of demand forecast lines. The demand planning app calculates the numbers and pushes them into it; master planning reads them out. The forecast model is the object of record, and it is what your design workshop should argue about instead of the two applications either side of it.

Three places, and only one of them holds the forecast

**[Demand planning app](https://learn.microsoft.com/en-us/dynamics365/supply-chain/demand-planning/demand-planning-home-page) [GA]** — What it holds: Time series, transformations, forecast profiles, algorithm choice, planner adjustments, fences and freezes · What it does not hold: Anything master planning reads. Separate app, separate release line
**[Forecast model in Supply Chain Management](https://learn.microsoft.com/en-us/dynamics365/supply-chain/master-planning/planning-optimization/demand-forecast) [GA]** — What it holds: The demand forecast lines, aggregated across submodels · What it does not hold: Any calculation. It is storage with an identity
**[Master planning](https://learn.microsoft.com/en-us/dynamics365/supply-chain/master-planning/planning-optimization/demand-forecast) [GA]** — What it holds: The plan that consumes a forecast model and nets it against real demand · What it does not hold: The forecast. It points at one, by name

The demand planning app is not a module of Supply Chain Management. It installs separately from Power Platform admin center under Resources > Dynamics 365 apps, as Dynamics 365 Demand Planning Application, and the install article adds two constraints for the architecture review: you "must install Demand planning on the same tenant as your Supply Chain Management environment" and "can't install Demand planning on your tenant's default environment" — the latter, in Microsoft's words, "Due to a current technical limitation".

Supply Chain Management also still ships its own built-in demand forecasting [GA], whose page opens with a Tip recommending "Demand planning in Microsoft Dynamics 365 Supply Chain Management, which is Microsoft's next-generation collaborative demand planning solution." Both write to a forecast model — the strongest evidence that the model, not the app, is the object of record.

Who owns what

**Historical demand, transformations, time series — Owned by: Demand planning app · The named surface: Data management > Import**
**Forecast algorithm choice per item — Owned by: Demand planning app · The named surface: Forecast profile > Forecast model tab > Settings**
**Manual planner adjustment** — Owned by: Demand planning app · The named surface: The time series values grid
**Lock on who may edit, and on what a rerun overwrites** — Owned by: Demand planning app · The named surface: Time fences and time freezes
**The demand forecast lines of record — Owned by: Supply Chain Management · The named surface: Master planning > Setup > Demand forecasting > Forecast models**
**Combining several forecasts into one** — Owned by: Supply Chain Management · The named surface: Submodels — one level deep, aggregated by date
**Netting the forecast against actual demand — Owned by: Master planning · The named surface: Method used to reduce forecast requirements**
**Planned orders** — Owned by: Master planning, in the Planning Optimization service · The named surface: The master plan run

Two consequences. Forecast governance lives in one application and netting policy in another, so nobody owns the round trip by default. And scenario combination happens in the submodel structure — Microsoft's example combines "a regular forecast with the forecast for a spring promotion" — so promotional planning is a Supply Chain Management concern even when the promotion was forecast next door.

The hop: how a forecast actually crosses

Nothing crosses on its own. The mechanism is an export profile, described step by step on Microsoft's export article.

**Create the profile — Where: Data management > Export > New · What you set: The Microsoft finance and operations apps tile on Select data provider**
**Point it at the environment — Where: Configure data provider page · What you set: Connection URL** of your Supply Chain Management environment
**Choose the payload — Where: Select output data* page · What you set: "You must select exactly one time series", and on Included, the Output version*
**Map the columns — Where: Map columns** page · What you set: Each time series column to a column in the target data entity
**Name the destination — Where: Define data export rules* page · What you set: Target company (legal entity) and forecast model ID. All for one model; Custom* to split
**Run it — Where: Action Pane > Run, or Run schedule · What you set: Every run appears on the Jobs** tab

The Define data export rules row is the one to remember. That is where the demand planning app becomes a producer of rows in a named forecast model inside a named legal entity. Point it at the wrong model and the rows still land — the export status tells you they were written, not that they were written to the model your master plan reads.

Two operational notes: the export lands through the Forecast Sales Import Entity staging entity, which Microsoft tells you to clear if performance suffers, and the install article has you preallocate the Demand forecast sequence number number sequence inside Supply Chain Management. Two systems, stitched.

What master planning does with it — and where this article stops

Three fields on the master plan's General FastTab, per Master planning with demand forecasts:

Forecast model — "Select the forecast model to apply. This model is considered when a supply suggestion is generated for the current master plan."
Include demand forecast — "Set this option to Yes to include the demand forecast in the current master plan."
Method used to reduce forecast requirements — None, Percent – reduction key, Transactions – reduction key, or Transactions – dynamic period.

This article stops at that third field, deliberately. The four methods behave very differently once real orders arrive, they interact with Reduce forecast by and Include customer forecast in the demand forecast on the coverage group, and the wrong combination produces a plan that double-counts near-term demand. That argument has its own worked examples and belongs to forecast-double-counting-dynamics-365. Summarising four netting methods in a paragraph would be worse than not covering them.

One netting fact has to cross, because it changes what "where does it live" means: master planning "excludes forecast requirements from the past, which means all forecast requirements before today's date." The forecast your planners saw yesterday is not the one the plan consumed today.

The forecast plan that Planning Optimization ignores

Supply Chain Management still has forecast plans as objects — Master planning > Setup > Plans > Forecast plans is a real path, and coverage groups carry a Forecast plan time fence field. But Microsoft states plainly:

Planning Optimization doesn't support separate forecast planning. Therefore, the **Current forecast

plan setting on the Master planning parameters** page has no effect when you use Planning

Optimization.

And again, as an Important callout against the master plan's own override: "Planning Optimization doesn't support the Forecast plan setting." Settings that are visible, editable and saved are inert under Planning Optimization. The coverage group's Forecast plan time fence is not in that inert set. The same page defines it — "Enter the number of days (from today's date) that the demand forecast should apply to" — and what Planning Optimization drops is the master plan's Forecast plan override of it, the option Microsoft describes as "Set it to No to use the values from the individual coverage groups."

"Are we up to date?" is two questions

The demand planning app has its own version line — 1.0.0.1067, 1.0.0.1281, 1.0.0.2502, 1.1.0.4, 1.2.3384.2 — and it is not Supply Chain Management's 10.0.x line. A capability can need a version of each.

**Use Demand planning at all** — Demand planning version: Any · Supply Chain Management version: 10.0.36 build 10.0.1695.83+, 10.0.37 build 10.0.1725.60+, or 10.0.38 (any build) or later
***The Demand Planning feature on by default*** — Demand planning version: Any · Supply Chain Management version: 10.0.40
**Faster forecast export* — Demand planning version: 1.2.3384.2 · Supply Chain Management version: 10.0.48 — "made possible by a new index introduced in Supply Chain Management version 10.0.48"*
**Croston's method for intermittent demand [PP]** — Demand planning version: 1.1.0.4 · Supply Chain Management version: Not stated on the page
**BOM (bill of materials) and route respected in forecast reduction** — Demand planning version: Not applicable · Supply Chain Management version: 10.0.49, plus a Feature management flag
**Cloud hosted environments** — Demand planning version: Unsupported since February 28, 2024 · Supply Chain Management version: —

Read the export row twice: a demand planning release gated behind a Supply Chain Management release. "We are on the latest demand planning app" is half an answer.

One caution: Microsoft's what's-new page lists releases by version number and prints no date against them. You can establish order from it, not age.

What to do this week

Open Master planning > Setup > Plans > Master plans and write down the Forecast model and Include demand forecast value for every plan you run.
In the demand planning app, open Data management > Export and read the Define data export rules tab on each profile. Confirm the forecast model ID and legal entity match step 1 exactly.
Record both version numbers — the demand planning app version, and the Supply Chain Management version and build — as one pair. Neither is meaningful alone.
Check the Jobs tab on each export profile for the last successful run. From inside master planning, a forecast exported six weeks ago looks identical to a current one.

Where we would draw the line

We would not build a second integration between these two systems. The export profile is supported, schedulable, versioned and mapped; a hand-built pipeline alongside it buys a reconciliation problem and a support boundary in exchange for nothing.

We would also not treat the round trip as an integration problem at all. It is a governance problem — one object of record, two applications with different owners, no alarm when an export lands in the wrong model. The fix is a named owner and a check after every export.

Where we optimize is one layer up. The forecast model tells master planning what is coming, not how much buffer that uncertainty deserves at this item, this site, this lead time. Dynamics manages the forecast and executes the policy; the Demand & Inventory Optimizer optimizes the safety-stock and replenishment call between them and writes the result back behind an approval step.

Siblings: forecast-double-counting-dynamics-365 for the four netting methods, and demand-planning-time-fence-vs-time-freeze for whether a planner's adjustment survives to be exported.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Want the round trip mapped on your estate, export profile against master plan? Book a call and we will walk it with you. https://cognilium.ai

Demand planning app or master planning — where does the forecast actually live?