Forecast User
A Forecast User is a Salesforce user who has been enabled for Collaborative Forecasts, appears in the forecast hierarchy, and whose owned opportunities roll up into a forecast number.
Definition
A Forecast User is a Salesforce user who has been enabled for Collaborative Forecasts, appears in the forecast hierarchy, and whose owned opportunities roll up into a forecast number. Forecast users see their own forecast grid on the Forecasts tab. If a user is also designated a forecast manager, they see the rolled-up grids of everyone reporting to their role in the hierarchy. Only enabled forecast users contribute to anyone's roll-up.
Enabling a forecast user takes two things. First, the user needs the "Allow Forecasting" permission, set per user so you keep granular control even when several teams share one profile. Second, an admin adds the user to the forecast hierarchy. A rep can hold a Sales license, a role, and a quota and still show zero in the grid until both of these are in place.
How a user becomes part of the forecast roll-up
The "Allow Forecasting" permission
The first gate is the "Allow Forecasting" user setting. Salesforce documents this as a per-user permission, which is deliberate. Two reps can share the same profile, yet only one of them needs to forecast. Setting it on the user record (not the profile) gives you that precision. Without "Allow Forecasting" turned on, the user never shows up as eligible in the hierarchy, so nothing they own can roll up. This is the single most common reason a new hire is missing from the forecast. The license and the role are correct, the quota is loaded, but the per-user permission was skipped during onboarding. Salesforce's own "users missing from pipeline forecasting" guidance lists "Allow Forecasting" as the first thing to check. The setting is independent of the Sales license. A Sales license makes a user eligible to be enabled, but does not enable them. Treat the permission as the real switch and verify it before you debug sharing or hierarchy issues.
Enabling users in the forecast hierarchy
The second gate is placement in the forecast hierarchy. After "Allow Forecasting" is on, an admin opens the hierarchy in Forecasts Settings and uses Enable Users to move eligible people from an Available list into an Enabled list. Only enabled users carry a forecast number. The hierarchy itself is generated from the user role hierarchy, so the structure mirrors your roles rather than the User.ManagerId field. If the role tree does not match real reporting lines, you fix that in Roles first, because the forecast hierarchy cannot be rewired on its own. Salesforce notes that a user becomes visible in the hierarchy once a forecast manager is assigned to a role above them. So enabling a single rep with no manager assigned anywhere above can still leave gaps in what rolls up. The practical sequence is reliable: confirm the role tree, turn on "Allow Forecasting," enable the user, then assign managers down the tree. Done in that order, the rep appears in the right grid on the next refresh.
Forecast managers and roll-up
A forecast manager is a forecast user who also rolls up the numbers of people below them. The hierarchy allows exactly one forecast manager per level, and that manager supervises the level directly beneath. This is what produces the nested, expandable grid a manager sees. Their own commit and best case sit at the top, and each subordinate's forecast sits one row down, expandable to that person's own view. Managers also get rights the role-based hierarchy alone does not grant: they can adjust the forecasts of people one level below them, and they can share their forecast with stakeholders who need to see it. Because the hierarchy is role-driven, promoting a rep to manager is not a forecast task by itself. You assign them as the forecast manager for their role, and the roll-up follows. The shape of the grid, who sees whom, and whose numbers aggregate where, all trace back to which role holds which manager. Get the manager assignments right and the rest of the forecast math lines up automatically.
Role-based versus territory-based hierarchy
The hierarchy type is not a global choice. It is set per forecast type. Each forecast type names the object the forecast is based on, whether the measure is revenue or quantity, the date it measures by, and the hierarchy used to roll numbers up. That last property is where role-based and territory-based diverge. A revenue pipeline forecast might roll up through the role hierarchy, while a separate forecast type rolls up through Enterprise Territory Management instead. For territory-based forecasts, a user's place in the roll-up comes from territory assignment, not role. This matters when you enable users. A rep can be enabled and visible in a role-based forecast yet absent from a territory-based one because they are not assigned to a territory in the relevant model. When a user appears in one forecast and not another, check which hierarchy each forecast type uses before assuming the enablement itself failed. The two models answer different questions and are configured independently.
Quotas and attainment for enabled users
Quotas are optional in Collaborative Forecasts, but most teams load them so the grid shows attainment as a percentage. A quota is tied to a user and a forecast type, usually loaded through the Data Loader or the API against the forecasting quota data. Loading a quota for someone who is not an enabled forecast user is allowed but does nothing useful. They do not appear in the grid, so no attainment is calculated against the number. The dependable order is to enable the user first, then load the quota. Quotas can be revised mid-period without re-enabling the user, which is handy when targets change after a reorganization. One subtle point: attainment compares the rolled-up forecast against the quota for the same user and type, so a manager's attainment reflects their team roll-up, not just their personal deals. If a quota looks wrong, confirm it was loaded against the correct forecast type. A revenue quota attached to a quantity forecast type will not line up the way the team expects.
Hierarchy changes during a quarter
Salesforce updates the roll-up live when the forecast hierarchy changes. Move a rep to a new region, promote someone to manager, or reassign a forecast manager, and the next grid refresh reflects it. The new manager gains visibility into the moved rep, and the old manager loses it. There is no snapshot of the previous hierarchy kept for you. That has a real consequence for reporting. If finance needs to know who owned a forecast at the start of the quarter versus the end, the live structure will not tell them, because it only shows the current state. Teams that need historical manager attribution build it themselves, often by exporting forecasting data on a schedule or logging hierarchy changes to a custom object. Plan this before a big reorganization, not after. Reproducing a quarter-start hierarchy from memory is painful, and the forecast grid gives you no way to rewind. The same live behavior that keeps the current grid accurate is exactly what erases the trail you might later want.
Partner users in the forecast
Forecasting is not limited to internal reps. Salesforce supports enabling partner portal users so the opportunities they add can flow into pipeline forecasts. When enabled, a partner rep contributes pipeline that a channel manager can see alongside direct pipeline, depending on how the forecast type and hierarchy are configured. This is configured through the same forecasting setup, with the partner-facing enablement handled as its own step. Treat partner enablement as a decision, not a default. Adding channel pipeline into commit calls changes the numbers leadership reviews, so only enable partners when the team genuinely uses that pipeline in forecasting. The mechanics still come down to the same two ideas covered throughout this entry. The partner user must be eligible and enabled, and the hierarchy must place their numbers somewhere that rolls up. Where they land depends on the hierarchy model the forecast type uses. Confirm both before expecting partner deals to appear in a manager's grid, and verify the licensing for partner forecasting in your edition.
Enable a Forecast User in Collaborative Forecasts
Enabling a forecast user is two settings, applied in order. Turn on the per-user "Allow Forecasting" permission, then add the user to the forecast hierarchy. Both must be in place before the user's opportunities roll up or their grid appears. Collaborative Forecasts must already be enabled in Forecasts Settings.
- Confirm the role hierarchy
The forecast hierarchy is generated from the user role hierarchy. Before enabling anyone, make sure the role tree matches real reporting lines, because you cannot rewire the forecast hierarchy separately.
- Grant "Allow Forecasting" on the user
Set the per-user "Allow Forecasting" permission so the user becomes eligible. Doing this on the user (not the profile) keeps control granular when several teams share one profile.
- Enable the user in the hierarchy
In Forecasts Settings, open the forecast hierarchy and use Enable Users to move the user from the Available list into the Enabled list. Only enabled users carry a forecast number.
- Assign forecast managers down the tree
Set one forecast manager per role level. A user reporting to a role becomes visible once a forecast manager sits above them, so assign managers from the top down.
- Load quotas and verify the grid
Optionally load the quota for the user and forecast type, then check the Forecasts tab. The rep should appear in the correct grid on the next refresh with attainment calculated.
The user-level permission that makes someone eligible to forecast. Without it the user never appears in the hierarchy and nothing they own rolls up.
The action in the forecast hierarchy that moves eligible users from Available to Enabled. Only enabled users contribute a forecast number.
One manager per level, supervising the level below. Grants the right to adjust subordinates' forecasts and share the forecast with stakeholders.
Each forecast type rolls up through either the role hierarchy or a territory hierarchy. This decides which placement makes a user appear in that forecast.
- A user with a Sales license, a role, and a quota still shows zero until both "Allow Forecasting" is on and they are enabled in the hierarchy.
- Users go missing most often because "Allow Forecasting" was skipped, or because no forecast manager is assigned to a role above them.
- The hierarchy follows roles, not User.ManagerId. Fix the role tree first; the forecast hierarchy cannot be rewired on its own.
- A rep can appear in a role-based forecast but not a territory-based one if they are not assigned in the territory model that forecast type uses.
Prefer this walkthrough as its own page? How to Forecast User in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Forecast User.
- Define Forecast Managers and Their SubordinatesSalesforce
- Give Users Access to ForecastsSalesforce
Hands-on resources to go deeper on Forecast User.
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 actually defines someone as a Forecast User in Collaborative Forecasts?
Q2. A rep has a Sales license and a quota but still produces zero in the manager's forecast. Why?
Q3. When should the Forecast User roster and hierarchy be updated to keep forecasts accurate?
Discussion
Loading discussion…