CRM Security Model Part 1

The CRM security model is in my opinion the most complex aspect of CRM that new administrator users of CRM will need to digest. It is not that it is unnecessarily complex but rather complex due to its robustness. That is, CRM can be configured from a security perspective not only in terms of the actions (CRUD along with some other CRM specific options - share, append, append to) that an end user can take on the various CRM entities but also in terms of the scope that a user may take on a given entity. For example, it may be that a user can update account records in CRM (action), but they may be limited to updating only a certain group of contact records (scope). Similarly, a user may be able to view accounts in CRM (action) but may be limited to viewing only a certain group of accounts and not say "corporate accounts" (scope). The same is true for the other actions (known as permissions in CRM speak) such as delete and insert (although insert is decidedly a rarer need in terms of the scope factor).

There is both a hieararchical as well as looser "team" based security model. And when deploying CRM, it is important to understand the structure of the organization in order to understand which model to apply. They are not mutually exclusive and can be combined to facilitate the required security model. Or team based sharing can be automated based on "attributes" of your CRM data in order to create a security model that is more "tag" based. So for example, you could use the team model to make accounts categorized as "investors" to only be view-able or update-able etc. by an "investor" team. You would want to automate such  a feature to ensure that such classification always happens and not to burden end users with extra "sharing" steps.

Yet, even with all the robustness of the security model there are still some gaps. The one that is most often encountered is the Field Level Security issue. For example, although you can control who can view say an account, once the account is view-able, you cannot control (in CRM 4.0 out of the box that is) what fields on the account can be viewed. Of course there are a number of 3rd party tools available to address this shortcoming along with other tricks of the trade that make it possible to surmount this shortcoming in 4.0. Happily, in CRM 2011 this shortcoming has been addressed out of the box so the above is more for the sake of posterity rather than being relevant if you are working with a CRM 2011 installation.

Remember though that MSCRM is an application that has been designed to be generic enough to be applied in all kinds of organizations across the world. And therefore it is pretty likely that a given organization will only require a certain facet of the security model. Consequently the complexity of the CRM security model may vary depending on how you intend to use it. For example, it might be that a deployment only has a need for a single root Business Unit and if so, it will not be necessary to be concerned about the "BU" or "parent-child" aspects of the security model. Or it may be that an organization does not have the concept of "ownership" for records and therefore you can perhaps dispense with the "user" level security. To be sure, I am not advocating ignorance in this regard - it is certainly possible and even likely that a company's implementation of CRM and therefore security model will evolve over time - and therefore it is always recommended  to have a good idea of the capabilities of the security model. However pragmatically speaking - like anything else - your design of the CRM security model should be tailored to an organization's needs and where-ever possible it should be simplified to the extent possible to enable easy administration. At the end of the day, a walk through document relevant to an organization's specific implementation of the CRM security model should be produced to facilitate such an imperative.

This blog entry is titled "part 1" as with this being somewhat of an introduction, I expect that there will be a sequel or two as we delve deeper into understanding the security model and its real-world application.