Almanac
Microsoft/d365salesDynamics 365

Consultant-focused KB for Microsoft Dynamics 365 Sales: implementation notes, gotchas, and configuration decisions beyond the official docs — across pipeline management, opportunities, forecasting, sequences, sales accelerator, Copilot, integrations, administration, and licensing.

feature-who-owns-the-forecast.mdv1 · history
CurrentApplies to EnterpriseUpdated 6 days agoSource Microsoft Learn

What it does

Dynamics 365 Sales can produce a revenue forecast from the opportunity pipeline, rolled up a hierarchy of sellers and managers, with manual adjustments on top. Most organisations already have a forecast owned by finance, built in a spreadsheet or a planning tool, on a different calendar and a different definition of revenue. This doc is about which one wins, and what you do with the other.

Key facts

  • A forecast is defined as a model: pick a template, define and schedule it, set permissions, configure columns and layout, configure drill-down entities, set advanced options, then activate it and let data load.
  • Forecasting is not supported on Government Community Cloud, and it is not supported on mobile.
  • A Sample Forecast ships with the product so you can experiment before building one for real.
  • Access is granted through the hierarchy defined in the model plus security roles — it is not a per-user share list. Once activated, users in the hierarchy can see the forecast.
  • Configuration needs administration and customisation roles; day-to-day use needs the primary sales roles.
  • Premium forecasting adds a prediction column and prediction factors, is GA rather than preview, and is restricted to hierarchies using Opportunity as the rollup entity.
  • Premium forecasting needs more than 10 closed opportunities carrying Actual Value, Actual Close Date, Estimated Value and Estimated Close Date, plus open opportunities with estimates. Every underlying opportunity must be owned by a system user. Data appears about two hours after activation.
  • Premium forecasting is unavailable in GCC, France and India.
  • Snapshots in sales forecasting were deprecated on 30 June 2024. Point-in-time forecast history now comes from the Forecast API (msdyn_forecastapi), not from the product's own snapshot feature.
  • You can build a forecast on a custom rollup entity rather than Opportunity, which is how non-standard revenue shapes get modelled.

When to use / skip

Turn Sales forecasting on when the sales organisation needs a disciplined, bottom-up commit process — sellers owning a number, managers adjusting it, a visible gap to quota. That is what the product is good at, and it is genuinely better than the spreadsheet it replaces, because the numbers trace back to opportunities you can open.

Do not position it as the company's forecast. It is not a finance system. It does not know about revenue recognition, deferred revenue, multi-year contract phasing, currency policy or the group reporting calendar, and every attempt I have seen to make it do so ended with an unmaintainable custom rollup entity and a finance team that still used their own model. If the client's CFO owns forecasting, your job is to make Sales the trustworthy source of pipeline data that feeds the finance model — not to replace it.

The useful pattern is two numbers with one lineage. Sales forecasts sales-recognised value on the sales calendar in Dynamics. Finance takes the pipeline export and applies its own rules. You agree, once and in writing, the mapping between an opportunity's estimated close date and finance's period, and between estimated revenue and whatever finance calls revenue. Then the monthly argument becomes a reconciliation instead of a fight about whose system is right.

Skip forecasting entirely in phase one on a new implementation. There is nothing to forecast until sellers are actually working opportunities in the system, and premium forecasting cannot even train until you have more than ten closed opportunities with clean actuals. Promising a forecast at go-live is how you end up demonstrating an empty grid to a sponsor.

Configuration decisions

  • Whether the rollup is Opportunity or a custom rollup entity — this is close to a one-way door, since it determines column configuration, drill-down and whether premium prediction is available at all.
  • Which hierarchy drives the roll-up: manager hierarchy, position hierarchy, or territory. This must match how the sales organisation is actually managed, not the HR org chart.
  • The forecast period and calendar, and specifically whether it matches finance's periods or deliberately does not.
  • Which opportunity states count towards the forecast categories, and who is allowed to adjust a rolled-up number versus who can only see it.
  • Whether forecast history is captured through the Forecast API from day one, given snapshots are gone.
  • Whether premium forecasting is in scope now or deferred until pipeline history exists.

Gotchas

  • Snapshots are deprecated, so "show me last month's forecast versus this month's" is not an out-of-the-box answer. If nobody builds Forecast API capture early, that history is simply never created and cannot be reconstructed.
  • Premium prediction produces nothing when opportunities are owned by teams or disabled users rather than system users. There is no error message — the column is just blank.
  • No forecasting on mobile. Sales managers who live on a phone will find this out on the first commit call.
  • Changing the rollup entity on a live forecast means rebuilding the model, not editing it. Get this right at design time.
  • Hierarchy changes — a manager leaving, a territory reshuffle — reshape the forecast. There is no built-in "as it was" view once snapshots are gone.
  • Currency is a quiet trap in multi-country pipelines. Agree the exchange rate policy with finance before the first forecast is activated, or the reconciliation will never close.

Consultant notes

  • Get finance in the room for the forecast design session, even if they are not the customer. Twenty minutes of a financial controller's time saves a quarter of arguments about whose number is right.
  • Demo the drill-down from the rolled-up number to the individual opportunity. That traceability is the actual sell, far more than the prediction column.
  • Push back on replacing a finance forecast. Offer the reconciliation model instead, and say plainly that Sales forecasting does not do revenue recognition.
  • Build Forecast API history capture into phase one even if nobody asked. It costs little now and is impossible to backfill later.
  • Before go-live, check opportunity ownership is all system users, and run the sample forecast with real data to confirm the hierarchy rolls up the way the sales director expects.

Worth another look after the next release wave, or if Microsoft restores a first-party forecast history feature.

Was this accurate?