Tales from the Socials: Mass custom reports

Overview

The poster reports that they have heard that having large numbers of reports will result in report results which are incorrect. The assertion is a little confusing, as reports should be read-only in their relationship to the data in your org, so my immediate assumption was that he/she means that the data appears incorrect and thusly can’t be relied up for making business decisions.

What’s the Deal?

This problem happens, and apparently it happens frequently enough to warrant its own support article:

https://help.salesforce.com/articleView?id=000324873

There are a number of ways that this can happen (as Salesforce points out), but the one I want to focus on is: Proper Report Type Selection. This is kind of a multi-pronged issue. In some organizations (like mine), you may have a separate team in charge of generating reports, or the business may ask you to give access to build their own reports, and even create their own report types… This can be helpful in removing that responsibility from you admins, as well as putting someone in charge of drafting your reports, who is more familiar with the business need… but you know what they say about having too many cooks in the kitchen…

Problem 1: Repetitively Redundant Report Types

Sometimes team members will need a report and they need it fast, so they crank open Salesforce, and they know enough about the development lifecycle to know that a new report type is required, but they’re in such a rush that they forget to make sure it’s not already there:

Oops… Unfortunately, now that I know there are 3 of these, I’m questioning whether or not I know which one I should actually be using. Now fortunately, the authors have described the types of relationships present in those reports (though, I can tell you the first one doesn’t actually describe the delivery object’s relationships properly). Unfortunately as well, the descriptions don’t actually describe the intent or functions of the reports. With names and descriptions like these, you don’t know what kinds of lookup relationships might be present in those reports! Perhaps that’s why we have 3 reports that are all pretty similar?

Problem 2: Those Redundant Report Types Weren’t Redundant…

When we start looking at these 3 reports, we find out that two of them are similar, but one is very different (but notice they’re all in different report type categories):

Ok, not too bad. We might be able to consolidate two of these. The 1st one looks a little suspicious though… Let’s take a closer look at the layout for that one:

548 fields in this Layout with 1 object type… Concerning, but let’s keep going…

Ok, we’re not even half-way down the list and there are some very real problems here… Part of this is a Salesforce problem, where we’re showing only a fraction of the characters that are available in the space given here. So while we see 3 Credit Team… entries, we don’t know for sure that there’s a big problem yet.

But you should also notice that there are no page layout sections… So your drop-down selection in the report is just one long list, and in the event that there is a field on your delivery object that has the same name as the one on your opportunity object (think Created Date), then there’s going to be a problem…

Now fortunately, our friends at Salesforce thought of this problem and they help us out a little by telling us what field drives the relationship for the field we’re looking at when selecting a field:

Since all of these fields run together, while technically we’re providing enough context for a user to select the right fields, we’re not allowing Salesforce to help our users, nor using the grouping functionalities in the report editor to really help us out.

Problem 3: Admins Have Bad Hygiene

But there was something else. There are two status fields on the Delivery object… When I create a report with these, I soon discover that these fields are not equivalent…

So if someone is relying on these fields do find out the delivery status, there’s a very real possibility that they select the wrong one. To make matters worse, there is a Delivered status under both.

So What Do We Do?

There are 4 things we can do to work through these problems:

Audit and Reconcile Existing Report Types

You probably don’t need a report type for Deliveries with Opportunities and Opportunities with Deliveries if you’ve set up your reports properly. Nor do you need Opportunities with Deliveries when you already have Opportunities with Deliveries with Activities, as adding Activities is just additional content layered onto the Deliveries with Opportunities report type.

(Note: Deliveries with or without Opportunities is a different type; though you can always use filters in your report to get an equivalent result)

Name and Describe Reports Properly

I recommend naming your report types in terms of the objects that are accessible, and the relationships. Something important to note: Don’t just go with Deliveries with Opportunities with User when you’re looking up to a (for example) Delivery Driver. Something like Deliveries with Opportunities with Delivery Driver is much more helpful to someone choosing a report type.

Continuing down, be sure to describe the goals or intents for the report type, and if you have a ticketing system or a data catalog, that information could be immensely helpful for you, your team, and your users.

Re-Train Reporting Team

If you are seeing a number of repetitive report types, or your reporting users aren’t following quality standards, host a re-training session and put together documentation with quality standards. You can always revisit this in the future, and it will help them deliver on user-requests and ensure there are no doubts about the integrity of the data in your reports.

Audit Objects for Fields With Identical Names and Rename Them

Things happen, and sometimes team members are exhausted or are trying desperately to hit a deadline and forget to evaluate whether the work they’re doing might be redundant, or that they might inadvertently convey information to users in a way that might give them the wrong ideas. In the case of this status field, one status field represents the generalized vehicle delivery status (for example, Delivered; Not Delivered). The other status field provides specific delivery details based on the type of delivery, hence the mismatch in values. At hub for picked up vehicles actually qualifies as a delivered vehicle, but someone who isn’t on the Logistics team might not know that. If they select the wrong status field, they might get the wrong idea. There are two ways to combat that:

  • Simplify the field – Consider in this case a boolean field titled something like “Delivered”. It’s a very obvious search for a user, and answers their question as simply as possible.
  • Consider names like “Short Status” and “Detailed Status” which helps convey to the user that they may want to look at other fields to get their data, and helps separate out the two fields so they don’t assume they’re the same.