MSCRM 2016 Admin Utility – Personal Views Manager

April 11, 2016

You may have noticed that even under the almighty System Administrator Security Role, you can’t view (nor edit, share, assign or delete) other users Personal Views. Well, that’s what personal means. Via the application UI, only the view owner can manage it.

This restriction can be troubling in some scenarios:

  • A user who shared his Personal Views with other users or teams has left the organization and now no one can edit or delete these views which are irrelevant or just annoying
  • A user has defined and shared a resources hungry Personal View which execution make the application grind to a halt

In this post, I’ll demonstrate a utility which allows you manage other users Personal Views, as long as you have the right privilege.

WIIFM? 

As you can see below, after selecting a user, you can view and manage the user owned Personal Views by deleting or assigning to yourself:

Personal Views Manager demo

If you are not into JavaScript coding and just want to use this utility, you can download the unmanaged solution. After importing this solution, open it, navigate to the Configuration element and manage away. It is recommended that you have the System Administrator Security Role. 

Note
that this utility was developed and exported from Microsoft Dynamics CRM Online Organization (v2016) but it should work perfectly in an on-premise v2016 deployment.
If you are using an earlier version (2015 and below), this solution is not for you, as it uses v2016 new API. There are similar solutions available for earlier versions.

Curious about the implementation details? read on. 

Bits & Bytes

Major implementation notes:

  • Although this utility can be easily implemented on the server side, I opted for client side & Web API which requires less code lines to write and is easier to maintain
  • I intended to add an option to Share Personal Views but encountered Web API limitation, as the GrantAccess message is yet unsupported. One option to implement this feature is calling a Custom Action wrapping a Custom Workflow Activity to execute GrantAccess request
  • The entity used to represent a Personal View is userquery 
  • The magic feature enabling access to userquery records owned by other users is Web API impersonation
  • In order to use impersonation with MSCRM (client or server side), the executing user (consuming the Web Resource) must have the prvActOnBehalfOfAnotherUser privilege, which is granted by default by the built-in Delegate and System Administrator Security Roles:

    prvActOnBehalfOfAnotherUser privilege 

  • To execute code using impersonation, the MSCRMCallerID header must be added to XMLHTTPRequest along with the impersonated user id:

    using the MSCRMCallerID header

  • Some good news though: in order to Assign a record using Web API, you only have to update the onwerid attribute. Sound so trivial…why did we ever need AssignRequest?

    use update instead of AssignRequest

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

one comment

  1. AnneNovember 14, 2017 ב 12:03 PM

    Hi,

    I’m logged in as System admin and the fields are still greyed out. Als in one environment I get a prompt for credentials. Could that prompt be because it’s a 365 version?

    Reply