Forecasts Hierarchy
A Forecasts Hierarchy is the Salesforce setup structure that defines who rolls up to whom inside Collaborative Forecasts.
Definition
A Forecasts Hierarchy is the Salesforce setup structure that defines who rolls up to whom inside Collaborative Forecasts. It mirrors the org's role tree (or its territory tree, if the org runs territory-based forecasts) and adds two pieces of configuration on top: a forecast manager designated at each level, and a per-user switch that decides whether someone takes part in forecasting. The platform uses this tree to sum opportunity amounts or quantities from each rep up to their manager, and onward to the top of the company.
The hierarchy is what lets the Forecasts tab show more than a single rep's own numbers. When a manager opens the tab, Salesforce walks the hierarchy downward from their position, totals the forecast figures from every enabled user reporting up to them, and renders one row per direct report. Without a configured hierarchy and an assigned manager, an enabled rep still produces zero in anyone else's grid.
How the rollup tree is wired together
Two flavors: role-based or territory-based
Salesforce builds the forecasts hierarchy from one of two structures. Most orgs use the role hierarchy, where the tree follows the same parent-child roles that already control record visibility. Orgs that run Enterprise Territory Management can instead base forecasts on the territory model, so a rep rolls up through their assigned territory rather than their role. You pick this when you turn on the forecast type, and the choice shapes everything downstream. A role-based hierarchy reuses your existing role tree, which keeps setup simple but ties forecasting to reporting lines. A territory-based hierarchy lets the same person forecast differently per territory, which suits overlay and channel teams. The two cannot be mixed inside a single forecast type. Whichever you choose, the hierarchy is a distinct view in Setup, reached through Define Forecast Managers and Their Subordinates, and you assign a forecast manager on each node there. The underlying role or territory tree stays the source of the parent-child links.
The forecast manager makes a node roll up
Each level in the tree can have one forecast manager. That person's grid shows the combined forecast of every enabled user at their level and everyone below them. Assigning the manager is a deliberate step, separate from creating the role or territory. A level that contains enabled forecast users but has no forecast manager becomes a dead end. The numbers from those users do not climb any higher, and a gap appears in the executive's totals. This is one of the quietest failure modes in a forecasting rollout, because each rep still sees a correct personal grid while the rollup silently loses their pipeline. The fix is to walk the hierarchy in Setup and confirm a manager sits on every level that has reps under it. On the User record, the person designated as a forecast manager carries ForecastEnabled set to true, which you can confirm with a quick SOQL check across the active roster.
Enabling a user is its own switch
Holding a role or territory is not enough to appear in the forecast. Each person must be enabled for forecasting through the Enable Users page in Setup. Enabling a user inserts them into the forecast grid and flips ForecastEnabled to true on their User record. Removing them takes them out of the live grid while leaving historical forecasting data in place, so you do not lose past numbers when a rep moves on. New hires are the usual sticking point. A rep can have a Sales Cloud license, a role, and open opportunities, yet still show nothing in their manager's grid because the enable step was skipped after the license was granted. A short onboarding checklist that includes enabling forecasting prevents the most common rollout bug. The same page is where you disable someone who has left the team, which keeps the grid honest without deleting their contribution to closed periods.
Up to four forecast types share the hierarchy
An org can run up to four forecast types at once, such as Opportunity Revenue, Opportunity Quantity, an Opportunity Splits type, and a Product Family type. All of them read from the same forecasts hierarchy. A user enabled in the hierarchy rolls up to the same forecast manager across every type they participate in. This keeps the manager-to-rep relationship consistent, so a director who owns a region sees that region's pipeline whether they are looking at revenue or quantity. The forecast types differ in what they measure and how they bucket amounts, not in who rolls up to whom. That single shared tree is convenient, but it also means a structural mistake, like a missing manager on one level, breaks every type at once. When you audit the hierarchy, you are checking all forecast types in one pass. Plan the tree first, then layer the types on top, rather than the other way around.
A worked rollout: region with a missing manager
Picture a sales org with a VP role, three regional directors beneath it, and reps under each director. The admin enables all reps for forecasting and assigns a forecast manager to two of the three director roles. The third director role gets created but no forecast manager is set on it. On the Forecasts tab, every rep under that third director sees their own clean grid. The director, however, has no rollup, because no manager was designated to receive it. Worse, the VP's grid is short by an entire region, since the dead-end level never passes its total upward. Sales leadership notices the company forecast looks low and assumes reps are sandbagging. The real cause is one unassigned forecast manager. The fix takes a minute: open Define Forecast Managers and Their Subordinates, select the third director role, and assign the director as its forecast manager. On the next refresh, the region appears and the VP total corrects itself. The lesson is that a clean per-rep view is not proof the rollup works.
Mid-period changes and historical attribution
Hierarchy changes take effect right away and rewrite the rollup math. When a rep is promoted into a new manager's branch, they appear in that manager's grid on the next calculation, and they leave the old one. Salesforce does not snapshot the previous structure, so reports built on the ForecastingItem object reflect only the current parent of record. That makes mid-quarter reorganizations awkward for attribution, because the pipeline appears to move from one manager to another with no historical breadcrumb. If your finance team needs to know who owned a number at the moment a period closed, the platform will not tell you after the fact. The practical workaround is to time hierarchy changes for the first day of a forecast period whenever possible, and to capture a custom snapshot at period close if you need durable history. A scheduled job that writes the manager-of-record into a custom object at close gives you the audit trail that ForecastingItem does not retain on its own.
Auditing the hierarchy with SOQL
Two queries cover most health checks. SELECT Id, Name, ForecastEnabled FROM User WHERE ForecastEnabled = true returns everyone currently active in forecasting, which you can compare against the headcount you expect to be enabled. A second query against UserRole (or the territory model, for territory-based orgs) tells you which levels have a forecast manager assigned and which do not. Combine the two and you can flag the two failure modes that hurt most: a level with enabled users but no manager, and a user enabled by mistake who should not be in the grid. Building this into a report or a small dashboard means any structural change can be checked in minutes, rather than discovered three weeks later when the executive total looks wrong. The Setup hierarchy view also surfaces a warning when a level has users but no manager, but a SOQL-backed audit scales better across a large org and gives you a record you can diff over time.
Set up the forecasts hierarchy
Setting up the forecasts hierarchy means enabling the right people and assigning a forecast manager to every level that has reps under it. Collaborative Forecasts must already be turned on in Forecasts Settings before these steps work.
- Open the forecasts hierarchy in Setup
In Setup, use Quick Find to open the forecasts area, then go to Define Forecast Managers and Their Subordinates. This shows the tree built from your role hierarchy, or your territory model if the org runs territory-based forecasts.
- Enable the users who should forecast
On the Enable Users page, add each rep and manager who should appear in the forecast. Enabling a user inserts them into the grid and sets ForecastEnabled to true on their User record. A Sales Cloud license and a role are not enough on their own.
- Assign a forecast manager to each level
Walk the tree and designate one forecast manager on every level that has enabled users beneath it. That manager's grid receives the rollup from their level and everything below. Leave none blank, or that branch becomes a dead end.
- Verify the rollup on the Forecasts tab
Log in as a manager (or check as that user) and open the Forecasts tab. Confirm each direct report shows as a row and the totals climb correctly to the top. Run a SOQL audit to confirm the active roster and manager assignments match what you expect.
Choose role-based or territory-based when you set up the forecast type. Role-based reuses the role tree; territory-based requires Enterprise Territory Management and lets a user roll up by territory.
Exactly one forecast manager can be designated per role or territory level. This is the user whose grid aggregates the level and its subordinates.
The set of users flipped on for forecasting. Enabling adds them to the grid; disabling removes them from the live grid but keeps their historical forecasting data.
Up to four forecast types can run at once, and all of them roll up through this single hierarchy using the same manager-to-rep links.
- A level with enabled users but no forecast manager is a dead end. Those numbers stop climbing and a gap appears in the executive total, even though each rep sees a correct personal grid.
- Granting a Sales Cloud license and a role does not enable forecasting. The user must be added on the Enable Users page, which is the most common reason a new hire shows zero in their manager's grid.
- Changing who a rep reports to on the User record alone does not move them in the forecast. The forecast hierarchy follows the role or territory tree, so update that structure first.
- Hierarchy changes overwrite the rollup immediately and Salesforce keeps no snapshot of the old tree, so mid-period moves erase the audit trail unless you capture your own.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Forecasts Hierarchy.
- Enable Users in Collaborative ForecastsSalesforce
- User Object Reference (ForecastEnabled)Salesforce
Hands-on resources to go deeper on Forecasts Hierarchy.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What metric would Forecasts Hierarchy typically help improve?
Q2. Which Salesforce Cloud is Forecasts Hierarchy primarily part of?
Q3. Who primarily uses Forecasts Hierarchy in a Salesforce org?
Discussion
Loading discussion…