As many of you know Microsoft Dynamics CRM 2011 has a built in integration with SharePoint. As a former SharePoint consultant I have reviewed it to see how it looks, not only from a CRM perspective but also from a SharePoint perspective and there are some major issues from this perspective that one needs to take into consideration. For those of you who attended my presentaton at SharePoint Exchange Forum 2012 22-23 of october this year this is more or less what I presented.
First of all, to make it work properly, you are recommended to install a special addon to SharePoint called the CRM List Webpart. This makes the document lists in SharePoint get a more CRM-y look. I found a very good blog with detailed instructions on how to install it which, at least for me, worked perfectly; http://mossdevsharepoint.blogspot.se/2011/07/integrating-crm-2011-with-sharepoint.html
When this is done, you simply go into Settings-Document Management and click on the “Settings for Document Management”-button. This will start a wizard that will let you configure the integration.
It will default which entities are to be used for the integration and you are also asked for the base site URL. This site will contain all CRM documents unless you do some manual configuring (as described below) so I generally recommend that you create an empty site. It will also create one document library per entity that you have selected in this site.
The result will look something like the following:
|Document libraries created in SharePoint (left) will match the entities selected in the document management settings in CRM (right)|
For now, let’s refrain from the ranting and just note that this is how it will look.
If further entities requrie document management, these can be added later by re-running the wizard.
After you have selected which entities you would like to use document management for, the wizad will show you the following query:
|Folder Structure selection|
This query is very important to the structure of documents in SharePoint. If you chose to use a folder structure based on an account or contact (my recommendation is generally to use Account here if this is your primary customer entity and only use contact for strict B2C).
If you choose the structure based on account, a folder structure will be created in the SharePoint Document Library as follows:
|Folder structure if based on account for an account with sub-opportunities and quotes|
Do note the folders called Opportunity and Quote that have been created. Rant below.
If, instead the structure is selected that is not based on an entity, a flatter structure will be created.
|Folder structure created if not based on an entity|
The folder structure is a lot flatter, but note the difficulty of trying to identify the quote folders for the opportunity “CRM Online for A Store”. As no hierarchy is used, the only way of distinguisishing sub-objects is to use descriptive names as I have done with the opportunities in this case to indicated that all your bases are belong to us.
To be total just, no object specific document folders are actually created in this step. This is something that is done the first time you open the documents tab for the object (ex. the account “A Store”).
So to give a quick review, the following can be concluded:
– Hierarchical structure is to be selected if documents are to be navigated to with SharePoint as the flat structure makes it very hard to understand which folder belongs to which place.
– When you reparent something in CRM, for instance if the opportunity was created towards the wrong company in a corporate hierachy and you reparent the opportunity. This will not trigger any changes in SharePoint which is ok if the flat structure is used but not so good if the hierarchical structure is used as the opportunity documents will be stored under the wrong account.
– The flat structure gives a clearer division of document types. For instance all Quote documents will be stored in a separate document library and all documents related directly to accounts in another.
– With the hierarchical structure, most documents will be stored in the account document library which for larger installations would incurr large amounts of documents. This will make it more diffucult to use.
You can also connect your CRM objects manually to a specific folder/document library, this enables you to create a more logical structure in SharePoin, like one site per customer, and then manually connect each of these site’s document libraries to the corresponding account in CRM. The problem with this is that you have to follow the following steps to do it (example for a customer setup)
- Create the account in CRM
- Create the customer site in SharePoint
- Copy the right part of the URL from the document library in SharePoint.
- Add a new document connecion in CRM and past the document library from (3) into the field.
This will not work in normal CRM implementations as the tasks are too complicated for normal users, and especially salespeople to do.
Another perspective that is important to remember that the security (privilages) for the document libraries are not replicated from CRM to SharePoint. SharePoint has a more traditional top-to-bottom security architecture and the security architecture of CRM is a lot more complicated and it is very complicated to try to replicate the privilages for a specific object in CRM to the corresponding folder in SharePoint. This is due to the fact that the CRM security architeture is dependent on both owner (user or team) and sharing that have been made. For instance adding or removing a person from a team would requrie you to check all ownerships and sharings for that team in order to mimic the security settings. The recommended way of handling this is to allow all people in a group to have access to all documents in SharePoint and then remove access (inheritance) for the folders that require special permissions. It requires special handling and would be very cumbersome for large organizations.
My final conclusions are hence that the use of SharePoint as a document storage tool for CRM greatly enhances the document management funtionality of Dynamics CRM but it has not been designed to enable logical use of the documents from a SharePoint perspective. The security aspect is also somethnig that will reduce the way it can be used. I would also recommend that the documents are to be accessed mainly from CRM and only in very special cases from SharePoint.
I am not aware of any third party addon that increases this functionality, if you do, please leave a comment!
MVP, CEO and owner at CRM-konsulterna AB
This is a great description of Dynamics CRM and SharePoint integration out of the box.
Currently all CRM users have access to all entity documents even if CRM user does not have access to the entity.
We are working on the design / solution of this problem to make this document security more granular. Will send you the updates.
Thanks for the information. My business has been rapidly expanding over the last few months and we've had some issues in organizing all of the extra paper work. I've looked into various electronic document management solutions, but I'm not the most technologically literate person. Is there anything you would recommend I do; or perhaps some software that is easy to learn?
Great post regarding the integration of MS Dynamics CRM with Sharepoint. It is not an easy do. While Sharepoint has been designed in a manner where even a non-technical person might be able to learn and make use of it, this integration might not be too easy for a lay person. But for those using either of these, this is a great way to enhance their internet document management systems and make better use of Dynamics CRM by integrating it with Sharepoint for document storage. Thanks for the info and a descriptive post on this subject.
Thank you for this interesting post, I managed to create a hierarchical structure under account for all entities that serve us except for the "contract" entity. There is a reason why "contract" does not follow the rule of other entities such as quote, order or cases?
@Ale, well the contract entity is a very strange entity to start off with and to be frank I don't know why it acts that way. I Think MSFT might have put in special logic for opp, quote, order and case as these are very common entities but contract on the other hand is not.
then it is a known problem, and not an error in my system.
you known if there is a solution?
Thanks for the advice
Very good post. We have just discovered the serious limitations of this plug-in, particularly concerning the security aspects in a large organisation.
@Chris Brown: Yes, it is very limited. I have been looking into trying to create a more enhanced version myself as an ISV Product but it has been too long since I worked with SharePoint and I find that the SharePoint API:s are too limited, especially when working CRM Online – SharePoint Online. Thanks for you praise! Nice to know that it is appreciated.
there is a commercial product on the market solving this security issue (http://connecting-software.com/index.php/en/solutions/products/cb-dynamics-crm-privileges-to-sharepoint-permissions-replicator)
Interesting. It is very complex to replicate this to SharePoint, as not only the BU/Role structure has to be replicated but also the sharing, joinging/unjoining of teams etc. can have effects on effective permissions in SP.
Definitely. It is not trivial task to implement and test it properly. There are a lot of actions and scenarios that can change permissions in CRM.
I am directly developer of this solution so feel free to ask more if you are interested. I'm trying to inform people about this product because so far I have not find any free or paid alternative that is covering this. And there ale a lot of discussion post regarding this issue and most of them are unanswered or simply not possible !
Ok. Thanks for the information. I have not had the time to look into it yet, but if it is what you say it is I think you have a good product. I have heard several customers asking for this functionality and it is especially large customers.