Security roles are inherited by child business units in Microsoft Dynamics. As I mentioned in a previous blog Sneaky Cylon Copies of Your CRM Security Roles, security roles have linked copies that have the same name but are separate entries with their own unique guids for each business unit. This creates an interesting situation when you want to base business logic on a user’s security role memberships. Since the only thing that is effectively guaranteed to be the same between parent and inherited security roles is the name you need to enact some design patterns to use them in a consistent manor in your code.
 
I’ve mentioned this before but I’ll reiterate that according to Microsoft it is best practice to define your roles at the root business unit. Also mentioned as best practice is if you decide to create security roles below the root business unit that they have unique names across business units. An example of this is if you were to create a security role called Customer Service Manager in business unit A. The premise of this security role may be valid in other business units but you should not create security roles in the other business units with the same exact name. (FYI – You can’t use a security role defined in one business unit for another business unit unless they both inherit that role from a parent business unit). The reason for this rule will become apparent as we continue the discussion.
 
It stands to reason that when creating business rules based on security roles that you implement those rules using the name of the security role or roles. The security role names are the only thing guaranteed to be the same down the business unit hierarchy. This is one of the reasons why you want to make sure that if you decide to create security roles below the parent business unit that the names are different else you will not only have to check for the security role name, but also the business unit it applies to. Yeah sure you could probably get away with it but I’m all about making life easier.
 
Unfortunately I have seen places where security role business logic is baked into code with hard coded names of security roles. This just feels like a crime because if anything about those security roles change (like the name) then the logic in who knows how many places has to be updated to match. When the time comes and changes need to be made to a system I don’t want to have to worry about stepping on land mines if I change anything about the system. I have a real pet peeve about hard coded attribute names and such because it causes some poor person later on more work in order to update and maintain the code. The following is what I believe is a better way to go.

If we assume that the name is what we have to key off of for security roles then we should obfuscate the name out of our code so that if it was to change then we don’t have to worry about all the places it is referenced. I’m thinking more in terms of JavaScript because that is where I’ve felt the most pain. In order to do this you could create the reference to the security role in a global variable in a JavaScript file that is global to the organization. I mentioned a methodology of doing this in a previous blog named CRM 2011 JavaScript Library Methodology. This would give you a way to update the security role name if it ever changed and take care of its reference in other places in the code. A second way way to do this would be to obfuscate the role names would be to use a configuration entity to store the security role references (reference my previous blog on the configuration entity titled Two Custom Entities that Are Useful in Every CRM Solution. The cons to using the configuration entity as you might imagine is that it requires a service call to get the values. The thing that you have to evaluate when decided how to implement this is performance versus maintainability. If you store information in the configuration entity you at least have access to it from both JavaScript, plugins and workflow assemblies. This is really nice but when you have a system with a large number of users it just may not be practical.

Just FYI, I have not yet had an opportunity to implement this in a project yet. I came up with this the other week when dealing with security role business logic. I don’t see why this design pattern wouldn’t work but I’ll certainly let you know when I get to try it out. The tactic seems sound at face value. Easy to implement and makes code easier to maintain. The day I get to see a project with code that has a proper level of obfuscation I will jump for joy, but I have a feeling I may be waiting a little while before that happens.