Salesforce reports, dashboards, and analytics
There is no “dynamic” option available in the report builder that allows a report to use the currency specified for the running user. Until this is supported natively, you can follow one of these methods in order to edit the metadata of your report so that it displays the currency of the running user. This makes it possible to manage a single set of reports in multi-currency enabled orgs.
A report request comes in asking for a calculation showing the average number of records created in a week. The time frame for this report could be set to a few different values – like last year, last quarter, or over the course of the previous two years. Ideally, the calculation would be dynamic and count the number of weeks that are present in the report results so that these time frame adjustments can be made on the fly. Using a formula field on the object and a summary formula field within a report, you can dynamically count the number of date groups shown in the report results at run time. Let’s dive into the specifics on both pieces of this solution so you can implement it in your org for your use case.
If you’ve ever tried to create reports on the activities that your users are meticulously entering, you may have run into some perplexing behavior. We have a handful of strategies you can utilize in order to bring some normalcy to the activity object in reports. You’ll even be able to create an “Activities (Deluxe)” report type by the end of this article.
In the final post of this series, we’ll discuss some advanced considerations that I’ve been compiling over the years. These are suggestions you may want to implement right away or tuck away in your toolbox if you haven’t encountered these scenarios.
While it may take some time to clean up existing reports, you can start enjoying the benefits of deluxe report types right away. Only create new reports with deluxe report types (or other styles with a better understanding of how object relationships work).
At the heart of every report is one of the following seven query scenarios. Recognizing the query scenario when you first hear the report request will allow you to identify the best report type configuration for the job.
Imagine if you had a single custom report type per object that could address a majority of the requests you have to create a report using data from that object. This is similar to the concept of “one process builder per object” or “one trigger per object” – you create one custom report type per object that you want to report on.
When working with reports in Salesforce, you will find that report types have a major effect on what you are able to manipulate. Report types control what report results have the potential to show, what objects you have access to, what fields are available, and how certain report features will behave. This is the first filter being applied to the data.
The report engine in Salesforce relies on the relationships that are explicitly defined in order to join together data from multiple objects. This means your data architecture determines what native Salesforce reports will be capable of producing. Here are four concepts to consider for data modelling that will allow you to build the reports you desire.
ReportForce 