Lately we have had a few clients ask for a more hierarchical structure for their User management. For example, a Sales Rep has a Regional Director, who has an Area Director, who has an Area VP, etc. Normally in CRM we would use Roles in combination with Business Units to handle these permissions. But what if the client needs to know this structure? What if they need to know that Jane Doe is John Doe’s Director? What if a Director resides in 1 Business Unit but has a subordinate in another Business Unit? Currently in CRM, the roles are flat. There is no hierarchy. Business Units help with permissions but can lock you into very rigid structures. So how do we do it?
When I first started using CRM 3, I noticed that the Users had a Manager field, but it was always disabled. I never knew how to edit this field and over the last year or so, have not had to.
Where do I edit the Manager?
The Manager field is enabled when you first add a User to CRM. After you save the User, the Manager is disabled. This functionality is similar to the Business Unit field. To edit the Business Unit I knew that you do that through More Actions on the grid view of the Users. So I went there first to see if I could edit the Manager. Sure enough, there was the option to “Change Manager”. |
|
What does the Manager do?
Setting the Manager field gives the hierarchy we need, but does it also give the permissions we need? Can a Manager automatically see entities the subordinate owns?
Getting the Manager field is very simple. Through the Sdk, the Manager is available through the systemuser.parentsystemuserid property. Through Filtered Views you can get the Manager’s Id by querying the FilteredSystemUser and returning the parentsystemuserid field. Filtered Views also return the parentsystemuseridname as well. Using either of these methods, we can create a recursive function that will return the Manager of a User and the Manager of that Manager etc. Below is a very basic example:
protected void searchButton_Click(object sender, EventArgs e)
{
CrmService service = new CrmService();
service.Credentials = System.Net.CredentialCache.DefaultCredentials;
//Pass in the User who's hierarchy you want to get
GetManager(new Guid("d01f2501-efb2-db11-ab88-0003ff5681c4"), service);
}
private void GetManager(Guid userId, CrmService service)
{
ColumnSet cols = new ColumnSet();
cols.Attributes = new string[] { "systemuserid", "parentsystemuserid", "fullname" };
//Get the User
systemuser user = (systemuser)service.Retrieve("systemuser", userId, cols);
if (user.parentsystemuserid != null)
{
//User has a Manager
GetManager(user.parentsystemuserid.Value, service);
}
else
{
//The boss
}
}
Why use the Manager field?
The next thing I wanted to check was to see if CRM automatically gave the Manager permission to the subordinate’s entities they owned. This did not happen. We can however easily achieve this by sharing the entity to the User’s Manager. Using a post callout we can check to see if the Owner has changed. If the Owner changed, use the same recursive function above to share the entity to the Manager on up. Using this, we can now achieve the permissions we need without needing the rigid and very limited Business Units + Roles model.
Using the Manager field in combination with Business Units, Roles, and sharing truly opens the door to a much more flexible security model than CRM offers out of the box. This example was a very basic example to illustrate how useful the Manager field can be to achieve an actual hierarchy with CRM.
This posting is provided "AS IS" with no warranties, and confers no rights.
Loading ...
