Mother may I? Granting permission to key user scenarios

posted at: 9:24 PM by Aaron Elder

---

One thing that continuously seems to be a problem for CRM 4.0 customizers is the fact that things just don’t seem to work right when you create custom Roles and try to grant access to particular “scenarios”.  The reasons for this are two fold:

1. The Microsoft CRM privilege model is complex and the exact combination of privileges to perform a particular action are NOT well documented.  This is probably the single biggest cause of frustration for customizers and users alike.
   
   Because of the complexity and the lack of “scenario based” documentation, it is rarely obvious what privileges are needed to do what.
   
2. There are bugs in the how custom roles are created.  The root cause so of this is that all of the roles that ship “out-of-the-box” contain a base set of privileges… privileges that are not settable via the Role Editor user interface.  When you create a new Role from scratch, these privileges are suppose to be granted automatically… so that your Role gets these privileges too.  The bug is that some of these “hidden” privileges are not added to your role automatically.
   
   This is why things seem to magically work when you create your new Role by using the “copy” feature to base your Role on an existing system Role.

With this post and subsequent additions, I hope to address both issues.  Let me start by providing some documentation for what I am calling “scenario based privileges”:

User Scenario	Privileges Required
Create a personal Workflow Note: This means to both create and publish a “personal workflow”	Required to Create: Local Read on System Job Local Create on Workflow Local Read on Workflow Local Write on Workflow Required to Publish: Execute Workflow Job Local AppendTo on Workflow
Bulk Import Accounts Note: For this scenario, we are using Accounts, but you could substitute another entity.	Required to access Accounts: Local Read on Account Local Create on Account Local Write on Account Required to make the Bulk Import menu show up: Local Create Data Import Local Read Data Import Local Delete Data Import Required to actually have the Bulk Import work: Local AppendTo Data Import Local Write on Data Import TBD Read on Import Map TBD AppendTo Import Map Local Create on Import Source File Local Read on Import Source File Local Write on Import Source File Local Delete on Import Source File Local Append on Import Source File Local AppendTo on Import Source File Local Assign on Import Source File Local Share on Import Source File

The personal Workflow user scenario is confusing and difficult for customizers to implement for several reasons including:

• The Create, Read and Write privileges on Workflow actually only control the users ability to “define” a workflow… with out Read on System Job, they could never actually see their workflow “running”.
  
• There is no “Publish Workflow” privilege… so CRM instead uses the “Execute Workflow Job” privilege.  This might be confusing, but since the user is the “owner” of the workflow and the workflow will execute “as them”, they will need to have this permission.
  
• Finally (and this is a bug), you can’t set the “Append To” privilege on Workflow via the Role Editor.  This privilege is included by default for all system Roles, but if you happen to create a new custom role from scratch you would be missing it and would be having one heck of a time trying to figure out why users keep getting Permission Denied when they try to publish their workflows.

 

The Bulk Import scenario is confusing and difficult for customizers to implement for several reasons including:

• The privileges that control whether or not the Import homepage and the “Import Data…” menu item show up are only a small subset of the privileges actually required to have it work.
  
• The privileges to Data Maps are a bit confusing… note in this scenario, I assume that a Data Import Map has already been created and shared with the user doing the import.  If the user needs to create their own maps, then obviously this would need to be extended to include more privileges.
  
• Finally (and this is a bug), you can’t grant all of the access needed on the “Import Source File” entity.  These privileges are included by default for all system Roles, but if you happen to create a new custom role from scratch you would be missing them and would be having one heck of a time trying to figure out why users keep getting permission errors while trying to do imports.

 

I hope that this article helps clear up any confusion as to the privileges required to create workflows and perform bulk imports.  Please note that the types of workflows the user creates and the type of data they import, will of course require additional privileges.  For example, if the workflow attempts to create and send an email, then the user (owner of the workflow) will need to have privileges for that as well.  Likewise, if the Bulk Import attempts to link an Account to a Contact, the appropriate Read, Append and AppendTo privileges would be required.

Finally, I would like to make available a “hacked” Role Editor page that allows you to grant the privileges that are missing in custom “made from scratch” Roles.  This editor can be installed simply by extracting the ZIP file over top of your current Role Editor ASPX page located here:

[CRM SERVER]\CrmWeb\Biz\Roles\Edit.aspx

This modifications makes some of the “hidden” privileges available for you to add / edit.

This modification is provided “AS IS” and should be used at your own risk.  Be sure to do adequate backups and testing before using in a production environment.  You can download the modification here:

http://www.ascentium.com/blog/crm/Gallery/Ascentium%20CRM%204.0.7333.3%20-%20Role%20Editor.zip

 

Enjoy,

This posting is provided "AS IS" with no warranties, and confers no rights.