Dynamics CRM Data Driven Security

View the wiki technet article here: http://social.technet.microsoft.com/wiki/contents/articles/8164.dynamics-crm-2011-data-driven-security.aspx

Data design and security for many companies is an important subject and careful planning is mandatory. CRM 2011 has shipped with new functionality extending the design options, the new introduced features are:

• Forms based on Security Roles
• Field level Security

Business units concept and security roles permissions stays the same. The ability to display different forms to different types of users was only possible in CRM 4 with loads of programming, extensive planing and maintenance. With CRM 2011 this is now possible out of the box and incredibly easy to implement, allowing more time for planing.

I want to talk about the following topics:

1. Business Unit data isolation
2. Confidential Records with data isolation
3. Security Role data visibility
4. Field level security

Important: To understand the concepts on this article you should have a basic understanding how the following CRM permission levels work:

• Organizational Access
• Business Unit Access
• Business Unit and Child Access

Business Unit Data isolation
I would like to think data isolation as company departments, which work on different floors and have different network drives accessed strictly by that department AD accounts. Business units are great to isolate data, however this approach can be very complex if your company spans multiple countries or multiple offices. The below example, the company Global Exports has 3 levels of security.

On the below diagram the concept is simple; We have 1 Parent business unit GlobalExports and 2 Child business units GlobalSales and GlobalEngineers and each also have a child business unit GlobalSales -> JuniorSales and GlobalEngineers->JuniorEngineers

1. Executives have full access to all data. Executives are placed on the top Business Unit GlobalExports
2. Sales representative are placed on the GlobalSales Business Unit. Only Executives can access sales data, also junior sales staff cannot access GlobalSales representatives data.
3. The same applies to the engineers business unit.

To read the diagram, the green arrows indicate how data-read flows (downwards), you see that no user can go back up and read their parent data.

Advantages:

• Junior staff can only access data in their own business unit, they cannot go back and read data on the GlobalSales or GlobalEngineers Business data.
• GlobalSales and GlobalEngineers are separate departments and do not access either data.
• Executives can access all company data, and no child business units can access GlobalExports Business Unit.

Disadvantages:

• If the Executives would like to share data with sales representatives on the GlobalSales Business Unit, the only available process will be Sharing Records with individual users or creating teams and sharing the records with teams, increasing management time and complexity.
• The same applies to sales representatives or engineers wanting to share data with their junior staff, can only share records with individual users or teams.
• Assigning records to users in different business units can move all child records which hold a parental relationship, adding more extra management complexity with entity relationships. e.g. sales representative assigns a record to a junior staff, the record and all child activities (phone calls, emails, tasks) will be also moved ans ownership taken by the new owner.  

To understand better why sharing records with individual users or teams is a disadvantage and how increases management complexity, the below diagram illustrates the company GlobalExports with a CRM design based on Regions:

Business Units Diagram.

From the above diagram we can ask ourselves a few questions:

1. How users would share data between themselves? 
2. After sharing records during 1 year what is the sense of levels of access?
3. If you created different Security roles for different users in order for them to be able to read across regions, how many security roles or how many users would be associated with these security roles and how would they be managed?

Business Units for data isolation is something that needs carefully planning. Hopefully the above example gives you a good picture of the complexity. However our first example with Junior sales and Junior Engineers are the perfect example how and why we would use Business Units for data isolation.

Confidential records

Business Units are great to isolate data and differentiate departments and keep data secure. A good example about isolating data with Business Units is the implementation of confidential records. Below is a brief description on the design concept:

1. A confidential Business Unit is created under the Parent Business Unit GlobalExports.
2. A user account is created and assigned to that Business unit. (crm.confidential)
3. All users within GlobalExports BU have Business Unit access level.
4. When users would like to make an opportunity confidential they assign the record to the confidential user moving the records automatically to the confidential Business unit, all child records with parental relationships will also move.
5. Because GlobalExports BU users permissions is based on Business Unit access level, no records can be read from the confidential business unit.
6. The way to access data on the confidential Business unit is to share the records between users or teams. This can be accomplished automatically with the CRM free plugin that auto-share records via workflows, so you could tick a box on the form and save, and this would trigger the confidential workflow which would assign the record and auto-share with user triggering the action. http://crm2011sharestep.codeplex.com/

Security Roles Data visibility
Again to help connecting data visibility with real world scenarios I would like to think data visibility as employee job title, employees that work on the same department but that do not necessarily access the same level of information, e.g. Sales representative and a junior sales representative, or a support engineer and a project manager. Assigning forms to different security roles is a new feature in CRM 2011. It provides a more robust way to expose different sets of data to users with different interests. E.g. Engineers and Sales want to get more information about company XYZ however both users are looking at different levels of information, so why provide the same form when we can give them just what they looking for?

At the same time, there is no department boundaries, all data lives in the same Business Unit and can be found by everyone. No need for sharing records.

The below diagram illustrates the company Global Exports CRM design but based on Security Roles data visibility:

Advantages:

• Keep the design simple with one Business Unit (or two if confidential records are required)
• No need to share record
• Ability to mix security roles and provide multiple forms.

Disadvantages:

• No data isolation
• Extra administration maintaining multiple security roles.

 How to assign security roles to multiple forms:
You assign security roles with forms on the customisation screen. Go to Customization > Customize The System >  Expand Accounts and click Form - you should see the below screenshot:

Important: By default if users have no security roles associated with a form for the entity they accessing, the default form is displayed. You should always customize a default form in case by mistake a user has no security role associated with the entity form and doesn't access information which should have been hidden otherwise.

Field Level Security

Field level security is a new feature with CRM 2011. Provides granular control over information that should only be accessed by a group of people within CRM e.g. credit card information, company financial information.Things to know about field level security:

• Field level Security only works with custom fields.
• You create Field security profiles and associate with custom fields.
• Assign to users or teams 

Go to: Administration > Field Security Profiles > Click New - below is a screen shot of a field security profile:

 

Mix and Match
Mix and match makes all sense and will create a greater design and provide granular control on all aspects of CRM access. But is also true that will increase complexity and management.

Keep it simple

1. Always keep it as simple as possible.
2. Consider data isolation only if really necessary.
3. Keep Security roles to a minimum.
4. Keep Business Units to a minimum.
5. Provide minimum permissions to users.

Hope you enjoyed the article.
Leave feedback