In the original introduction to this topic we termed this option (i.e. leaving "Based on entity" unchecked) as the "Individual Path". This is because when I store documentation using this setting, the path to the stored document will go straight from the root location to the sub-location corresponding to the name of the entity it is stored under (account, contact, opportunity etc.). As opposed to the Account Path which is relative to the parent entity in which the document is being stored and therefore for child entities will involve an additional level of navigation.
The main benefit of this approach is that it is quite simple. To find or store contact documentation, you just need to navigate to the corresponding contact in SharePoint. And also... it avoids the downsides that were mentioned in the Account Path approach.
The main downside to this Individual Path approach is that there is no connection between this and the parent account from a SharePoint navigation perspective (i.e. when navigating from the SharePoint user interface). Other downsides include:
- If the sub-contact moves to another account, then some manual steps would need to be taken to prevent the co-mingling of content from the former and current account.
- The “oops factor” is also present but to a lesser extent than in the account centric approach. For example, if a contact, opportunity etc. is renamed the SharePoint location name will no longer correlate exactly with the corresponding CRM entity it is linked to (unless manually fixed).
It should be mentioned that both of the above downsides also are present for the Account Path approach. These should be addressed either via business process or by implementing business logic to prevent these issues from occurring. For example, you could use jscript to prevent the entity name from being updated in order to prevent the second scenario from occurring.
In the next post, we'll wrap up this topic by trying to pull it all together and arriving at some implementation recommendations.
Next: CRM 2011 Document Management Settings: Select Entities
Thanks for kick-starting this useful and interesting discussion!
ReplyDeleteHow does Sharepoint handle the occurrence of two Contacts with the same name? I assume the second one must become JoeBloggs2 or somesuch.
With the "based on entity" approach using a parent Account in the path this should be reduced as there will be fewer collisions within a single company than there will be in the world at large.
This alone may not be enough to offset the other downsides you mention though.
In general, CRM does have a more general issue with Joe moving to another company and dragging all his historical activities, opportunities and cases with him. I tend to always favour these being linked to a "Customer" which is an Account (in a B2B scenario of course), and adding a custom link to the related Contact. That way even if Joe still has them linked to him, at least they do still show up against the original Account as well.
It can often be better to give users a tool (a process dialog is fine) to create a "clone" of Joe instead, who works for the new company, inherits a new address etc, and leaves all the old activities behind, but is linked to the original Contact so it is easy to follow the thread back and see the longer-term view of the relationship with that person. Once this is on place the "parent customer" field is locked so it cannot be changed once filled in, even if incorrect - a new record is created instead. This same approach would help mitigate one of the biggest downsides of the Account > Contact configuration in Sharepoint.
To be honest, it's a question that I hadn't pondered until you raised it. So I experimented - I just tried creating two accounts with the same name rather than 2 contacts. And when I clicked on the Documents link of the second account it prompted me as follows:
ReplyDelete"A folder with the same name already exists in this location... Click OK to associate that folder with this Microsoft Dynamics CRM record."
So essentially the way it handles it... is to not handle it. If I clicked Ok it would have had a single library servicing 2 different records. It's highly unlikely - as you mentioned - at the account level (which I just did for the sake of this exercise - it no doubts works the same way for other entities). It is somewhat more likely at the contact level. However I'm not sure this presents a problem in light of the recommendation made in the post below which suggests to keep things simple and leverage the SharePoint metadata to tag the content.
http://practical-crm.blogspot.com/2012/04/crmsharepoint-integration-best.html
Of course the above assumes a B2B world where the account is the center of the universe. I could see where this could be an issue in a B2C world where the contact is the center of the universe. However given that this is an exception it is quite easily handled by manually providing a SharePoint location which is what you can do if you click Cancel on the dialog mentioned above.
In terms of the other issues you mentioned with regards to the history - you are correct - it can get complicated. But it's a little beyond the scope of what I wanted to get into here and requires a dedicated discussion in and of itself. There are various ways to approach it. But I think you have a very well thought out approach to this - I've actually done something similar in terms of implementing a "cloning" process. This kind of scenario is rampant in the "relationships" businesses (e.g. Thanks for the write up though - good food for thought and I appreciate the time spent writing it up.
Perhaps a separate blog post is required to tackle this one - if I'm brave enough to try and take that one on...