Salesforce.com’s Flexible Architecture & How It Impacts Reporting
You’ve most likely chosen Salesforce to run some (or all) of your business operations because you need something flexible and scalable. You saw the demo of the robust reports and dashboards, and assume that you’ll be able to get all of the data in the reports that you are now using Excel to produce. To your surprise, you try to build a report that shows some basic data stored in custom objects and find that you cannot connect them. So now you still have to export that data into a spreadsheet and make pivot tables.
The question we hear from clients time after time is, “How can an application as excellent as Salesforce not be able to produce these simple reports?” Salesforce.com is a metadata-driven application. You might think that architecture shouldn’t have a big impact on your options, but it does.
The Salesforce Metadata Architecture – How It Impacts Analytics
A major strength of the Salesforce platform is arguably one of its greatest weaknesses when it comes to analytics. Salesforce’s metadata architecture can be used to model just about any business. The problem with metadata-driven systems is that the flexible architecture results in limited reporting functionality. The ability to connect custom objects to any other objects means that the reporting engine can’t logically piece all of those objects together in a consistent way. A strong analytics solution requires a stable data structure with consistent relationships, hierarchies, and calculations. So the flexibility of Salesforce’s metadata has a huge impact on any reporting engine that expects consistency.
With this understanding, there should be two basic steps behind every Salesforce implementation.
- TAKE THE TIME TO THINK ABOUT HOW YOU WILL REPORT ON THE DATA IN YOUR OBJECTS - It is a common problem that reporting is only considered after Salesforce deployments are complete. You are doing your investment a disservice if you do not take the time to plan your configuration to maximize reporting functionality.
- DESIGN YOUR CUSTOM FIELDS AND OBJECTS TO SUPPORT REPORTING REQUIREMENTS – Create new objects, extend existing ones, and define the relationships between those objects with reporting in mind. This will prevent you from having to do too many data backflips to get the reporting you need. Remember that there is always a balance between good data architecture and one that is too complex to support reporting. We always encourage data normalization, but there are tradeoffs when it comes to reporting.
What You Don’t Capture, You Don’t Know
The data tells the story and that means it didn’t happen if it’s not in the system. Once you’ve configured the system to capture your organizational data, you must remember that insights are limited by the data entered. Your setup has to be usable in the real world by real people who are very busy. Make sure you can collect the data you need to support business decisions, but don’t overwhelm your users with too many required fields that will make them not want to use the system at all.
Readjust From What You Have Learned
As you customize, extend, and improve upon your Salesforce implementation, you should evaluate the information that is being captured and how that is supporting the metrics necessary to run your business. Are there data points you are missing?
After you’ve gotten to a steady Salesforce configuration, you will need a solid plan for sharing and learning from all of the information you’re collecting. This is where the “analytics” component comes in. In our next blog, we will take a look at practical recommendations for driving meaningful insights and actionable intelligence from your dashboard and reporting setup.