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.
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.