Don’t Work So Hard This Summer Making Salesforce Reports Work for You

It’s almost summer break, so if you’re like me, this is not the time of year when you have the energy to read a long list of advanced reporting techniques. You’re just looking for a few tips that will keep your users’ Salesforce reports reporting all summer long while you head out of the office a bit early to sit by the pool. (You can dream, right?)

Without further ado, here they are – just 3 simple tips to make reporting easier.

Tip #1: Encourage your end-users to use List Views instead

During Discovery Assessments with new Salesforce clients, we Cloud for Good consultants often hear end-users say “I need a report for that!” when they really mean more simply that they need to be able to find records within certain criteria. A key difference between reports and list views is that a list view can only pull data from a single object (e.g., Accounts, Contacts) – but it can still be filtered to a subset of that Object. Importantly, it is easier to create than a report, and it is much more actionable than a report. Specifically, you can edit records in your list view right from the list view – even en masse. If you were looking at a report of the same data, you’d have to click over to each individual record to edit it. Also, the Kanban view of your list view lets you update a record’s status or category by simply dragging and dropping. So, when your end-user tells you that they need a report, find out what they are going to do with the resulting data. If the data is from a single object, and they’ll be using the pulled data for something actionable (such as a Call List), encourage them to create their own list view and use inline editing.

Click the pencil icon in the top right corner of your list view to use inline editing. Note that you must filter the list by a record type in order to use this feature.

Tip #2: Don’t create a new report; change the filter on an old one

There’s usually a few departments at any organization that want the same data (i.e., “I want to see all my donations and their payments…”) filtered a bunch of ways (e.g., “…this quarter…” “…last month…” “…only for donors in New York…”). For this example, instead of creating two (or more) reports that display the same exact set of fields from the Opportunities and Payments objects, create one report with filter values equal to null. Then, when you run the report, you can dynamically filter your report to reuse this same one over and over again.

I built my report with a standard filter of Mailing State = NULL and Close Date = NULL, since those are the fields that the end-users wanted to filter on (to find donations last year or from New York, for example).

When my end-users view the report, they can adjust the filters as they wish to see specific data, such as Mailing State != NULL and Close Date = LAST MONTH. If somebody wanted to, they could export these specific results or even save the report as a new report. They could also simply get the high-level information that they need, and then exit, and next time they view the report, use different filters.

Tip #3: Keep your custom report types clean

Okay, you may want to tell me that this one isn’t effortless for the system administrator, and I suppose it’s not, but I bet it will make life easier for you and your end-users later on. So, grab a refreshing summery lemonade and get to work on Tip #3.

You may already know that you need to create a custom report type in order to report on an object or combination of objects that doesn’t have a standard report type. This will enable you and your end-users to create reports on the data in those objects. It is easy enough to go to Setup and create a custom report type, name it whatever, and simply shove all of the fields from your selected object(s) into it. But then when your end-users go to create a report from it, they may not be able to find the report type or the fields that they actually need in their report.

Thus, the recommendation here is to make sure that you’re using clear and consistent naming conventions for your custom report types (and that you actually include a description). You may want to include “CRT” or the acronym for your organization in the name of the custom report types, so that end-users can search for that. Also, make sure to only include the fields that end-users really need in your custom report type; if a standard field isn’t included on your page layouts and you never use it, it doesn’t need to be on the report type. Finally, you can leverage the custom report type lookup tool to bring in fields from related objects which are relevant to your end-users.

Give your custom report type a clear name and a helpful description.

Click the “Edit Layout” button on the custom report type configuration screen to see the lists of fields available for each of your included objects. Drag and drop fields between the selected fields sections and the available fields sections to include and exclude fields that you do or don’t need.

Click the “add fields related via lookup” link to select fields from any object related to your custom report type’s object. For example, I could add my Opportunity’s Primary Contact’s Email Address and Phone Number.