Dynamics CRM 2011 Charts and Dashboards: Who can see what?

Microsoft Dynamics CRM 2011 includes excellent charting (or visualization) features. It also introduces dashboards, which can be used to present several charts together, along with a few other things such as data grids, web pages, and Silverlight forms. Dashboards are obviously highly visual, and they are very front-and-center in the user experience. For example, the default settings in an un-customized Dynamics CRM 2011 organization will make the “Microsoft Dynamics CRM Overview” dashboard the first thing a user sees when accessing CRM through the web application:

Now there’s nothing wrong with that, and judging by how many times I was told by CRM 4.0 customers, “we need dashboards!”, the default settings – that all users can view and create charts and dashboards — will likely be fine for most organizations. However…they won’t be for all organizations, and recently I’ve had a few questions along these lines: “how can we configure it so some of our users can see the dashboards we want them to see, but not waste a lot of time creating charts and dashboards of their own”?

Background: System Charts and Dashboards v. Personal Charts and Dashboards

So…who can see Dynamics CRM 2011 charts and dashboards, and who can create them? These kinds of things are determined by the security roles assigned to a user, and in order to configure security roles for charts and dashboards, you need to understand the distinction between System charts and dashboards, and Personal charts and dashboards. The following table (valid for the default security roles) compares these along several different dimensions:

 

Security Privileges System Charts and Dashboards Personal Charts and Dashboards
Who can create them? Users assigned to System Administrator or System Customizer security roles All users
Who can see them?  All users  Only the user who creates them 
Which entity controls security privileges? 
  • System Chart for charts
  • System Form for dashboards
  • User Chart
  • User Dashboard

 

Let’s start with System charts and dashboards. As indicated in the table, most users cannot create these. These are considered system customizations, and once created they are by default visible to all users. So…it’s probably a good thing most users cannot create these things! The most obvious examples of these are the default dashboards you see in the Workplace, and charts like the Sales Pipeline chart exposed on those dashboards, as in the figure shown above.

Now on to Personal charts and dashboards. Notice in the previous figure the New button on the ribbon. If you click that you will be creating a Personal dashboard. It can be confusing at first keeping track of whether you’re creating a personal thing (chart or dashboard) or a system thing, so here’s my rule for how to remember the difference: if you click a New button on one of the application ribbons in Dynamics CRM 2011, the thing you’re creating is personal. You have to work harder to create a system thing, and again, since everybody will see it, that’s a good thing. The following two figures show, respectively, the default Dashboards ribbon every user sees when working with dashboards, and the default Chart tab for the opportunity data grid.

On the Dashboards ribbon, any user can click New to create a new personal dashboard.

On the Charts tab for most data grids, any user can click New Chart to create a new personal chart.

From a security standpoint, personal charts and dashboards behave the same way personal views do: while every user can create one, by default the only user who can see one is the one who created it. This can be a little confusing at first. For example, we’re used to thinking that a user with the System Administrator role can “see everything”, but that’s not true: they can only see almost everything. In fact, if you examine the System Administrator security role you will see they only have User-level Read privileges on entities such as Saved View, User Chart and User Dashboard. So unless a user shares a personal chart, nobody else can see it, not even a system administrator.

Locking Down Personal Charts and Dashboards

OK, so now we know there are two different types of charts and dashboards. How do we modify security so our sales reps don’t waste time goofing around creating charts and dashboards?

Well, we know they can’t create system charts or dashboards, so we only have to prevent them from creating the personal (or user) variety. Since I’m picking on salespeople here, I’ll use the Salesperson security role in the example:

  1. Click Settings, and then click Administration.
  2. Click Security Roles.
  3. Select the Salesperson security role and double-click it to open the form.
  4. On the Core Records tab, remove the Create and Read privileges (the first two columns) for the User Chart and User Dashboard entities:

The following figure shows the tool tip you see when you hover over one of those empty red circles in the security role UI. If you try this, you’ll notice that the only access levels the Create and Read privileges can have for those two entities are None, and User.

So, after customizing the security role, suppose I sign in as a user with the following characteristics:

  • Only assigned one security role, the customized Salesperson role.
  • Not a member of any teams.

Here’s what I will see when I navigate to Opportunities:

The Charts tab is absent from the ribbon, just as it will be from anywhere else it would usually appear. Similarly, the Save and New buttons will be removed from the Dashboards tab:

Locking Down System Dashboards

Now, suppose you not only don’t want them wasting time creating personal charts or dashboards, but you don’t even want them looking at system dashboards or charts. Security privileges can be used to prevent users from seeing these as well. For this, you need to customize the System Chart and System Form entities on a security role’s Customization tab:

By default, only the System Administrator and System Customizer security roles have Create privileges for these, but all security roles have Read privileges. Continuing our example, suppose you lock down the Salesperson role even more, by removing the Read privilege for System Chart and System Form as shown in the previous figure.

Then if you sign in as a user with only that security role, here’s what you would see if you navigated to dashboards:

If you navigate to the opportunity data grid, you will see that the user experience degrades in a slightly better way – instead of seeing a Not Available sign, you just don’t see the chart pane at all:

Role-Targeted Charts and Dashboards

So that’s how you can prevent a user from seeing any (system) charts or dashboards. But suppose instead of a completely locked down experience, you were going for more of a targeted one: salespeople see the dashboards they need, customer service reps see only the dashboards they need, and so on. How would you do that? This article’s long enough already, so I leave you with that as a question. I’ll write up at least one solution to that problem in a future article, but in the meantime, if you’ve got one, feel free to let me know about it!

19 Comments »

  1. AdamV Said,

    July 16, 2011 @ 2:24 pm

    I haven’t really thought much about giving people only a subset of dashboards and charts as I don’t see a great deal of need for it – most users are happy not to waste time looking at things which are not useful or relevant to them.

    One approach could be to simply prevent them using system ones at all, then create user charts (for one user, possibly an administrator) and share them to a Team. Managing Team membership is then an easy way to make sure the right people have them, and you are likely to be managing teams anyway for other things like record ownership, queue visibility and so on.

    Anything involving sharing can be seen as being a bit kludgy, but it could be the simplest option here.

  2. Richard Knudson Said,

    July 16, 2011 @ 2:28 pm

    Hi Adam,

    Those are the lines I was thinking along…I guess I have to work harder to stump you! :-)

    I’ve seen clients do this a couple of times now, and both times they shared a personal chart to a team (or user — teams are better as you say). But then…they forgot that the chart was based on a personal view, and the view wasn’t shared, so the user still got a permissions error. Anyway, something to think about.

  3. Saurabh Gupta Said,

    July 19, 2011 @ 7:19 am

    How user dashboard can be converted into system dashboard?

  4. jobin Said,

    August 5, 2011 @ 5:46 am

    Thanks Richard for making it very clear. really useful!

    Kudos!!

    Jobin

  5. Richard Knudson Said,

    August 5, 2011 @ 6:51 am

    My pleasure, Jobin — glad you liked it and thanks for reading!

    Richard

  6. Oz Said,

    August 31, 2011 @ 2:06 am

    Really would like to know how to set up what you described in the summary – “But suppose instead of a completely locked down experience, you were going for more of a targeted one: salespeople see the dashboards they need, customer service reps see only the dashboards they need”

    Any chance of elaborating on that please?

  7. Sudhanshu Said,

    October 7, 2011 @ 12:06 am

    this is really awesome in details described…
    thanks buddy

  8. Anish Said,

    October 14, 2011 @ 12:15 am

    Hi Richard,

    As far as the system dashboards are concerned can we restrict individual system dashboards to be visible as per specific requirements? I tried the same for views via plugin and it worked. For e.g. There are 11 System Dashboards and I want ‘Sales Performance by Territory’ not to be visible on a specific condition, how do I achieve this?

    Thanks.

  9. Anil Said,

    October 26, 2011 @ 11:53 pm

    Thanks Richard for helpful articles in a detailed manner,

    here can you explain something about Personal Views also. Recently I got a requirement, personal views created by one user should be accessed by Administrator. How can I get it done..

  10. Ed Sandoval Said,

    October 31, 2011 @ 7:48 am

    Great Article, Richard.

    If you (or anyone else) could elaborate on a targetted approach to allow access to a subset of dashboards to a team/user, it’d be great

  11. Prashant Miraje Said,

    January 17, 2012 @ 5:08 am

    this is realy usefull article .

  12. Daniel Hodgin Said,

    March 8, 2012 @ 2:44 pm

    When I remove the system form permission from a security role it also includes accounts, contacts, etc. All system forms for system entities not just dashboards.

    Is this what everyone else experiences as well? I just want to restrict users to only see a single system dashboard i setup maybe or possibly none.

    Right now I’m modifying my sitemap to just remove dashboards all together until i have a better solution than removing the system form permission

    Great articles on your blog. I’ve learned so much. Thanks a lot.

  13. Richard Knudson Said,

    March 13, 2012 @ 6:31 am

    Hi Daniel,

    Yes, that’s the way it works. The system form permission is for ALL system forms, including dashboards. In my experience, the most important implication is that system dashboards are not the way to go … unless you want every user to see a particular dashboard. If I want only certain users to see a dashboard, what I usually do is create a personal dashboard and then share it. You can share it with a user or a team. (Just remember you also have to share out any personal views or charts the dashboard might be using). A bit of a hassle, but it’s better than everybody seeing every dashboard.

  14. Ali Hanif Said,

    April 20, 2012 @ 9:39 am

    Hi Richard,

    unfortunately when you have to develop dashboards (Personal dashboards) on a test system, I can not find a way to migrate it over to production system. Do you know of a way to migrate a personal dashboard over, so we can assign it to a team and have it hidden from others.

  15. Richard Knudson Said,

    April 22, 2012 @ 4:59 pm

    Hi Ali,

    No, unfortunately components such as personal views, charts and dashboards cannot be components in a solution. I’d like to come up with a workaround, but I haven’t figured it out yet. I’ll let you know if I come up with anything. Anybody else got any ideas on this one?

    I did find an article about this, and apparently there’s a codeplex solution that sounds like it might help, but I have not tried it yet. Here’s the article: http://dynamicslollipops.blogspot.com/2011/07/export-import-user-saved-views.html

    Let me know if it helps, and thanks for the note.

    Richard

  16. Sandeep Said,

    April 23, 2012 @ 3:07 pm

    I know we can write a plugin on retrieve multiple and then based on the role we hide or show some system views. It might be possible for Dashboards as well.

  17. Clecira Said,

    May 28, 2012 @ 6:59 am

    very nice blog.http://www.divulgaemail.com

  18. Brad Said,

    October 25, 2012 @ 8:32 am

    Great post !

    I would be very interested how to filter specific dashboards based on a security profile. I tried creating a personal dashboard and sharing with a specific group of users (specifically, a report on a dashboard), however as a user I am unable to uncheck “Restrict Cross-frame Scripting” from the iFrame (with this checked, the dashboard report fails). I needed to create the dashboard as a System Dashboard, which works well, however everyone can see it.

    Any ideas ?

  19. Brad Said,

    October 25, 2012 @ 8:56 am

    I think I found an ugly solution – simply don’t share the report with all users. However, it is still displayed as a possible dashboard in the list – when users without visibility to the report navigate to this dashboard, they get a Permission Denied error….

    it works, but a graceful way to manage this would be great :-)

Leave a Comment