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.
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.
The complementary paper includes over 12 years of research, recent survey results, and CRM turnaround success stories.
This 60-second assessment is designed to evaluate your organization's collaboration readiness.
Learn how you rank compared to organizations typically in years 1 to 5 of implementation - and which areas to focus on to improve.
This is a sandbox solution which can be activated per site collection to allow you to easily collect feedback from users into a custom Feedback list.
Whether you are upgrading to SharePoint Online, 2010, 2013 or the latest 2016, this checklist contains everything you need to know for a successful transition.