What Is Salesforce Custom Forecasting Data?
If you’ve ever sat in a forecast call wishing you could see a stretch number, a prior-year actual, or a budget target in the same grid as your commit — you’ve run into the reason Salesforce Custom Forecasting Data exists.
It’s one of those Salesforce features that’s quietly powerful and almost invisible until someone points it out. Here’s what it is, what it does, and where it stops being enough on its own.
The short version
Salesforce Custom Forecasting Data is a feature that lets you add custom columns to a forecast type. Those columns can be one of two kinds:
- Calculated columns — values computed from a formula you define. Gap to Quota and Pipe Coverage are the two that ship by default.
- Reference data columns — values you load into Salesforce yourself, stored on a dedicated object called Forecasting Custom Data. Stretch quotas, internal booking targets, prior-year actuals, and any other numeric data you want to see on the forecast page.
Each forecast type can hold up to five custom columns total — calculated and reference data combined. Gap to Quota and Pipe Coverage count against that limit if enabled.
Why this matters
Salesforce forecasting out of the box gives you a forecast category (Closed, Commit, Best Case, Pipeline) and a quota. That’s it. Every other number you care about — the stretch goal from the SKO, last year’s booked revenue, the budget number finance is watching, a new-logo target, a ramp-adjusted plan — lives outside the forecast.
So reps open the forecast, then open a spreadsheet, then open another tab for the board deck. Decisions get made against whichever number was most recently updated, which is usually not the forecast.
Custom Forecasting Data is Salesforce’s answer to that. Load the number once. It appears next to the forecast, roll-ups and all, for everyone in the hierarchy.
How it works, technically
The reference-data path — the interesting one — stores everything on the Forecasting Custom Data object. You add custom number or currency fields to that object in Setup. Then, on a given forecast type, you tell Salesforce “show me this field as a column.”
To get data into those fields, Salesforce’s documented method is Data Loader (or the Enterprise API). You prepare a CSV with these columns:
- User ID
- Forecast Type ID
- Period Start Date (e.g.
2026-04-01) - One column per data field
- Territory ID (if you’re using territory forecasts)
- Product Family (if you’re using product-family forecasts)
You map the CSV columns to the Forecasting Custom Data object, run the load, and the numbers show up on the forecast page.
Permissions gate who can do this: Manage Forecasting Custom Data lets a user load and manage data for themselves and their subordinates. View All Forecasts lets them do it for the whole hierarchy.
What you can’t do with the native feature alone
The feature works. It does what it says. But once teams start using it in earnest, the rough edges show up.
The 5-column ceiling is low
Five columns sounds like plenty until you realize Gap to Quota and Pipe Coverage already take two, you want a stretch goal, a prior-year actual, a budget number, and a new-logo target — and now you’re out. Cutting one means losing context somewhere.
Calculated columns have gotchas
Custom calculated columns don’t show 7-day change and aren’t included in rollups. They also can’t be adjusted. And if you have even one active calculated column, Salesforce blocks you from switching from single-category to cumulative rollups, enabling the Most Likely category, or disabling Show Quotas.
These aren’t deal-breakers, but they’re constraints worth knowing before you design your forecast around formulas.
Loading reference data is genuinely painful
This is where most teams hit the wall. The only documented way to get Custom Forecasting Data in is Data Loader with a CSV keyed on User ID and Forecast Type ID.
That means:
- You need the Salesforce User IDs for every rep.
- You need the Forecast Type ID (an 18-character string) for the right type.
- You need the exact period start date in ISO format.
- If territory or product-family is in play, you need more IDs.
- You need someone comfortable with Data Loader.
- Every time the number changes — a reorg, a mid-year reforecast, finance revises the plan — you run it again.
Most RevOps teams don’t want to run Data Loader every time a stretch goal shifts. So the numbers either don’t get loaded, or they get loaded once at SKO and go stale by Q2.
It’s editor-less
There is no UI to edit Forecasting Custom Data in place. You can’t click a cell and change a value. Everything is import-and-reload.
So where does that leave you?
Salesforce Custom Forecasting Data is a real, useful feature — and it’s the right place to store the kind of numbers it’s designed to hold. The limits are on the editing and loading side, not the data model.
Which is why most teams that lean into it end up needing a layer on top: an editor that lets you add fields without Data Loader gymnastics, update them like a spreadsheet, and see them everywhere a forecast is shown.
That’s the role Akoonu’s Custom Data Manager plays. It sits on top of Salesforce Custom Forecasting Data and makes it practical to actually use — inline editing, multi-select bulk updates, guided import from Excel (no User IDs, no Forecast Type IDs), fiscal-year copy, and rollups in views where the native feature stops short.
If you’re looking at Salesforce Custom Forecasting Data for the first time, start with the native feature. Get a field defined, load a test batch, see it on the forecast page. Then, when you hit the edit-and-reload wall — and you will — that’s the signal you’ve outgrown Data Loader.
Want to see Custom Forecasting Data managed the way it probably should be? Schedule a demo and we’ll show you Akoonu running on your Salesforce org.
