In the sprit of post about relationships, today let's talk about Report Types and Fast Food.
For those that are not familiar with what a report type is, it's a neat feature of Salesforce that lets someone with special powers join different objects in Salesforce. Let's say you can run reports with Account and Opportunity or Order and Order Products. But, it would be super cool if you could build a single report with fields from all of those objects. All of us hate joining reports, and there only seems to be one person who knows how to. This can help in those situations.
What is even more cooler (not a real word), is you can bring in fields from even more objects that are not a part of the ones in your new fancy report type using lookups.
So whats the problem? Sounds amazing right!
Take a small amount of time to come up with naming conventions and ownership. This area of Salesforce, if left unattended, can soon begin to cause a lot of drama.
1. You can name a custom report type ANYTHING, and this leads to a LOT OF CONFUSION. Just follow the Salesforce method that is used for everything else - X With Y With Y. Go back and update your report types using this convention. A few minutes will save you countless calls and meetings.
2. EXPLAIN the word WITH to everyone. This is critical!. When you are at the drive thru and you order your favorite burger with pickles. It comes with pickles. It does not come with a compliment of optional sides in case you forgot to order them. If you did not ask for it, it will not be placed on your burger.
With means that there is a relationship between the two objects, a special bond. Meaning, a row in your report will only show up when there are records from each object. Example: you have 546,988 Accounts and 345,678 Opportunities. When you run a report of Accounts and Opportunities with fields from both, you can not exceed 345,678 results. Salesforce does not allow blank results when your Account has no Opportunity.
3. What if you want blank rows? Well, again, this is where Custom Report Types can help. You can indicate With or With Out when you build it. But, remember to make that clear in your naming. These names show up to your users. Use W/O and ensure the description explains the difference.
4. Include the abbreviation (CRT) in the label name. This helps everyone know they are using a Custom Report Type. So, when complaints come in about point 5, missing fields, you know how to find which report type.
5. Assign someone the duty of ensuring fields are maintained on your Custom Report Types. You could even add it your deployment checklist, should you have one. There is nothing more frustrating than hours and hours of troubleshooting security/profile settings. To then realize the field was never added to the CRT. New fields do not get added automatically.
Start with this simple tips and you will be well on your way to avoiding potential adoption issues around reporting and data.