Working Around Salesforce Limitations with Reporting Snapshots

This post was written by Principle Salesforce Administrator Ben Musson. It was last updated on 01/05/2024.

Reporting snapshots are a powerful tool in Salesforce for aggregating and analyzing historical trends in your data, whether that’s your lead or opportunity pipeline size, case resolution history, or some custom object of your own making.

Unfortunately, the out-of-the-box functionality for reporting snapshots does come with some significant limitations. The full list is available here, but some things that can ruin your day include:

1. Scope – A reporting snapshot will only capture a maximum of 2000 rows of your source report. If your report is returning more rows than that, the rest will get left behind.
2. Size – Your source report can only contain up to 100 fields from the object(s) you’re pulling from.
3. Automation – The target object for your reporting snapshot (where your historical data is stored) cannot be the subject of ANY workflow that runs on creation. This means no workflow rules, no process builders, no flows, and no Apex triggers that run on insert.

Fortunately, it is possible to work around these issues. One of Kicksaw's Solution Architects was able to determine that if you need to perform any sort of update on your snapshot records, you are able to automate that using a scheduled flow. Simply create a reporting snapshot using the standard functionality, making note of the time you have set it to run, then set a scheduled flow to run some time after those records are created. It’s easiest to set that to run the same day, but you should allow for at least an hour between the snapshot run time and the flow run time. This is because snapshots run asynchronously, so the exact start time can vary depending on the available system resources at the scheduled time.

If for some reason you need to operate outside the size or scope limits, which can often be the case with larger organizations, the solution is more complex, but lies in remembering that a reporting snapshot is essentially doing three simple things:

1. Running a SOQL query to gather the data in your source object
2. Mapping the fields in that data to the fields in your target object
3. Creating a record of your target object for each row of the SOQL query

What functionality do we know of that can also handle those tasks at large scale? Apex! Using a Schedulable class and a Batchable class, it is possible to create a custom scheduled snapshot of your data in an asynchronous, resource-efficient, and less restrictive environment. This solution does also resolve the restrictions on automation for the target object, but it’s quite a significant lift if that’s the only limit troubling you.

Remember best practices and design patterns when writing the code, of course. Make sure to keep those DML statements outside of your loops, or you’ll hit an entirely different set of limits!

Salesforce’s native reporting snapshot functionality is a great way to keep an eye on your data trends over time. The limitations placed on it are there for your protection so that you don’t accidentally cause a snapshot run to fail by trying to do too much at once. Keep this in mind with your workarounds, and remember to test, test, and test again to make sure you don’t discover in a month that your snapshots have been failing.

Hopefully this article helps you wrap your head around how best to work with reporting snapshots. If you need a custom solution to help manage your reporting snapshots, though, or with any other reporting challenges you have with your business, simply reach out via the Contact Us form below, and we'll put you in touch with one of the pros at Kicksaw. We love helping companies streamline their processes!