Also called Report Charts, Embedded Analytics gives Salesforce Administrators the ability to publish a filtered Dashboard component directly on the page layout so users can see key metrics for that record without navigating to a Dashboard. Embedding certain types of metrics are more effective than others and in today’s post I am going to focus less on the How To of implementing Embedded Analytics and much more on the What To.
If you are interested in learning how to implement Embedded Analytics Salesforce Help and Training provides an excellent guide:
What we need here is a Framework! I present to you: The Embedded Analytic Decision Diagram!
Venn Diagram anyone?
At the intersection of Actionable, Measurable, and Relatable we find our ideal candidates for embedded analytics. I’ll explain each in due time. Using this framework can help you identify what is going to be most effective to display. There’s a limit of 2 report charts per page so you want to make sure that you are displaying the most effective information you can with the limited space you have.
Let’s get this one out of the way quickly. If you can’t report on it in Salesforce then you can’t embedded it as a Dashboard component on the page layout. Your metric needs to be something that can be measured. This is the concern of the Salesforce Admin because there may be relational database changes needed in order to create the reporting needed.
Let’s take the example of an Apartment Complex. Apartments have Residences (Accounts or Person Accounts) and they consume Resources (Apartments, Garages, Parking Spaces, Electricity, Water, etc.). A measurable metric might be water consumption by Resident displayed over several months. In order to report on this within Salesforce water consumption records must be related to the Resident through a Lookup or Master-Detail relationship.
Take stock in your audience of the the component you are considering. Can Jane Sales Rep understand the data presented in this component? Can Joe Support Agent use this data to better serve the customer? Does the component .ell a story?
These are some simple questions to ask but they each dive into what the data behind the component is trying to tell you. I like to refer to this as the story behind the data. If you have data for data’s sake then its not useful. The narrative the data tells you is much more useful. What’s even more useful is if that narrative matters to the person viewing it.
Opportunities in Pipeline might not be directly impactful to a Support Agents duties but certainly might be useful for a Sales Rep. However, Number of Escalated Cases in the last 3 month may tell a much better narrative to both the Support Agent and the Sales Rep, something they both can relate to. Understanding the narrative behind your data will help to determine a relatable component.
Much like data that doesn’t tell a story, if your users can’t do anything with it the data you give them the data is useless. When considering embedding analytics into a page layout we need to consider what actions our users might be able to take based on the data they are presented.
Let’s take our Water Consumption report example from above. Water Consumption is related to the Resident and measuring it over several months certainly can tell a story. But who cares if your users can’t do anything with it. Let’s say we are displaying this data in a component to a leasing agent who is working with a resident to sign a new lease. The leasing agent sees the component and notices a spike in water consumption in the last three months. She discusses quickly with the resident the possible reasons for this and finds out that the kitchen faucet has been leaking. The leasing agent can then easily dispatch maintenance to fix the issue, improving customer loyalty and satisfaction.
When implementing a component on the page layout, embedded with field level data, we need to consider what actions might be taken from a quick analysis of the data itself. If the data won’t result in your users taking action then its not going to be effective.