Having implemented several instances of Salesforce in a variety of industries, two of the most used yet most ambiguous features are Reports & Dashboards. To start off, many folks who are defining business processes along with their Salesforce buildout might not yet have a definitive idea of what specific information or format they need until after they start to use the system for a while. On the flip side, some organizations may have well-defined reporting needs but cannot effectively put them into place at least until data is migrated. Thinking about it logically, Reports & Dashboards are outputs, and outputs are only going to be useful once the inputs have been addressed.

On top of the fact that reporting needs are typically handled toward the end of an implementation of Salesforce features, there is often another debate unique from most other tools within the platform. Salesforce has made reporting so user-friendly and accessible that really anyone CAN learn it, but each organization might have a different definition of who SHOULD be building them. Perhaps opening most capabilities to end users is the appropriate solution, or perhaps a central data or admin team will be responsible for maintaining your reporting suite. Or potentially reporting requests will be outsourced to a Salesforce consultant that can help with best practices and industry standards.

As you can see, even though reporting might seem straightforward on the surface, there are several things to consider before the official build. Another common question to answer is, “Will we need to report on changes over time for certain attributes?” Enter Reporting Snapshots, which give you the ability to track things like period-over-period deltas in the information that matters to you most.

What comprises a Reporting Snapshot?

To get started with building a Reporting Snapshot, there will always be 3 main ingredients: a source report, a target object, and Target object fields.

• Three main ingredients to start a Reporting Snapshot:
• A source report
• A target object
• Target object fields

For example, if you wanted to create a Reporting Snapshot that gave you a picture of the number of prospects actively onboarding from month to month, you could create a simple report – Prospects Currently Onboarding – which would give you a list of Contacts in the Onboarding status today. To store the data at each interval, we need to create a custom object called “Onboardings”. Finally, on the Onboardings object we would need fields to store the number of Contacts in the Prospects Currently Onboarding report and the current date each time the snapshot is taken.

Defining & Mapping the Reporting Snapshot

After you have taken care of the initial steps, you are ready to configure the snapshot itself. The first part is self-explanatory – you will need to define a name, a running user (which should have access to all the object(s) and field(s) needed for the source and target), and the source report/target object you already created.

The following screen, however, is where it gets a little bit tricky. You will need to define a field mapping for the reporting snapshot that tells us which report fields should get stored in which object at each interval. For our simple example, that would mean two fields should be set up here – both the record count and the run date. For more complex situations, this screen is important in laying the foundation for what will ultimately be consumed.

‍

Scheduling your Reporting Snapshot

The final action you need to take for your Reporting Snapshot to function properly is to create a schedule. This is another straightforward step, but it is critical that those providing requirements understand the implications about being indecisive with the schedule. For certain types of snapshots, should you decide to change the frequency at any point in the future, you may no longer be comparing apples with apples regarding the historic snapshot data you will have gathered to date. Perform the due diligence and put the appropriate amount of thought into how often you want to generate the data (with storage considerations at play as well).

‍

Digesting the Output

To make use of the data that Salesforce will now be creating for you over time, you will need to create another report in addition to the original one that was used as the source of information. This report can then be grouped by the date of the snapshot, and a chart added to display a visual trend of the change over time in prospects actively onboarding similar to below.

‍

Important Considerations

In addition to formulating a general reporting strategy, there are specific technical nuances to look out for when configuring reporting snapshots that may serve as roadblocks in achieving the strategic goals of your organization.

As previously mentioned, pay close attention to the permissions of the Reporting Snapshot’s running user. In addition to requiring access to the object(s) and field(s) in question, they must be able to run reports and have access to the specific report serving as the data source. The running user also cannot be inactive.

Additionally, if you were hoping to build automation triggering off the creation of a record in the target object by the snapshot functionality, unfortunately this is not functionality that is supported. No workflows, processes, triggers, or even validation rules can be built on the target object. The idea is that the snapshot functionality itself is constructed so specifically and that no user is manually creating a snapshot record, so there is no need to build additional controls beyond configuring the snapshot itself.

In Conclusion

Salesforce’s reporting and dashboarding tools are some of the most powerful and intuitive available in the market today, but because of its open-endedness, due diligence, sound architecture, and thoughtful policy are of utmost importance. Reporting snapshots are one of the more advanced features made generally available and setting them up can vary greatly in degree of difficulty. Once you have built a solid foundation of inputs, however, you can “set it and forget it” and let Salesforce do the heavy lifting for you over time!

If you have additional questions about generating Reporting Snapshots in your Salesforce org, or general questions about other Salesforce topics, please do not hesitate to reach out!

‍