Which forecast algorithm should you use for intermittent…

Which forecast algorithm should you use for intermittent demand?

In the Dynamics 365 demand planning app you don't choose one, and that is not something configuration gets you around. The algorithm built for intermittent demand is Croston's method, and Microsoft is explicit that "Croston's method isn't a forecasting model that you can choose." It is a fallback. Something else decides when to reach for it, that something else is currently a preview feature, and the question needs rephrasing before it has a useful answer.

The answer, in the form the product actually takes

Intermittent demand — long runs of zero with occasional non-zero orders — is the defining statistical problem in service parts and slow-moving aftermarket stock. The real question is not which algorithm but which best fit version am I running, and what did it pick per item.

Which algorithm for intermittent demand — The question that has an answer: Which Best fit model version is configured on the step · Where you answer it: Settings on the Forecast step of the forecast model
Will it handle my sparse items — The question that has an answer: Does that version include Croston's method, and is it preview · Where you answer it: The version gate on Microsoft's algorithm page
Is it working — The question that has an answer: Which algorithm ran for which dimension combination · Where you answer it: The Explainability tab of the forecast job run

What Microsoft actually documents

Demand planning in Microsoft Dynamics 365 Supply Chain Management includes four popular demand

forecasting algorithms: auto-ARIMA, ETS, Prophet, and XGBoost.

— Demand forecasting algorithms

**auto-ARIMA* — What Microsoft says it is for: "works well with stationary data"* — constant mean, constant standard deviation, no seasonality · Status: [GA]
**ETS (error, trend, seasonality)* — What Microsoft says it is for: "works well if your business case is simple and the data has various patterns, such as linear or exponential trends"*, or when recent data should carry more weight · Status: [GA]
**Prophet* — What Microsoft says it is for: "works best with complex, real-world data"* — missing values, outliers, holidays · Status: [GA]
**XGBoost* — What Microsoft says it is for: "can generate a forecast based on multiple inputs" — the multi-input case · Status: `[GA]` algorithm, reachable only through the `[PP]` Forecast with signals* step
**Best fit model* — What Microsoft says it is for: "automatically selects the best of the available algorithms for each product and dimension combination"* · Status: versions differ — see below
**[Custom Azure Machine Learning algorithm](https://learn.microsoft.com/en-us/dynamics365/supply-chain/demand-planning/custom-azure-machine-learning-algorithms)** — What Microsoft says it is for: Your own model, called from a forecast step · Status: [GA]

Notice what is not in that list. No Croston's entry, nothing aimed at zero-heavy series. The page's own guidance for single-input forecasting is blunt: "For most other scenarios, use the best fit model algorithm, because it automatically selects the correct forecasting algorithm for each product and dimension combination."

Best fit has three versions, and only one knows about intermittent demand

Every row below is a version gate on the demand planning app's own release line — not Supply Chain Management's 10.0.x line. The two numbers do not track each other, though an individual improvement can still depend on a Supply Chain Management release.

**Best fit model - version 1** — Demand planning version required: 1.0.0.1067 or higher · What it adds: Selects among auto-ARIMA, ETS and Prophet per product and dimension combination · Status: [GA]
**Best fit model - version 2 (preview)** — Demand planning version required: 1.0.0.3424 or higher · What it adds: Adds Naive forecasting for low-data items; training and testing data limited to values before the forecast start date · Status: [PP]
**Best fit model - version 3 (preview)** — Demand planning version required: 1.1.0.4 or higher · What it adds: Adds Croston's method for intermittent demand · Status: [PP]

Microsoft's own note under that table is the part to take to your steering committee:

- Best fit model - version 2 and Best fit model - version 3 are preview features.

- Preview features aren't meant for production use and might have restricted functionality. These

features are subject to supplemental terms of use. They're available before an official release so

that customers can get early access and provide feedback.

— forecast-algorithm-types

So the honest position today: the only route Microsoft documents to Croston's method is a preview feature, and Microsoft's own terms say preview features aren't meant for production use. Pilot it. Do not rebuild a spare-parts replenishment policy on it, and do not let it into a go-live plan as though it were shipped. The Croston's page carries the matching banner: "[This article is prerelease documentation and is subject to change.]"

What Croston's method actually does — and refuses to do

Croston's method is a forecasting algorithm designed specifically for intermittent demand, which

is demand data that includes many zero-demand periods with occasional nonzero demands.

— Croston's method forecasting (preview)

It estimates how frequently the item is needed and how large the average demand is when it occurs, weighted toward recent activity — and it will not tell you when. Microsoft states the refusal directly: the method "predicts only the average interval between demands—not when the next demand will occur—and doesn't provide a probability distribution of sizes."

The flat line is the point. Standard models on zero-heavy data "might overreact to small changes, forecast zero across the board, or attempt to create a trend where none exists."

It fires only when all four of these hold:

**Version* — "You're using the Best fit model - version 3 (preview) (or newer) forecasting algorithm. Croston's method isn't available for other forecast algorithms or as a separate algorithm."*
**Not a low-data case* — "Your dataset doesn't fulfill the conditions for using the naive forecasting algorithm."*
**No seasonality* — "Your dataset doesn't have a clear seasonal pattern."*
**Sparsity threshold** — Microsoft's threshold restated without the symbol: over eighty percent of values in the input time series are equal to zero

That last row is Microsoft's stated threshold, reproduced in words rather than with the symbol, and it decides whether your slow movers reach Croston's at all.

Two traps that will quietly cost you the fallback

A seasonal hint switches it off. From the same page: "Adding a seasonal hint prevents the best fit algorithm from selecting Croston's method, forcing it to choose an alternative." Apply a blanket hint across the catalogue — reasonable for finished goods — and you have disabled the intermittent-demand path for the spare parts in the same run, with nothing to report it.

A Croston's selection is a data verdict, not a success. Microsoft is explicit: "When the system chooses to use Croston's method within a dimension combination, it indicates that the data you provided might be insufficient." The naive forecasting page says the same of its own trigger.

When the item is spiky rather than sparse

Sparse and spiky are different problems. If the zeros are driven by something observable — promotions, weather, price, a stockout that suppressed recorded demand — the route is a second input, not a better single-input algorithm.

XGBoost is the algorithm for that, with one constraint quoted exactly as written: "It's currently the only algorithm you can use with the Forecast with signals forecast model step in Demand planning. In addition, only that type of step supports it." Keep the word currently — Microsoft hedged it, and so do we. Forecast with signals [PP] began at one signal in demand planning version 1.0.0.1700 and was "extended to allow up to five signals" in version 1.1.0.4, per the what's-new page.

And the ceiling: custom Azure Machine Learning algorithms [GA] are supported. Register a Microsoft Entra application against the Azure Machine Learning workspace and its storage account, register the endpoint under Custom Azure ML, then place a Custom step (batch endpoint) or a Finance and operations step (pipeline endpoint) where the standard Forecast step would go. That is the supported door for a purpose-built intermittent-demand model, and Microsoft publishes a template repository behind it.

What to do this week

Open Operations > Forecast profiles, then the Forecast model tab, then Settings on the Forecast step. Read which Best fit model version is selected. If it is version 1, no amount of data work will produce a Croston's forecast.
Check your demand planning app version against the gates above. Version 3 needs 1.1.0.4 or higher.
Open the Explainability tab on a recent forecast job run and sort by algorithm. Microsoft's forecast profile page describes it as listing "each combination of dimensions … the demand forecasting algorithm that was used and the mean average percentage error (MAPE) for the calculation", and "a lower MAPE value indicates greater accuracy". Count how many service-part rows sit on a fallback.
Check whether a seasonality hint is applied model-wide. If it is, your sparse items are excluded from Croston's by configuration.

One vocabulary note: Microsoft expands MAPE as "mean absolute percentage error" on the algorithms page and "mean average percentage error" on the forecast profiles page. Same metric, two expansions in the vendor's own documentation.

Where we would draw the line

We would not run a spare-parts replenishment policy off a preview algorithm and describe it to a board as shipped. Nor would we write our own Croston's implementation to escape the preview label — you would be maintaining a statistical method against a vendor about to ship it, and losing the explainability output that makes it auditable.

What we build is the layer Croston's deliberately leaves empty. It returns an average rate and an average size and says so — no timing, no distribution of order sizes. A service-parts business does not stock to an average; it stocks to a service level under a lead time, which needs the shape of the demand distribution and not just its mean. Dynamics manages the forecast; the Demand & Inventory Optimizer optimizes the stocking decision on top of it and writes the buffer back behind an approval step.

Two neighbouring chapters carry the adjacent questions — demand-planning-time-fence-vs-time-freeze for whether a planner's override of a fallback forecast survives the next run, and forecast-double-counting-dynamics-365 for what master planning does with the forecast once it lands.

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/

Carrying a long tail of slow-moving parts? Book a call and we will read your explainability output with you. https://cognilium.ai

Which forecast algorithm should you use for intermittent demand?