Reporting Snapshot Target Object
A Reporting Snapshot Target Object is the custom object that stores the data a Reporting Snapshot captures each time it runs.
Definition
A Reporting Snapshot Target Object is the custom object that stores the data a Reporting Snapshot captures each time it runs. You pick this object when you define the snapshot, and every report row from the source report becomes one new record on it. Salesforce also calls the feature an Analytic Snapshot, so you may see the older name in some setup screens.
The target object is where history lives. A standard report shows data as it looks right now, but a snapshot writes a dated copy of those results into the target object on a schedule. Build reports and dashboards on the target object and you can compare last week to this week, or chart a number's movement across months.
How the target object captures and keeps history
Why a snapshot needs a separate object
Salesforce records normally hold one current value per field. When an opportunity amount changes, the old amount is gone unless field history tracking saved it, and history tracking has its own limits. A Reporting Snapshot solves the broader case. It runs a source report on a schedule, then writes the results as fresh records into a target object you choose. Because each run adds new rows instead of overwriting old ones, the target object slowly fills with dated copies of the same metrics. That stored history is the whole point of the feature. The target object has to be a custom object. You cannot point a snapshot at Account, Contact, or any standard object, so most teams create an object whose only job is holding snapshot output. A common pattern is a "Pipeline Snapshot" object that stores the open pipeline total per sales stage, captured every Monday. Six months later that object holds 26 weekly readings per stage, which is enough to chart how pipeline built or shrank over the quarter.
Designing the fields that receive the data
Field mapping is where the target object earns its keep. During setup you connect each source report column to a field on the target object, and Salesforce only lets you pair fields with compatible data types. A currency column can feed a number field, but it will not feed a checkbox. So you design the target object's fields to mirror the report first. If the report shows stage name, count, and amount, the target object needs a text field, a number field, and a currency or number field ready to receive them. Add a date or date/time field too, because you usually want to know which run each record came from. A few targets are off limits during mapping. You cannot map into Created By, Last Modified By, Created Date, or Last Modified Date, since the platform owns those. Lookup columns map to the related record's ID rather than its name. Keep field names plain and descriptive, because months later a teammate reading "Pipeline_Amount__c" understands it instantly, while a vague name forces guesswork.
The 2,000 record limit per run
The most important number to know is the per-run cap. When a Reporting Snapshot runs, it can add up to 2,000 new records to the target object. If the source report returns more than 2,000 rows, the extra rows are dropped and the run finishes as a partial success with a warning. This catches people who point a snapshot at a wide tabular report. A tabular report lists every matching record, so a report over 2,000 detail rows loses data on every run. A summary report behaves differently because you snapshot a grouping level, not the raw rows. Snapshotting the stage grouping of an opportunity report might produce only a handful of records per run, one per stage, which sits far under the cap. The fix when you hit the limit is almost always to summarize. Group the report and snapshot the group totals, or tighten the report filters so it returns fewer rows. Designing the source report to stay well under 2,000 rows keeps the target object accurate and your trend charts honest.
Restrictions the target object must respect
A target object cannot carry the automation a normal object often has. It cannot be the detail side of a master-detail relationship, and it cannot have validation rules, workflow rules, or Apex insert triggers. It also cannot exceed 100 custom fields. These rules exist because a snapshot inserts records in bulk on a schedule, and any automation that fires on insert could block or distort that load. A validation rule that rejects a blank field, for example, would fail records the snapshot tried to write. Plan the object as a quiet storage bin, not an operational record that people edit. Currency causes a specific trap in multi-currency orgs. The records flowing into the target object should share one currency code, otherwise the snapshot can report a mismatch. Salesforce suggests mapping the converted currency amount instead of the raw amount so every value lands in the same currency. Because of all this, the cleanest target objects are purpose-built, free of triggers and rules, and dedicated to one snapshot rather than shared across several feeds.
Reading the history back out
Once data accumulates, the target object becomes a normal reporting source. You build a custom report type on it, then create reports and dashboards exactly as you would on any object. A line chart grouped by your snapshot date field shows a metric moving over time, which is the payoff for all the setup. To compare two objects, say the source pipeline and the stored snapshot, you can place charts from both on one dashboard. The snapshot's date field is what makes time-series analysis possible, so always capture it. Filtering matters as the object grows. After a year of weekly runs the object can hold thousands of records, so dashboard filters and report date ranges keep views focused on the period that matters. Some teams add a simple "snapshot label" field, populated from a report column, so they can slice history by region or product line later. The running user you set on the snapshot also shapes what gets captured, because the report runs with that user's data access. A running user who cannot see certain records produces a snapshot missing those rows.
A worked example: weekly pipeline tracking
Picture a sales operations admin who wants a weekly read on open pipeline by stage. They build a summary report of open opportunities grouped by Stage, showing the record count and the summed Amount. Next they create a custom object called Pipeline Snapshot with four fields: Snapshot Date (date), Stage (text), Opportunity Count (number), and Pipeline Amount (currency). In Setup they open Reporting Snapshots, create a new one, choose the summary report as the source, set themselves as the running user, and pick Pipeline Snapshot as the target. On the mapping screen they choose the Stage grouping level, then connect each report column to its matching field and map the run date into Snapshot Date. They schedule it to run every Monday at 6 AM. Each Monday the snapshot writes one record per stage, maybe seven records total, which stays far under the 2,000 cap. After a quarter the object holds roughly 91 records, and a report grouped by Snapshot Date with a line for each stage shows exactly how the pipeline moved week over week.
Set up a Reporting Snapshot target object
You configure the target object and wire it to a snapshot in Setup. Build the custom object and its fields first, then create the Reporting Snapshot and map the source report columns onto those fields.
- Create the custom object
In Setup, build a custom object dedicated to snapshot output. Add fields whose data types match the source report columns you plan to capture, plus a date field to record which run each record came from.
- Build or pick the source report
Create a tabular or summary report that returns the data you want to track. Keep it under 2,000 result rows. For trend data, a summary report grouped by a dimension like Stage usually works best.
- Create the Reporting Snapshot
From Setup, open Reporting Snapshots and click New. Give it a name, set a running user whose access matches what you want captured, choose the source report, and choose your custom object as the target.
- Map fields and save
On the mapping screen, pick a grouping level for summary reports, then connect each source column to a compatible target field. Map your snapshot date field too, then save.
- Schedule the run
Set the snapshot to run daily, weekly, or monthly. Pick a time outside business hours so the bulk insert does not compete with user activity.
Required. Must be a custom object with no validation rules, workflow rules, or Apex insert triggers, no master-detail detail role, and at most 100 custom fields.
Required. A custom tabular or summary report. Legacy forecast, Quota vs Actual, and Leads by Source reports cannot be used.
Required. The user whose data access the report runs under. Only users with Modify All Data can set a running user other than themselves.
For summary reports only. Selects which grouping's totals are snapshotted, or use Grand Summary for the overall totals.
Daily, weekly, or monthly, with a start and end date. Sets how often new records are written to the target object.
- Each run adds at most 2,000 records. A source report over 2,000 rows loses the extra rows and finishes as a partial success.
- You cannot map into Created By, Last Modified By, Created Date, or Last Modified Date on the target object.
- A blank Total Row Number on the run history usually means an inactive running user or a deleted or changed source report.
- In multi-currency orgs, map the converted currency amount so all values land in one currency code and avoid mismatch errors.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Reporting Snapshot Target Object.
- Define a Reporting SnapshotSalesforce
- Map Reporting Snapshot FieldsSalesforce
Hands-on resources to go deeper on Reporting Snapshot Target Object.
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 Reporting Snapshot Target Object?
Q2. What happens when a snapshot runs?
Q3. What should target objects enable?
Discussion
Loading discussion…