CRM 2011 Document Management Settings: Based on Entity Pros/Cons

It's been a little while but in a former post we were discussing the various configuration options that we have available when configuring the out of the box SharePoint integration with CRM 2011. And in particular, we were reviewing the impact that the "based on entity" setting has on how the content is physically stored in  SharePoint. Or as I termed it - "the centricity of storage".

I had also mentioned that we'd review the pros and cons of these configuration options and in this post I'd like to make good on that promise. In particular, I'd like to focus on the pros/cons of setting the "based on entity" to  Account or Contact. For the sake of discussion, we'll assume the Account-centric setting.


The benefit of this approach is that the content is a little bit more organized. That is, the structure of the content mirrors the structure of the customer organization and therefore it seems more logically organized to a certain extent. For example, if you had a customer portal that exposes customer documentation, it would be sufficient to link it at the account level and the remaining levels would just “follow suit”.

The main downside of this approach is that it can become more disorganized over time. Some of the contributing factors to this might be:

• Documents can be stored in different paths depending on the “characteristics” of the entity in question. For example, a contact with an account will be stored in the “..\account\SolarTech\Joe Bloggs” location, whereas a contact without a parent account will be stored in the “..\account\Joe Bloggs” location (as there is no account reference). This is perhaps the most unsettling factor as you want order to your data so that you can follow a logical predefined path for storing and retrieving data rather than having two different navigation systems depending on the nature of your data. This issue might be mitigated if the nature of the entity is such that it would always have a parent. For example, contacts in CRM could very well be parented or un-parented leading to the issue described. However opportunities should always have a parent and therefore is less prone to this type of disorganization.

• The relationship structure can change. For example (using the illustration provided in my former post), Joe Bloggs might at some point leave SolarTech and join ABC Corp. This is ok, but CRM is not yet smart enough to detect this change in relationship structure and it will be up to a diligent user (which is wishful thinking at best) to change the location under the contact rather than continuing to add content which will inevitably lead to the wrong documentation appearing under SolarTech.

• The “oops factor”. This is a variation of the above. That is, what happens if I create a contact, click on the Documents link to create the SharePoint location and then “remember” to associate a parent account to a contact? The result is that I now have the SharePoint location for this contact stored in the wrong path and as a user I need to remember to move this around. It is possible to mitigate this by creating some client side script. For example, we could hide the Documents link until an account is added but there are other scenarios that would be impossible to cover (e.g. initially parenting a contact with the wrong account). 

• Too many levels. It can also quite easily be argued that the account-centric approach introduces too many levels into the document storage structure, involving too much required navigation etc.

Next: We will need to review the pros/cons of the "individual" path approach and see if we can perhaps bring it all together by driving towards a best practice recommendation.