A while back, we looked at how one can access Salesforce data using the associated APIs provided by the platform. In my opinion, this is a great strength of the Salesforce platform – whenever you create a new object (table) in Salesforce, you get a set of REST API endpoints along with it for free without having to lift a finger. You can create, read, update, delete records programmatically. Having API level access to your datastore opens many possibilities. For instance, this allows you to feed records from an external system, perhaps a legacy database that you are still heavily reliant on. Or you may want to do the reverse: when a new record is created in your Salesforce org, or when a record is updated, you may want an external system to reach in and grab that information for some other external processes that you may have going on. But what if you have a set of reports in Salesforce that you and your team has created, slicing and dicing the data in every which way, providing you a manicured set of derived values? What if you need access to this externally? You don’t have to recreate those calculations outside of Salesforce but instead use the Reports & Dashboards REST API to get the report data directly and then operate on those derived values.
Real-Life Use-Case
I was recently in a situation where I was brought into the tail end of a project to help with extracting some data out of a Salesforce org to be packaged and shipped elsewhere. It turned out that the data model was largely built by a third-party consultancy that was no longer on the project. Well, as you often find in many software development endeavors that you inherit, the data that I needed to get at was stored in a convoluted mess of objects with zero documentation. After spending a day trying to untangle this data storage mess, my colleague suggested an alternate approach –
“Why don’t you just use the report that the third-party consultants built, as is?”
He was right. The data that I was after was all there in a single report, neatly pressed and packaged. I didn’t have to look at or try to understand all the web of complexities that lay underneath this pretty façade.
How do I do this?
Getting report data out is very similar to getting object data out… the API endpoint changes and the return data structure changes but the mechanics are all the same. If you need to revisit that topic, you can check out my entry: Connect to a Salesforce APEX REST API from a C# Console Application (and related posts). As for Reports & Dashboards API, the endpoint URL will look something like:
https://[instance-name]/services/data/[api-version]/analytics/reports/[report-id]You can find the Report ID from the UI by inspecting the URL:
Parting Thoughts
The Salesforce Reports & Dashboards API goes much beyond than simple data access. You can create new reports, modify existing reports, retrieve all sorts of metadata about reports, download report data as Excel files, do on-demand filtering and much more. But also keep in mind that there are limitations that you may run into. There are limits on how many records the API will return, how many synchronous runs it will support and so on. In most cases, you can work around these limitations by perhaps putting in delays between runs, by tacking on additional filters, cross-joining your reports to a helper object in which you’ll insert records, one for each report row that you’ve “looked at” (processed) so that you can retrieve additional rows. Check out the documentation. It’s good documentation, with a lot of examples.