Scenario:
“We, conceptually, have two ‘apps’ within a single Dynamics CRM organization. The ‘apps’ share a common set of entities such as Contacts. We want to control which ‘apps’ show up in the Dynamics CRM navigation Area for a given user based on Security Roles. The user has rights to entities that show up in both navigation Areas. How do we enable this scenario?”
The trick is in understanding how security trimming of the Site Map works. You might want to read this blog post as a backgrounder:
I’ll build on the post above to show how to enable the scenario. Let’s start with the example:
I am logged in as a System Administrator so I have access to both App One and App Two. Notice the contents of my Solution:
The Site Map is a given. We’ll be modifying it to enable the scenario. I have two Security Roles: App One and App Two. These represent how we differentiate access to different ‘apps’ in the organization. Finally, you see two entities: privSiteMapAppOne and privSiteMapAppTwo. These are entities that will never contain data. They only exist for the purpose of adding a “custom privilege” that can be used from the Site Map. Here’s a screenshot of each Security Role:
Notice that each Security Role has Read access to the corresponding “custom privilege entity.” Now let’s look at the Site Map configuration. I’m going to be showing it through my favorite Site Map editing tool, but you should be able to do the translation to however you edit the Site Map:
Notice that AppGroupOne->BingSubArea has a Privilege child node with Entity set to dkdt_privsitemapappone which is our “custom privilege entity” and the Read checkbox checked. The way I read this in English is “Only show the BingSubArea navigation link if the user has read access to the dkdt_privsitemapappone entity.” The XboxSubArea is configured similarly but with the other dkdt_privsitemapapptwo “custom privilege entity”:
Ok great, but we still haven’t enabled the scenario. Why? Because I’ve also included a SubArea that enables the What’s New navigation link that is part of Activity Feeds.
Since both Security Roles have Read access to the post entity, users who are in only one of the two Security Roles will still see both Area navigation links. Why? This goes back to understanding how security trimming with Privilege settings work for the Site Map. If you have rights to see anything within the Area, the navigation link shows up. You just don’t get to see the children in the area you don’t have access to. The trick (which is what this whole post has built up to) is to add a second Privilege node to the nav_personalwall SubArea for the corresponding “custom privilege entity.” Here it is for the AppOneArea node:
The way I read this in English is “Only show the nav_personalwall SubArea navigation link if the user has read access to the post entity AND the dkdt_privsitemapappone entity.”
Do the same for AppTwoArea node:
At this point, a user who is in the App One Security Role will only see the App One navigation link:
A user who is in the App Two Security Role will only see the App Two navigation link:
Users who are assigned to both Security Roles will see both (see the first screenshot in the post). HTH!
Gold Coast 