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.
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:
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:
- To execute code using impersonation, the MSCRMCallerID header must be added to XMLHTTPRequest along with the impersonated user id:
- 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?