Reporting Snapshot
A Reporting Snapshot is a Salesforce feature that captures the results of a source report on a schedule and saves them as records on a custom object.
Definition
A Reporting Snapshot is a Salesforce feature that captures the results of a source report on a schedule and saves them as records on a custom object. Each run writes a fresh batch of records, so the target object slowly builds a history of point-in-time data you can report on later. The feature is sometimes still called an Analytic Snapshot, its older name.
Salesforce does not track historical changes to most fields by default. A standard report always shows the current state of your data. Reporting Snapshots fill that gap by saving a copy of report results at set intervals, which lets you trend metrics like open case counts or pipeline value across days, weeks, or months.
How a Reporting Snapshot Builds History
The three pieces every snapshot needs
A working snapshot has three parts that you wire together in Setup. The first is a source report, which must be a custom tabular or summary report. Standard reports, legacy forecast reports, quota versus actual reports, and Leads by Source reports cannot be used as a source. The second piece is a custom object that acts as the target, where each run drops new records. The third piece is the field mapping that connects columns in the report to fields on that custom object. You also pick a running user. That user's sharing and field access decide what data the source report can actually see when the snapshot runs. Only someone with the Modify All Data permission can set a running user other than themselves, so most admins run snapshots as their own user or a dedicated integration account. Choosing the running user carefully matters, because a user with narrow visibility produces a thin snapshot. Get these pieces right and the rest of the setup is mostly mapping and scheduling.
Mapping report fields to the target object
Field mapping is where most of the configuration time goes. You match each field coming from the source report to a field on the target custom object. Salesforce only lets you map fields with compatible data types, though it is flexible in sensible ways. For example, a currency field can map to a number field. You can also set a source field to Load No Data, which tells the snapshot to skip it. A few fields are off limits as targets. You cannot map to Created By, Last Modified By, Created Date, or Last Modified Date, because Salesforce manages those system fields itself. To populate a lookup field on the target, you map to the ID of the related record rather than its name. If you map a summary report, you choose a grouping level for the data you want, and the Grand Summary option pulls totals across every grouping. Custom summary formulas only map when their grouping level matches the level you picked for the snapshot.
Scheduling when snapshots run
Once mapping is done, you schedule the snapshot to run daily, weekly, or monthly. Weekly runs let you pick specific days of the week. Monthly runs include a handy option to fire on the last day of every month, which keeps your history consistent even though months differ in length. You set a preferred start time, but Salesforce only promises the run happens within an hour of that time, so do not depend on it to the minute. You can also turn on email notifications. The running user can choose to notify themselves, and Others lets you add specific users or public groups. Each notification reports the date and time the snapshot ran, whether it succeeded, and how many records were loaded. That alert is your early warning system. If a snapshot quietly stops loading data, the notification is usually the first place an admin notices, which is why pointing it at a real person or a monitored group is worth the extra click.
The 2,000 row limit and what it means
The single most important limit to remember is row count. A reporting snapshot can add up to 2,000 new records to the target object on each run. If the source report returns more than 2,000 rows, the extra rows are simply not recorded, and the run notification flags that some rows failed. This is silent data loss if you are not watching for it. This limit shapes how you design the source report. For trending, you rarely need 2,000 detail rows per run. A summary report that rolls data up to a manageable number of grouped rows is usually the better choice, both for staying under the cap and for keeping the target object clean. If you genuinely need many rows, filter the source report tightly or split the work across more than one snapshot. Each snapshot run still counts toward your daily scheduled job allocations, so very high frequency snapshots on large reports can pressure both the row cap and the broader scheduling limits in your org.
A worked example: trending open cases
Salesforce's own documentation uses a support scenario, and it maps neatly to real work. Say a support manager wants to track open cases by priority over time. First you build a summary report of open cases grouped by priority, with a record count. Next you create a custom object, for example Open Case History, with fields for the snapshot date, priority, and case count. Then you define the snapshot, choosing that report as the source and Open Case History as the target. In field mapping you connect the priority grouping and the record count to your custom fields, and you map the run time to a date field so each row is stamped. Finally you schedule it to run daily at 5:00 PM and notify the manager. After a couple of weeks, the Open Case History object holds a dated row per priority per day. Now a simple report or dashboard line chart over that object shows whether the high priority backlog is climbing or falling, something the live case report alone could never tell you.
Common reasons a snapshot fails
Snapshots fail for a predictable set of reasons, and knowing them saves hours of guessing. On the source side, a run breaks if the report was deleted, if the running user loses the Run Reports permission, if that user cannot access the report's folder, or if the report uses invalid formulas or filters. A source report that exceeds 100 fields, or one that was converted from summary to tabular format after mapping, will also fail. The target object has its own rules. A snapshot cannot load into an object that has validation rules, workflow rules, Apex insert triggers, or more than 100 custom fields. The target also cannot be the detail side of a master-detail relationship. If any required field on the target is left unmapped, the run fails. An inactive running user stops everything. Because these conditions are easy to introduce later through unrelated changes, treat a target snapshot object as off limits for new automation, and review it whenever a long running snapshot suddenly goes quiet.
How to create a Reporting Snapshot
You build a reporting snapshot in Setup after you already have a custom source report and a custom target object with fields ready to receive the data. The flow below covers defining the snapshot, mapping fields, and scheduling it.
- Prepare the source report and target object
Create a custom tabular or summary report with the columns you want to trend. Then create a custom object with fields sized to hold each value, plus a date or date-time field to stamp each run.
- Define the snapshot
In Setup, use Quick Find to open Reporting Snapshots and click New Reporting Snapshot. Enter a name, unique name, and description, pick a running user, then select your source report and target object.
- Map the fields
Click Save and Edit Field Mappings, or open the Field Mappings section and click Edit. Match each source report field to a compatible target field. For a summary report, pick the grouping level (or Grand Summary) that holds the data you want.
- Schedule and notify
Set the snapshot to run daily, weekly, or monthly, choose a preferred start time, and add email notifications for yourself or a monitored group so you catch failed runs early.
The label and API-safe unique name that identify the snapshot in Setup.
The user whose data access governs what the source report returns; only Modify All Data lets you pick someone other than yourself.
A custom tabular or summary report whose results are captured on each run.
The custom object that receives new records; it cannot have validation rules, triggers, or be a master-detail detail object.
- Each run loads a maximum of 2,000 rows into the target object; rows beyond that are dropped and the notification flags the partial failure.
- You cannot map to Created By, Last Modified By, Created Date, or Last Modified Date on the target object.
- Adding validation rules, workflow, Apex insert triggers, or a 101st custom field to the target object will break later runs.
- Converting the source report from summary to tabular after mapping, or pushing it past 100 fields, causes the snapshot to fail.
Prefer this walkthrough as its own page? How to Reporting Snapshot in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Reporting Snapshot.
- Define a Reporting SnapshotSalesforce
- Map Reporting Snapshot FieldsSalesforce
Hands-on resources to go deeper on Reporting Snapshot.
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 does a Reporting Snapshot do on the schedule an admin defines for it?
Q2. Why is a Reporting Snapshot the standard way to build trend data in Salesforce?
Q3. Where do a Reporting Snapshot's captured rows land after each scheduled run completes?
Discussion
Loading discussion…