Reporting Snapshots

5 minutes 5 Questions

Reporting Snapshots (formerly Analytic Snapshots) in Salesforce let you capture report data at scheduled points in time and store it in a custom object, enabling historical trend analysis that standard reports cannot provide because they only show current data. For the Platform Administrator II exam, within the Data and Analytics Management domain, you should understand how they work, their setup requirements, and their limitations. Setup involves four components: (1) a source report, which must be a tabular or summary report (matrix and joined reports are not supported); (2) a target custom object with fields whose data types match the source report fields; (3) field mappings between report columns (or summary groupings) and target object fields; and (4) a schedule defining when the snapshot runs (daily, weekly, or monthly) and a running user whose permissions determine what data is captured. The running user must have access to the source report and the target object. Key rules and limits include: a maximum of 100 fields can be mapped; up to 2,000 rows are loaded per run (extra rows are discarded); the target object cannot have validation rules, triggers, workflow, or be a detail in a master-detail relationship; and you cannot map the report's Record Count summary field to a lookup. The snapshot timestamps each run, so you can later build reports and dashboards on the custom object to show trends, such as pipeline size over months or case backlog over weeks. Typical use cases: tracking the number of open cases at the end of each day, monitoring opportunity amounts by stage over time, or auditing changes in lead volume. Administrators should also know to monitor the Run History and Scheduled Jobs for errors, such as field mismatch or deactivated running users. In short, Reporting Snapshots turn point-in-time report results into persistent records, bridging the gap between real-time reporting and historical analytics without needing external BI tools.

Reporting Snapshots: Capturing Historical Data for Trend Analysis in Salesforce

Why Reporting Snapshots Matter
Standard Salesforce reports show data as it exists right now. If a sales manager asks, "How many open Opportunities did we have at the end of each month for the past year?", a standard report cannot answer that, because Salesforce does not retain the historical state of records. Reporting Snapshots (formerly called Analytic Snapshots) solve this by capturing report results on a schedule and storing them as records in a custom object. This allows administrators to build trend reports, track KPIs over time, and compare performance across periods. On the Salesforce Advanced Administrator exam, Reporting Snapshots fall under the Advanced Data and Analytics Management domain, and you should expect scenario-based questions that test whether you understand when to use them, how to configure them, and what their limitations are.

What Is a Reporting Snapshot?
A Reporting Snapshot is a feature that lets you schedule a report to run at a regular interval and save the results as records in a custom object. Each row of the source report becomes a record in the target object. Once the data is stored, you can build standard reports and dashboards on the custom object to analyze how values changed over time.

Key components:
• Source Report: A Tabular or Summary report that produces the data you want to capture. Matrix and Joined reports are not supported.
• Target Object: A custom object that you create to hold the snapshot data. It must have fields whose data types are compatible with the source report columns.
• Field Mapping: The configuration that tells Salesforce which source report column maps to which target object field.
• Running User: The user whose security settings determine what data is visible to the snapshot when it runs.
• Schedule: Defines when the snapshot executes (daily, weekly, or monthly) and the preferred start time.

How Reporting Snapshots Work

Step 1: Create the Source Report
Build a Tabular or Summary report containing the fields you want to capture. For a Summary report, you can map summary fields (such as Record Count, Sum, Average) from the grouping level. Best practice is to keep the report focused and include only the columns you need.

Step 2: Create the Target Custom Object
Create a custom object (for example, "Pipeline Snapshot") with custom fields to store the data. Field types must be compatible: for example, a Currency field in the report should map to a Currency field in the object, a Date to a Date, a Text to a Text, and a numeric summary to a Number field. Salesforce automatically populates certain system fields on the target object such as Created Date, which effectively acts as the snapshot date.

Step 3: Create the Reporting Snapshot
Navigate to Setup > Reporting Snapshots and click New. Provide a name, a unique name, and optionally a description. Select the Running User, the Source Report, and the Target Object.

Step 4: Map Fields
On the Field Mappings page, map each source report column to a field on the target object. For Summary reports, you choose the grouping level and map summary fields. Unmapped fields are simply not populated.

Step 5: Schedule the Snapshot
Set the frequency (Daily, Weekly, or Monthly), choose the days and the preferred start time, and set a start and end date. You can also specify email recipients to be notified when the snapshot runs. Note that the actual run time may vary depending on server load; the preferred start time is not guaranteed.

Step 6: Report on the Target Object
Once snapshots have accumulated, create reports and dashboards on the custom object. Group by Created Date to visualize trends (for example, a line chart showing total pipeline value by week).

Important Limits and Rules
• Maximum of 200 Reporting Snapshots per organization.
• A snapshot can insert a maximum of 2,000 rows per run. If the source report returns more rows, only the first 2,000 are stored, and the Run History will indicate the limit was exceeded.
• Source reports must be Tabular or Summary. Matrix and Joined reports are not allowed.
• Up to 100 fields can be mapped per snapshot.
• Field data types must be compatible between the source and target.
• The Running User must have the Run Reports permission and access to the source report folder. Data captured is based on the Running User's field-level security and sharing.
• The Running User does not need to be the admin; you can use an integration or designated user to ensure consistent visibility.
• If the Running User becomes inactive, the snapshot will fail. Email notifications and the Run History help identify failures.
• Snapshots run in the time zone of the Running User.
• The custom target object can be deleted or modified, but changing field types may break mappings.
• The Run History displays up to 200 runs and shows status, row counts, and errors.
• Reporting Snapshots are available in Enterprise, Performance, Unlimited, and Developer Editions.

Common Use Cases
• Tracking open Case volume by priority over time to analyze support workload.
• Capturing monthly pipeline by Stage for sales forecasting trends.
• Monitoring Lead conversion rates week over week.
• Recording the number of inactive users or overdue Tasks each day.
• Comparing year-over-year renewal values for subscription businesses.

Reporting Snapshots vs. Alternatives
• Historical Trend Reporting: Lets you compare field values at specific points in time for Opportunities and select custom objects, but it is limited to 3 months of history (or up to 5 fields and 8 selected dates). Reporting Snapshots can store data indefinitely.
• Field History Tracking: Tracks field-level changes on individual records (up to 20 fields per object, retained 18 months by default) but is not designed for aggregated trend reporting.
• Report Subscriptions: Send scheduled report results by email but do not store data for later analysis.
• CRM Analytics (Tableau CRM): Offers advanced trending and dataflows but requires additional licensing.
When a question asks for long-term historical trend analysis using standard reports and dashboards, Reporting Snapshots are almost always the correct answer.

Exam Tips: Answering Questions on Reporting Snapshots

Tip 1: Recognize the trigger phrases. Words like "trend over time," "compare month over month," "historical," "point in time," or "how many records existed at the end of each week" signal a Reporting Snapshot scenario. Standard reports only show current data, so these phrases should immediately point you toward snapshots.

Tip 2: Know the supported report formats cold. The exam frequently tests that only Tabular and Summary reports can be used as source reports. If an answer choice mentions a Matrix or Joined report as the source, it is wrong.

Tip 3: Memorize the numeric limits. 200 snapshots per org, 2,000 rows per run, 100 mapped fields, and 200 entries in Run History. If a scenario describes a report returning 5,000 rows and asks why only some records were captured, the answer is the 2,000-row limit. Solutions include filtering the report or using a Summary report with grouping to reduce rows.

Tip 4: Understand the role of the Running User. Questions may describe a snapshot capturing fewer records than expected. The likely cause is that the Running User lacks visibility to some records due to sharing rules or field-level security. Also remember that if the Running User is deactivated, the snapshot stops working. Selecting a user with broad access (or an admin) ensures complete data capture.

Tip 5: Field type compatibility is a classic distractor. If a scenario says a field cannot be mapped, the reason is almost always a data type mismatch between the report column and the target object field. Fix it by creating a compatible field on the custom object.

Tip 6: Know what goes in the target object. The target is always a custom object that you create; you cannot snapshot into a standard object. Each report row becomes one record. Trend reports are then built on this custom object, typically grouped by Created Date.

Tip 7: Distinguish snapshots from Historical Trend Reporting. If a question involves Opportunity field changes over the past few weeks with a quick setup and no custom object, Historical Trend Reporting may be the answer. If it involves long-term storage, any object, or aggregated counts, choose Reporting Snapshots.

Tip 8: Scheduling questions. Remember the frequency options are Daily, Weekly, and Monthly, with a preferred start time that is not guaranteed. Snapshots cannot run hourly. If a requirement states "every hour," a Reporting Snapshot is not the right tool.

Tip 9: Troubleshooting approach. When asked how to diagnose a snapshot problem, the correct first step is typically to review the Run History on the snapshot detail page, which shows success or failure, row counts, and error messages. Email notifications can also alert the admin to failures.

Tip 10: Eliminate answers that over-engineer. Exam distractors often suggest Apex triggers, scheduled Flows writing to custom objects, or purchasing CRM Analytics to capture historical counts. If a declarative Reporting Snapshot satisfies the requirement, it is the preferred best-practice answer for an Advanced Administrator.

Sample Scenario Walkthrough
A support manager wants a dashboard showing the number of open Cases by Priority at the end of each day for the past year. What should the administrator recommend?
Analysis: "End of each day" and "past year" indicate historical, point-in-time data. The admin should create a Summary report of open Cases grouped by Priority, create a custom object with fields for Priority and Record Count, create a Reporting Snapshot mapping the grouping-level summary fields, schedule it daily, and build a dashboard on the custom object grouped by Created Date. Answer choices involving Historical Trend Reporting (limited to 3 months) or a standard report (current data only) are incorrect.

Key Takeaways
• Reporting Snapshots store report results in a custom object on a schedule to enable trend analysis.
• Only Tabular and Summary source reports are supported.
• Limits: 200 snapshots, 2,000 rows per run, 100 mapped fields.
• The Running User's permissions control what data is captured.
• Field types must be compatible between source and target.
• Use Run History to troubleshoot, and schedule Daily, Weekly, or Monthly.
Mastering these points will prepare you to confidently handle any Reporting Snapshot question on the Salesforce Advanced Administrator exam.
Test mode:

Admin II - Reporting Snapshots Example Questions

Test your knowledge of Reporting Snapshots

Question 1

When a reporting snapshot runs, whose record access determines which source report rows are written into the target custom object?

Question 2

Ursa Major Solar's sales director wants a dashboard line chart that shows how total open pipeline for each opportunity stage changes week over week, starting now and continuing for the next two years. The current opportunity reports show only present-day values, so they cannot show trends. Which solution should the administrator recommend to meet this requirement?

Question 3

Cloud Kicks uses a reporting snapshot that loads a summary report of open opportunities into a custom object every Monday. The Opportunity org-wide default is Private. When the VP of Sales runs the source report herself, she sees much higher pipeline totals than the totals stored in the snapshot's target records. The source report has no restrictive filters. What should the administrator do to make the snapshot records match the VP's report?

More Reporting Snapshots questions
24 questions (total)