Most organizations with CRM will eventually want to have some kind of dashboards to help their employees focus on the KPIs and CRM lists that are important to them. Creating the dashboards themselves is outside the scope of this article, but there are a variety of ways to build them, from the popular SharePoint dashboards with PerformancePoint analytics, to custom webpages with embedded gauges and reports.
But once you build a dashboard for one set of users, others are sure to follow. Usually it’s the sales managers who first push to have dashboards so they can monitor their team’s pipeline and close ratio. But then the salespeople themselves will want a custom dashboard, and then the service folks, and soon after that, every group of users and department in your organization is pushing for a dashboard.
So how do you keep from cluttering up your sitemap navigation with 15 links to dashboards that are irrelevant to the majority of your users? Here’s one approach: use a combination of security roles and custom entities to display dashboard links to the right group of users. Follow the steps below:
1) Build your dashboards. In this example, we’ll pretend we have a dashboard for sales managers, and a separate one for salespeople. The sales managers don’t actually sell anything, so they don’t want to see info about their specific pipeline and alerts about the accounts they own. And the salespeople shouldn’t be distracted by looking at the aggregrate numbers and new opportunities from across the organization. So we’ve built different dashboards for each of them. (This example has screenshots from CRM 3.0, but the same principles and techniques apply to CRM 4.0 as well).
The result should look like this:
3) Now add two custom entities. I’ve added one called SalesDash (schema name is “new_salesdash”) and one called SalesMgrDash (schema name is “new_salesmgrdash”). I’ve made them Organization-owned (rather than User-owned) and I’ve selected to not show them in any area of CRM. I’ve also made sure not to allow Activities or Note to be attached to them. These entities are only there so I can reference them in the security roles, I don’t want anyone actually using them.
4) Next, edit the Salesperson and Sales Manager security roles so they have Read privileges on the respective new custom entities you’ve just created. The Salesperson security role should be able to read instances of the SalesDash entity, but not have any privileges on the SalesMgrDash entity. The Sales Manager security role can read the SalesMgrDash entity, but not the SalesDash entity.
5) Lastly, go back to your Sitemap XML and set privileges on the dashboard links to display them only to users whose security roles grant them read access to the appropriate entity:
Now your dashboards will only show up in the Sitemap for the right individuals, and your sitemap won’t look cluttered with a bunch of irrelevant links for all the wonderful dashboards you’ll be creating!