Forecast model setup: templates, rollup and hierarchy entities

What it does

A forecast configuration tells Dynamics which records to add up (the rollup entity), who or what to add them up against (the hierarchy entity), and over which periods. Everything else in forecasting — columns, quotas, adjustments, predictions — hangs off those three decisions.

Key facts

Three out-of-the-box templates: org chart (rollup entity Opportunity, hierarchy entity User), product (Opportunity Product / Product) and territory (Opportunity / Territory). All three are starting points, not fixed models.
The rollup-to-hierarchy relationship is a path, not a single lookup, and it supports up to two hops — for example Opportunity > Owner (User) > Territory (Territory) > Territory.
Change tracking must be on for the rollup entity. Any table with change tracking enabled can be a rollup entity, including custom ones and Opportunity Split if you have built it.
The hierarchy entity has to be hierarchy-enabled in Dataverse (a self-referential parental relationship). User and Territory already are; a custom table won't be until you configure it.
Top of hierarchy sets the root node. The grid only ever shows that node and everything below it.
Both entities take an optional filter (the funnel icons on the General step) — rollup entity filter to exclude records, hierarchy entity filter to exclude people or territories.
Scheduling covers scheduling format (Gregorian and other calendars), period start date, forecast period (monthly, quarterly or annual), fiscal year label, the period the forecast starts in, and number of periods. At least one period must exist before you can move on.
Hard org limits: 50 forecast configurations, of which 6 can be active at once.
The out-of-the-box forecast needs no configuration at all: org chart template, Opportunity, current month only, quota derived from the previous month's won amount, near real time, capped at 50,000 records, and not saved anywhere. Configured forecasts have no stated record cap.
Not supported on Government Community Cloud, and not supported on mobile.

When to use / skip

Everyone who sells against a number wants this, and it is genuinely good, but it is only as good as the hierarchy underneath it. If the client's Manager field on User is empty, stale, or maintained by hand rather than fed from HR or Entra ID, you are building a reporting structure by accident and it will be wrong within a quarter. Fix that first or use the territory template instead.

Skip the custom rollup entity route unless the client genuinely forecasts on something other than whole opportunities. Opportunity Product and Opportunity Split configurations are considerably more work — the amount field, the forecast category and the close date all live on different tables, so nothing auto-configures and you wire every column by hand.

The out-of-the-box forecast is fine for a demo and useless for delivery. It is one month, unsaved, and you cannot change a thing about it. Do not let a client build a process on it.

Configuration decisions

Which template, and behind it which rollup grain — whole opportunity, opportunity product, or a split/custom table. This is the decision that sets how much build work follows.
Which hierarchy the numbers roll up: the org chart via Manager on User, or Territory. Product hierarchies are a third option and usually a second forecast rather than a replacement.
Where the top of the hierarchy sits. A CRO at the root gives one grid for the business; a regional VP gives a narrower one that loads faster and reveals less.
Period grain and how many periods. Monthly with twelve periods is the common answer; quarterly is what finance usually actually reports on. You can run both as separate configurations.
What the rollup filter excludes — internal opportunities, renewals, a particular business unit. Decide this before columns, because it changes what the numbers mean.
How many of the six active slots you are spending, and on what. Two hierarchies times two period grains and you are already at four.

Gotchas

The General step choices are structural. Re-pointing a live forecast's rollup or hierarchy entity is not a routine change — plan on building a second configuration and activating that, which means one of your six slots.
Change tracking is easy to forget on a custom rollup entity and the table simply won't appear in the picker. There is no error telling you why.
The two-hop relationship limit bites on real data models. If territory hangs off Account which hangs off Opportunity, you're at the edge; anything deeper needs a calculated or rollup field on the source record instead.
Users with no manager and no place in the hierarchy quietly do not appear. Their opportunities are not in the forecast, and nothing flags this.
Only the top of the hierarchy and below is forecast. Move someone under a different manager mid-quarter and past periods keep the old structure until you manually recalculate them.
GCC tenants get no forecasting at all. Find this out at the sales stage, not during design.

Consultant notes

Ask to see the Manager field populated across the whole sales org before you agree a delivery date. It is the single most common reason a forecast build stalls.
Demo the org chart template with real users and real opportunities. A forecast grid full of sample data lands badly, and predictive forecasting later needs real data anyway.
Push back on requests for five or six parallel forecasts. Six active is the ceiling and you want spare slots for the rebuild you will inevitably need.
Agree the fiscal calendar with finance up front — the fiscal year label and period start date are cosmetic in Dynamics but not in the client's reporting.
Before go-live, walk the hierarchy from the top node down and confirm every seller appears exactly once.

Worth another look if Microsoft raises the six-active-forecast limit or extends the two-hop relationship depth.