Skip to content
Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
DictionarySSource Report
AnalyticsAdvanced

Source Report

A Source Report in Salesforce is the existing tabular or summary report that feeds rows into a Reporting Snapshot.

§ 01

Definition

A Source Report in Salesforce is the existing tabular or summary report that feeds rows into a Reporting Snapshot. The snapshot engine runs the source report on a schedule, takes the resulting rows, and writes a copy of the data to a custom Salesforce object as a point-in-time snapshot. The source report is therefore the query layer in the snapshot architecture; the custom object is the storage layer where trend analysis runs against the historical copies.

Source reports are the only data source Reporting Snapshots accept. They cannot run directly on SOQL, on external systems, or on an Apex method. Whatever data you want to capture historically must first be a runnable Salesforce report. This constraint shapes how teams design their snapshot programs: build the report you want to capture, lock its filters, then point a Reporting Snapshot at it.

§ 02

How a Source Report drives the Reporting Snapshot pipeline end to end

The snapshot architecture

A Reporting Snapshot has three parts. The Source Report is the existing tabular or summary report that produces rows. The Target Object is a custom object whose fields map to the source report columns. The Schedule defines how often (daily, weekly, monthly) the snapshot job runs. When the job fires, Salesforce executes the source report, maps each row's columns into matching target-object fields, and inserts records into the target object stamped with the run timestamp. Over time the target object accumulates a series of point-in-time copies that trend analysis reports query.

Source report report types

Source reports must be tabular (no groupings) or summary (one grouping level). They cannot be matrix reports, joined reports, or row-level formula reports. The constraint exists because each row in the report maps to exactly one record in the target object; matrix and joined reports do not have a stable one-row-per-output shape. The reporting team usually designs a source report specifically for snapshot capture, separate from the report users see in dashboards.

Column mapping

When you create a snapshot, Salesforce shows the source report columns on the left and the target object fields on the right, with a dropdown to map each pair. Column data types must match the target field types (text-to-text, number-to-number, date-to-date). Salesforce-supplied auto-mappings handle the obvious matches; the admin manually maps anything ambiguous. Once mapped, the column-to-field bindings are stored with the snapshot configuration and re-used on every run.

Running user and source-report filters

Each snapshot runs as a specific Running User. The source report executes with that user's data visibility, role hierarchy, and sharing rules. This matters because a report designed by an admin with View All Data returns more rows than the same report run as a sales rep restricted by sharing rules. Plan the running user so the snapshot captures the intended scope. The source report's filters also run as-is; if the filter uses today() or this-month, the snapshot captures only the data matching that relative window at run time.

Schedule and history accumulation

Snapshots run daily, weekly, or monthly. A daily snapshot of a 1,000-row source report adds 1,000 rows to the target object every day, 30,000 rows a month, 360,000 rows a year. The volume math matters because the target object counts against data storage. Long-running daily snapshots can become storage-expensive; many teams use weekly or monthly cadence to balance the granularity they need with the storage they pay for.

Common source report patterns

The most common source reports for snapshot capture are: open opportunities by stage and amount (for pipeline aging), case backlog by priority (for service SLA trends), product inventory by warehouse (for stock burn), forecast commits by rep (for forecast accuracy), and training completion by employee (for compliance reporting). Each report design has a snapshot pattern that drops the right point-in-time view into a custom object the analytics team can graph.

Source report drift and snapshot integrity

Editing the source report after a snapshot is configured can corrupt the snapshot pipeline. Adding or removing columns breaks the column mappings; the admin must re-open the snapshot configuration and re-map. Changing filter logic silently changes the rows captured going forward. The historical rows already in the target object stay where they are, but a year-over-year trend chart suddenly compares two different population shapes. Treat the source report as a versioned artifact; document each change and assess the snapshot impact before saving.

§ 03

Build a source report and wire it into a Reporting Snapshot

Create a tabular source report, build a custom target object with matching fields, then schedule a Reporting Snapshot that captures the source report rows on a recurring basis.

  1. Design the source report

    Open the Reports tab. Click New Report. Pick the report type. Choose Tabular or Summary format. Add columns and filters that capture exactly the rows you want snapshotted.

  2. Save the source report

    Save with a name that signals it is for snapshot use (Source Report: Open Pipeline). Document the filters and columns in the description field for future maintenance.

  3. Create the target custom object

    Setup, Object Manager, Create. Add a custom object with one field per source report column. Match data types exactly (text, number, date).

  4. Configure the Reporting Snapshot

    Setup, Reporting Snapshots, New Reporting Snapshot. Pick the source report, the target object, the running user, and the field mappings.

  5. Schedule the run

    Set the start date, frequency (daily, weekly, monthly), and preferred run time. The job runs in the background and populates the target object.

  6. Validate after first run

    Wait for the first scheduled run. Open the target object's list view. Confirm the row count and field values match the source report at the run timestamp.

Gotchas
  • Source reports must be Tabular or Summary. Matrix and Joined reports cannot drive a snapshot; convert the report type before wiring it in.
  • Editing the source report breaks column mappings if you add, remove, or rename columns. Re-open the snapshot configuration and re-map after any source change.
  • Running user matters. A source report run as an admin returns different rows than the same report run as a sales user; pick the user whose visibility you actually want captured.
  • Daily snapshots of large source reports consume target-object storage quickly. Estimate the row count and multiply by the schedule frequency to size storage cost.
§

Trust & references

Sources

Cross-checked against the following references.

Official documentation

Straight from the source - Salesforce's reference material on Source Report.

Keep learning

Hands-on resources to go deeper on Source Report.

Was this entry helpful?
Help us write better definitions. Quick reactions or detailed edit suggestions.

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 is a Source Report?

Q2. What determines what gets captured?

Q3. Should you use existing analytical reports?

§

Discussion

Loading…

Loading discussion…

Back to Dictionary