Special privileges in CRM Security Roles

There are several privileges in Dynamics CRM that control access to things like settings and user personalisation features, rather than data records. If users are missing some of these then they might not be able to sign in to CRM at all, or might not be able to use it properly. In particular, there are six privileges that can only be set at User level

Privileges that can be set at “User” Level only

There are a few privileges that you can only set to User level or None in any security role. Five of the entities for which this is true are on the Core Records tab, and you can easily find out which they are by looking at the System Administrator security role (shown below). Even this “super user” does not have global rights to these items so they stand out as the only rows not covered in green circles:

(Minor note: the above screenshot was taken from CRM 2015. In CRM 2013 and earlier, you will see that UserEntityInstanceData is written as one word with no spaces, and appears below User Entity UI Settings.)

The 5 rows to pay attention to here fall into two groups:

Saved View, User Chart and User Dashboard

These control access to a user’s saved personal views (saved Advanced Finds in other words), personal charts and personal dashboards. I know in some organisations, some users are not allowed to use these features. This is typically in high turnover, call centre type environments where users should already be presented with everything they could possibly need to do their focussed, process-driven jobs. But most of the time, for regular “information workers” the ability to personalise and enhance their CRM experience makes these features really useful, so you will want to keep them turned on.

You cannot set these above “User” level, so this means you cannot grant one user the rights to another user’s views, charts or dashboards directly. This can only be done through sharing, and only by the owner or someone that already has the items shared with them, including the “Share” rights.

User Entity Instance Data and User Entity UI Settings

These two entities store details about a user’s recent usage of CRM in two tables in SQL server. Without trying to document these precisely here, this includes things such as pinned views in Outlook (User Entity Instance Data) and the most recently used records (as an XML string) and the last form a user accessed for each entity (User Entity UI Settings). This enables a lot of the behaviour in CRM to take a user back to where they have most recently visited or present data to them in the way they prefer (having switched forms, they keep using the same form for their whole session until they sign out).

If users do not have access to Create, Read and Write these two special entities, you will probably find that they cannot sign in to CRM at all. To be more precise. if a user has never had these privileges, they will not be able to sign in. If they have had them, and signed in, and then the privileges have been taken away (if their security roles are removed for example), then they can probably sign in, but might get errors if they navigate to entities they have not used before and open a record (because the system tries to write a row to show which form they used).

So while you might see situations where users can work without these, in general I would suggest this is a bad idea. You definitely want to make sure that all users have at least Create, Read and Write access to these two rows.

Don’t confuse either of these with the User Settings row on the Business Management tab. That one can be set to different levels, but typically a user should have at least Create, Read, Write, Delete and Append To at User level. Some out of the box roles set some of these higher, for example at BU or Organisation (global) level. The System Administrator role has global access to all privileges for User Settings.

User Application Metadata

This setting is on the Customization tab rather than Core Records, and again, this can only be set to None or User levels. This was introduced in CRM 2013 and plays a similar role to User Entity UI Settings, but for the tablet app rather than the browser or Outlook. Users will need this set to User level if they need to use the mobile client, as well as the special privilege Use CRM for Tablets on the Business Management tab. They would also need to be able to Read the System Application Metadata. This is discussed a little more in CRM Tip of the Day #4: The Application Metadata security privilege.

Unlike the previous two, this one is optional, depending on whether you have users accessing the tablet application. If you use custom security roles and have upgraded from a previous version of CRM, it will be set to None, so you will need to check this. My advice would be to set all the privileges for this entity to User level in all roles (or at least in a role that all users share). Then control access to the tablet app using the single Use CRM for Tablets privilege which is intended to do exactly that. This is likely to be clearer for admin staff to configure, and easier to troubleshoot.

Include these privileges in a role assigned directly to the user

These six special privileges can only be set to User level (or None). You must include these in at least one role that is assigned directly to a user, not just in a role that they “inherit” via membership of a Team.

Yes, for regular entities you can use privileges at User level with Team security roles, and then “User” really means “This Owner”, in other words the privilege applies to records owned by the Team (not those owned by any of the Team’s members). Users do not really inherit security privileges from their Team roles, they can only take advantage of them from the point of view of the Team, as discussed in my post Security Roles and Teams in CRM – An Inconvenient Half-Truth.

For these special entities, we are talking about my settings and my recent use of CRM. This information can only be owned by me, a user. Teams do not sign in, so they do not have any usage or historical data to save in the first place. So to take effect, you must include the six settings discussed above in at least one security role that is assigned to a given user. My preference is usually to create a “Baseline” security role that includes privileges such as this, and which is always assigned to all users. (More on that thought is coming in a later post).

Note that Use CRM for Tablets is either on or off (None or Organisation / Global) so this can be included in a role that is assigned to a team (including a Default Team for a Business Unit) and will apply properly to all users who are members of that team, because global privileges are effectively inherited.

“Delete” privileges on these special entities

Again, the privileges that can only be set to User level fall into two groups here: the first three are used for intentional personalisation by users, whereas the latter three exist to store information about their use of CRM and improve their experience.

User UI Components

I would strongly suggest that if you grant users the right to create and edit UI components such as personal views, charts and dashboards, then you really ought to let them delete them as well. If a user no longer needs something, or saved it in error, or made copy to work on and now wants to get rid of the original, let them do it. If you don’t, you risk users becoming frustrated and not wanting to take advantage of these features. So for me these three rows are usually set to User level across all the privilege columns, in all security roles.

User history data

These other three are more inscrutable. As far as I can see, users don’t actually need the ability to delete these kind of “history” records. CRM updates rows as people use the system, but should not need to delete them. I tend to leave the Delete privilege at User level for these three as well, just like it is in the out-of-the-box roles, but I have not done extensive testing to see if this is actually required to make the system work.

The reason I highlight the Delete privileges here, is that very often I have clients who want to remove any rights to delete anything, ever, from all roles and I tend to agree with or even suggest this (perhaps more on that in a later post too). So CRM admins or customisers go right ahead and click the column heading for “delete” until everything is blank.

This sounds good, and the system probably passes all the UAT tests when people check that they can do all the usual business tasks and that no users can delete any data. It is quite possible no-one will think to test whether a user can create a saved view, and then delete it. This tends to come out through support calls soon after go-live. Those users who paid attention in their training session and then went back and tried out their new Advanced Find skills will find they can’t delete those first few random attempts at personal views.

So, make sure you reinstate those Delete privileges for the three user UI components, and possibly the other three special “settings” entities as well.

Share your thoughts

Have you had issues with getting these security privileges to work? Do you have any particular scenarios where you have needed to set these up in unusual ways, or deny access to these features? Let me know in the comments below!