A Salesforce report shows the current state of records. It cannot tell you what your pipeline looked like six weeks ago, because that information does not exist unless something was capturing it at the time. Every point-in-time question you will ever be asked has to be set up in advance, and the day the question arrives is too late.
Why the obvious approach fails
The instinct is to filter on close date and created date and reconstruct history. It does not work, and it is worth knowing exactly why.
A report reads today’s field values. An opportunity that sat at 50,000 in Proposal last month and is now 30,000 in Negotiation reports as 30,000 in Negotiation, with no trace of the earlier state. Deals that have since slipped out of the quarter do not appear in a quarter filter at all. Deals closed lost and reopened look as though they were never lost.
So the difference between last month’s pipeline report and this month’s is not explainable from the data. Everyone assumes it is, and the reconciliation meeting is where they find out.
Historical Trending
This is the built-in answer and the one to try first. Enable it in Setup, select the object, select the fields to track, and Salesforce stores a daily value for those fields.
You get a report type comparing a field’s value now against its value on a chosen past date, with the change alongside. Available on Opportunity, Case, Forecasting Items and custom objects.
The constraints shape how you use it:
- Only a handful of objects, and a small number of fields per object. Choose deliberately: amount, stage, close date and forecast category cover most pipeline questions.
- History is retained for roughly three months. It answers questions about this quarter and cannot answer questions about last year.
- It starts from the day you enable it. There is no backfill.
Enable it on day one of any implementation, on the fields you might plausibly be asked about. The cost of tracking a field nobody asks about is nothing. The cost of not tracking one is a question you cannot answer for three months.
Reporting snapshots for the long view
Where you need more than a quarter, a reporting snapshot is the tool. It runs a source report on a schedule and writes the rows into a custom object you define, mapping report columns to fields.
Two patterns cover most needs.
Summary snapshot. A source report grouped by stage and owner, writing one row per group per week. Small, fast, and enough for a pipeline trend chart going back years. This is the one to build first.
Detail snapshot. One row per open opportunity per week, with amount, stage and close date. Much larger, and it answers questions about individual deals, such as how often one slipped. Watch the growth: a thousand open deals snapshotted weekly is over fifty thousand records a year.
Snapshots cap how many rows a single run captures, which is the constraint people hit. If the source report returns more, the run truncates quietly. Keep the source summarised or filtered, and check the snapshot’s run history occasionally.
The other history sources
OpportunityHistory is a standard object that records changes to stage, amount, probability and close date, and it is reportable through the opportunity history report types. It is the quickest way to answer how long deals sit in each stage, and it exists without you enabling anything.
Field history tracking stores one row per tracked change on the field history objects. It is an audit log, not an analytics source: no row exists for days when nothing changed, so a trend built from it means filling gaps yourself. Field Audit Trail extends retention where that is a compliance need rather than a reporting one.
What to build on day one
Historical Trending enabled on Opportunity for amount, stage, close date and forecast category. A weekly summary snapshot of pipeline by stage and owner. Field history tracking on close date and amount. That is an afternoon’s work and it means that in a year, when someone asks what changed, there is an answer.
Frequently asked
Can I backfill historical trending? No. It records from enablement onwards, which is the whole reason to enable it early.
Can a snapshot source report use a joined report? No. Keep source reports to a single report type, tabular or summary.
Where does the snapshot data live? In a custom object you create, so it counts against data storage and it is yours to report on, share and delete.
Is there a way to see deleted opportunities in a trend? A snapshot taken before the deletion keeps its row, which is a quiet argument for detail snapshots in businesses where records get deleted.
