Can a Librarian Manage Library with No Classification System?
(Why CRM and SharePoint integration fails user expectations?)
The metaphor of librarian managing library with no classification system is best describing the poor out-of-box feature to integrate Dynamics CRM with SharePoint. In the article “CRM is from Mars, SharePoint is from Venus”, we suggest using less SharePoint folders and more metadata retrieved from CRM records, to “bridge” between these two standalone great products from Microsoft (CRM & SharePoint).
Classification system can be constructed if relevant and effective metadata is available. Dynamics SharePoint Organizer (SPO), is one of the available add-on to CRM, enriching CRM and SharePoint integration, by saving relevant metadata with the documents uploaded to SharePoint (read more).
In this post we describe and analyse CRM and SharePoint integration and the inherent limitations, which is the first step before one can evaluate alternative solutions.
Integrating CRM and SharePoint is few steps process, available in CRM>Settings>Document Management>Document Management Settings. The integration is based on entities. You select and integrate only those entities that you wish to link and associate with the documents uploaded to SharePoint. After entering SharePoint Site, you only have one option to select from to configure this integration, whether the entities you have selected are created as standalone unrelated document libraries or create a folder structure whereby the selected entities are child folders to a parent folder which is either Account or Contact entity (Account or Contact Centric structured folders).
The advantage of Account or Contact Centric structured folders is in linking all the documents related to an account (or contact), as a group. The disadvantage is in the need to go through two more folder levels to reach a document.
Standard folders structure– has 3 levels: Entity name -> Record name -> Document
Account or Contact Centric folder structure – has 5 levels: Account -> Account name -> Entity name -> Record name -> Document
It worth mentioning that in order to upload documents from CRM to SharePoint, the function is not available in the tools / functions ribbon of the record, and once you reach it, you can only upload documents from hard-disk, and only one document at a time. To upload documents attached to the records’ Notes and Emails, they firstly need to be saved to hard disk and only then uploaded to SharePoint (one by one).
This is like our library positions its entry at the very far end at the back of the building, and only allows you to return one book at a time.
Don't get the wrong idea and assume the issues are with SharePoint. The other way around. SharePoint is a great product to store and easily retrieve documents. The issue is with the integration function in CRM.
The starting point is, you must upload documents with metadata from the CRM records. An example of possible metadata from the Invoice entity is Invoice ID, Date, Customer (Account), Total Amount, Payment Terms, Date Delivered, and Description. When uploading documents, you can assign Content Type to the document. In our case, invoices uploaded from CRM will be assigned with Content Type Invoice, when they are stored in SharePoint.
At the extreme end, we can store all our CRM documents in one only SharePoint library. Having all documents with no folders eliminates the need to navigate through complex folders structure. The metadata uploaded from CRM is stored in the library columns. A column can be selected to group records in a view. The Customer metadata / column is an obvious selection to group documents in this folder for each customer. Two levels of grouping are available per each library view. The second level can be the Content Type within the Company group. Content Type is a method to tag group of documents of the same type, like invoices will be classified as Content Type Invoice and orders as Content Type Orders. In essence this is what Microsoft is trying to achieve in integrating CRM and SharePoint, but without metadata. They are “replacing” metadata with SharePoint folders by using the Name field of the record as the folder name.
There are number of issues with this approach:
1. In most CRM entities the Name field does not necessary contain useful information to justify using it as folder name.
2. The Name field is not unique. This is critical when using Account or Contact Centric folder structure, as Account Name can be spelt slightly different between users and even for same user, which can easily create multiply folders containing similar or even duplicated documents for the same Account. The obvious question is, how complicated was it for Microsoft to allow the user to select the field / attribute to be used as folder name. Most users will probably select Account Number or Invoice ID as preferred folder description.
3. Account or Contact Centric folder structure is only available for accounts and contacts. What if I wish to store in SharePoint documents related to projects in a Project Centric folder structure? The ability to select any entity as the parent folder for documents stored in any entity linked to the selected folder in 1:N relationship is an option in Dynamics SharePoint Organizer (SPO), not implemented in CRM integration with SharePoint.
In this article we described the inherent issues and limitations of CRM integration with SharePoint.
Follow us for next article:
“Organizing Dynamics CRM Documents in SharePoint”
Click here to download Dynamics SharePoint organizer (SPO), trial version