Reporting Snapshots are pretty high on my list of all-time favorite features in Salesforce. They allow me to capture records at a particular moment in time, repeatedly, for super-accurate trend reporting. They are similar to the Historical Trending feature, but with less limitations.

Creating a Reporting Snapshot is easy – so easy, in fact, that I’m not writing about that today! If you’ve never created a Reporting Snapshot, these instructions will walk you through the following steps:

• Creating a Source Report
• Creating a Target Object and custom fields
• Creating a Reporting Snapshot
• Mapping fields from the Source Report to the Target Object
• Scheduling the Reporting Snapshot

As with most things in the Salesforce universe, there are lessons that can only be learned through experience – or avoided, if someone warns us! So here are my warnings to you… the what-not-to-do’s of Reporting Snapshots.

Pitfall #1: The over-filtered source report

The source report should include all records that need to be captured in the snapshot. I’ve seen a lot of emphasis placed on how often a snapshot is taken – but what I find far more important is, which records are included in the snapshot? The more records you include, the more ways you can slice and dice the historical data however you like. But if you place too many restrictions on the initial data capture, you cannot go back and retrieve it.

Here is an example of an over-filtered source report:

Sure, maybe this was fine when the snapshot request first came to me… but what happens when someone comes back and says that they also want to see closed won and/or lost opportunities in the snapshot, or deals that are further out than the current quarter? I highly recommend not filtering by opportunity stage, case status, etc., and using a date range such as “Current and Next 3 FQ” or “Current and Next FY.” Pull as much data as you can into the source report, because you can filter things out when you run snapshot reports or list views – much like cropping a photo – but you cannot add things that were not there to begin with.

Pitfall #2: Not enough fields

You can create up to 100 fields on the source object for your reporting snapshot. One hundred fields! So… do I even need to say what is wrong with this picture of my field mappings?

What if, at some point, we wanted to sort our opportunity snapshots by Lead Source? Or by some other field that I never added or mapped? It’s all fine and good to add fields later, but that data won’t exist in your historical records. Save yourself the headache now – talk to your users who will be reporting on the snapshots, and make sure to include every field that has even a slight chance of being used in future reporting.

Note: Lookup fields cannot be pulled into the source object for a reporting snapshot. If you want something like Record Type included in your snapshot, you will need to create a formula field on the original object (in my example, the opportunity) that displays the ID of the record referenced in the lookup. Then create a text field in your target object, and map the record type ID to that field.

Pitfall #3: No way to compare record IDs

At some point, you may want to compare snapshot records with actual records. Or you may have a snapshot report that you compare against an opportunity (or other object) report, but some records are missing from one of the reports.

Note: If you find discrepancies, or you suspect that the snapshot is not capturing all data, go directly to the snapshot and scroll down to Run History – this will show you if there were any failures during the scheduled snapshot.

Do yourself a favor, and add the 18-character record ID to your reporting snapshot. It will enable you to pull snapshot records and records from your source object, and compare them in Excel with a V-lookup to quickly locate discrepancies.

If you have not created an 18-character record ID before, here are instructions for adding it to any object. You will then want to:

• Add it to the object in your source report, and add it as a column in the report.
• Add it to your target object as a text field.
• Go to the reporting snapshot, and map it in your field mappings.

Whether you are creating your first Reporting Snapshot or managing existing snapshots, these best practices will save you some trouble down the road as different people in your organization find different ways to look at the data you are capturing in those snapshots. Implement them now, not later. Happy reporting!