Hide Areas & Sub Areas in the SiteMap using Security Roles in Dynamics CRM (Privilege tag)
If you need to show or hide a sub area in your SiteMap based on access control security roles, you can easily do this using the Privilege tag in the SiteMap as follows:
<SubArea Id=”crm_myentity” Entity=”crm_myentity”>
<Privilege Entity=”crm_myentity” Privilege=”Read” />
</SubArea>
Based on the above, this sub area will only be shown to users who have security roles with read privilege of the custom entity: crm_myentity.
You can add the privilege tag above to any sub area and the entity in the privilege tag can be any entity and doesn’t have to be the same one as the sub area. For example, the following is also applicable:
<SubArea Id=”contact” Entity=”contact” Title=”Contacts”>
<Privilege Entity=”crm_myentity” Privilege=”Read” />
</SubArea>
This will hide the contact sub area for users without the read privilege for the entity crm_myentity. You can mix and match as much as you want to show and hide any sub area in the sitemap based on any entity you require whether they are customisable/system or custom entities.
As for hiding and controling access to a whole area in the sitemap such as Sales, Marketing or Service (site map section), you will need to set the privilege tag to every sub area inside this area.
So for example, if you want to hide the whole of the Sales Area for specific users, you need to add the “<privilege />” tag to every sub area in the Sales Area. What you can also do, is create a custom entity specifically for setting the security on the SiteMap. The following example will hide the Sales (or marketing or service) area for all users who do not have a security role with read access to the custom entity crm_SiteMapPrivilege:
<!–Sales Area–>
<Area Id=”SFA” ResourceId=”Area_Sales” Icon=”/_imgs/sales_24x24.gif” DescriptionResourceId=”Sales_Description”>
<Group Id=”SFA”>
<SubArea Id=”nav_leads” Entity=”lead”>
<Privilege Entity=”crm_myentity” Privilege=”Read” />
</SubArea>
<SubArea Id=”nav_oppts” Entity=”opportunity”>
<Privilege Entity=”crm_myentity” Privilege=”Read” />
</SubArea>
….
</Group>
</Area>
What you can then do is that, you make every sub area in the Sales area requiring the read privilege of SiteMapPrivilege entity, every sub area under the Marketing area can then have the Write privilege and every sub area under the Service area can have the Create privilege of the crm_SiteMapPrivilege entity. So similar to how the Sales area has read as per the previous example, the Marketing and Service areas can look like this:
<!–Marketing Area–>
<Area Id=”MA” ResourceId=”Area_Marketing” Icon=”/_imgs/marketing_24x24.gif” escriptionResourceId=”Marketing_Description”>
<Group Id=”MA”>
<SubArea Id=”nav_leads” Entity=”lead”>
<Privilege Entity=”crm_myentity” Privilege=”Write” />
</SubArea>
<SubArea Id=”nav_accts” Entity=”account”>
<Privilege Entity=”crm_myentity” Privilege=”Write” />
</SubArea>
…..
<!–Service Area–>
<Area Id=”CS” ResourceId=”Area_Service” Icon=”/_imgs/services_24x24.gif” DescriptionResourceId=”Customer_Service_Description”>
<Group Id=”CS”>
<SubArea Id=”nav_apptbook”>
<Privilege Entity=”activitypointer” Privilege=”Read” />
<Privilege Entity=”service” Privilege=”Create” />
</SubArea>
<SubArea Id=”nav_cases” Entity=”incident>
<Privilege Entity=”service” Privilege=”Create” />
</SubArea>
…..
Hence, based on the above 3 examples (Sales, Marketing, Service), you will need to make sure that users who should see the Sales Area has a security role with the read privilege of our custom entity (crm_SiteMapPrivilege), users who should see the Marketing area must have a security role with the Write privilege of crm_SiteMapPrivilege and Create privilege for Service.
The same applies for any additional Areas that you creates. So if you have added a new custom Area in your SiteMap, you should then use another privilege (append, appendto, etc) for every sub area under your new custom Area in the Site Map to show and hide this area based on your chosen privilege.
You can either manually amend your users security roles to add the privilege (read, write, etc..) or alternatively, a much better way of doing this is to create a new security role for each area. So what I have done is I created the following security roles: Access to Sales Area Access to Marketing Area Access to Service Area Access to MyCustom Area
In each security role, I only set the privilege for my custom entity crm_sitemapprivilege as follows:
For Security role: Access to Sales Area, set “Read” on crm_sitemapprivilege For Security role: Access to Marketing Area, set “Write” on crm_sitemapprivilege For Security role: Access to Service Area, set “Create” on crm_sitemapprivilege For Security role: Access to MyCustom Area, set “Append” on crm_sitemapprivilege
Once I’ve done that, I add those security roles to the users based on what they need to see. So for example: User1, need to see sales area, assign security role: Access to Sales Area. User2, need to see marketing area, assign security role: Access to Marketing Area. and so on,
you get the drill.
Last thing to mention is the possible privilege values that you can use. These can be:
All AllowQuickCampaign Append AppendTo Assign Create Delete Read Share Write
you can also use a combination of those values such as: “Read,Write” or “Read,Write,Create” and so on.
so your privilege tag will look something like this:
<Privilege Entity=”crm_sitemapprivilege” Privilege=”Read,Write” />
<!– OR –>
<Privilege Entity=”crm_sitemapprivilege” Privilege=”Read,Write,Share,Write,Append” />
The advantage of using combinations is that it will allow you to do this for as many Areas as you could ever need.
