CRM 2011 Integration with SharePoint: Taking a Deeper Look

One of the best new additions to CRM 2011 is tight integration with SharePoint 2010 for storing documents.  In the past when using v3 or v4, CRM Projects have been forced to develop custom code to integrate CRM with SharePoint, but now the standard CRM functionality allows the two products to be integrated and easily configured in the CRM 2011 settings area.

Following the CTP and release of 2011 at the beginning of this year, many great articles have been written and posted on the web to provide step-by-step guides for connecting CRM to SharePoint using this functionality:

http://blogs.msdn.com/b/crm/archive/2010/10/08/crm-with-sharepoint-integration-introduction.aspx

http://blog.pointbeyond.com/2011/04/30/integrating-sharepoint-2010-with-crm-2011-for-document-storage/

However as with many areas of ‘out-of-the-box’ functionality the default integration is limited in certain ways.  This article aims to take a deeper look at this integration between CRM 2011 and SharePoint to examine how the integration works ‘under the hood’; with the aim of understanding how CRM 2011 has implemented this integration and how it could be extended further to meet the requirements of more complex Document Management scenarios.

The Standard CRM and SharePoint Document Integration

By default whenever CRM 2011 has been correctly configured to work with SharePoint 2010, an admin user will be able select which CRM Entities should have SharePoint document areas:

image

Configuring Document Management Settings in CRM 2011 by selecting which entities should have a Document Library Folder

Selecting these entities will then have the effect of creating a SharePoint Document Library for each entity:

image

Completing the configuration of Document Management in CRM

image

The resulting Document Libraries creating in SharePoint as a result of configuring CRM 2011's Document Management settings.

Within CRM this will also create a reference in the CRM Database’s Share Point Site table to record that this SharePoint Site will be used for document management – essentially storing the details required to link CRM and SharePoint in this record for reference.  We can see this record via a simple Advanced Find in CRM on the ‘SharePoint Sites’ entity:

image

Running an Advanced Find in CRM for the 'SharePoint Sites' entity to return a single record detailing the settings configured for Document Management with SharePoint

To fully understand how this is connecting the two systems, it can be useful to look at how CRM has populated the fields for this record as the placeholder that CRM has created to act as a pointer to SharePoint:

image

We can also open this record in a similar fashion to any other CRM record:

image

Opening the SharePoint Site record in CRM

With this in place, we can now browse to any valid CRM Record for the entities selected for Document Management and click ‘Documents’ to begin creating or uploading documents against that record.

image

Accessing the Documents area for a CRM Record which does not have an associated SharePoint Document Location record - prompting CRM to offer the option of creating a new folder in SharePoint.

This prompts CRM to create a new SharePoint Folder in the Document Library for the entity type of the record – typically the Account entity in many business cases.

image

The resulting folder for the CRM Account Record created in the 'account' Document Library in SharePoint

With this folder being directly accessible from within CRM via the SharePoint List Component:

image

The Documents area in CRM showing the Documents contained in SharePoint for the highlighted 'Documents on Default Site 1' SharePoint Document Location record.

Behind the scenes here CRM has taken the step of invoking SharePoint to create a new folder for the Account record and adding a reference in the CRM Database to link the Account record to this particular SharePoint Document Location.

Again we can view this reference record in the CRM Database via a simple Advanced Find, this time on the ‘SharePoint Document Locations’ entity in CRM’:

image

Running an Advanced Find in CRM against the 'SharePoint Document Locations' entity

This list of Document Locations shows the references that CRM has created to external SharePoint Locations for storing documents.  In this case, a reference to declare that documents for the ‘Account’ entity will be stored at the relative URL for ‘account’ and a second reference to declare that documents for the ‘CRM Consultancy’ Account record will be stored at the relative URL for ‘CRM Consultancy’. 

As this 2nd reference has a parent link to the 1st, this makes the relative URL ‘account\CRM Consultancy’ – and in turn, the 1st Document Location is linked back to the earlier SharePoint Site record and as such the URL is determined as:

[Site Absolute URL] –> [Location 1 Relative URL] –> [Location 2 Relative URL]

In this case ‘http://mySharePointServer/mySite/account/CRM Consultancy’.

We can look at this as a simple ERD Diagram to show the relationships between the entities in CRM and SharePoint:

Document Management ERD between CRM and SharePoint

Entity Relationship Diagram to show the connection between CRM and SharePoint via the SharePoint Site and SharePoint Document Management Entities

Opening the child Document Location record, we can see these links in a similar fashion to any other Parent/Child Lookup relationship in CRM:

image

Opening the SharePoint Document Location record that links an Account to a folder in SharePoint inside CRM.

Looking at the fields for the SharePoint Document Location entity, we can see that these are very similar to the SharePoint Site entity – particularly when thinking of the AbsoluteUrl/RelativeUrl fields.

image

This series of Site/Location records informs CRM where to look in SharePoint when showing the list of Documents for a record, building a URL from the various levels of relative URLs involved back to the root absolute URL.  This is best expressed by the following Record Relationship Diagram that shows how this functions for an Account in CRM:

CRM - SharePoint Record Relationship Diagram I

Record Relationship Diagram to show how the SharePoint Document Location records associate the Account in CRM to a specific folder within SharePoint

This basic structure of Document Management allows a CRM Users to add new Document Areas for an Account and record Account-based documents directly through CRM.

Folder Structure Entity

The structure above can be extended via the Document Management configuration in CRM to allow for sub-folders from the initial Account folder down to sub-entities such as Contact.  This enables documents to be stored in a nested structure to allow CRM Users to store documents against a Contact or other entity which is in turn linked back to the ‘header’ Account.

Therefore the Record Relationship Diagram would be extended to:

CRM - SharePoint Record Relationship Diagram II

Record Relationship Diagram to show how CRM tracks a variety of SharePoint Document Location records to associate the connected Account and Contact to different linked areas within SharePoint

In this example, the Contact entity could be any entity in CRM that is related to the root Account entity – so we could have additional folders for Opportunity, Order or Case for example.

This extended structure stems from the ‘Folder Structure Entity’ field of the SharePoint Site record, this field can be set to either None, Account or Contact to specify the top-level entity for managing documents.

This defines more complex nested sets of Document Location records in CRM:

[Site Absolute URL] –> [Location 1 Relative URL for Folder Structure Entity] –> [Location 2 Relative URL for Record] –> [Location 3 Relative URL for Sub-Entity] –> [Location 4 Relative URL for Related Record]

image

Looking at the list of SharePoint Document Location records for tracking locations for a Contact attached to a Account when the Account entity is acting as the Folder Structure Entity

This allows CRM to cater for business models where the top-level Customer may be an Account (for business-to-business) or Contact (for business-to-consumer) in a similar fashion to how CRM allows Opportunities or Orders to be linked to either an Account or Contact. 

However by default this is restricted to Accounts and Contacts, we could not have a custom entity or other system entity acting as the Folder Structure Entity – however this does show the flexibilty that Microsoft have built into the concept of Sites and Document Locations.

Conclusion

The crucial understanding here is that this structure of a Document Library per Entity Type with Folder per Entity Record is simply the default business logic provided by CRM 2011 – and is in no way set in stone as the functionality provided by the SharePoint Site and Document Location entities in CRM can easily be extended to provide bespoke business logic for tracking documents.

As with many areas of Dynamics CRM, the application here provides a platform of functionality that can either be used in it’s default configuration or be extended via custom development.

In terms of why we may want to do this, when we look at the standard SharePoint integration here we can see some limitations for Document Management:

  • a single Document Library is storing all the CRM Documents, this could result in a single huge Document Library when it may be better to spread out the documents across multiple document libraries.
  • the Document Structure is heavily dependent on nested folders, this can often create a confusing layout for storing documents; and long-time SharePoint experts generally shy away from heavy use of folders for creating good Document Management governance. (SharePoint Document Libraries and Horrors)
  • Without customising the Document Library in SharePoint, the Document Structure does not make use of SharePoint Views or Metadata for managing documents.

The next post in this series will attempt to show how we can incorporate these concepts into CRM using custom development that uses and builds on these concepts to provide a custom model for managing documents between CRM and SharePoint.

Advertisements
This entry was posted in CRM 2011, Customisation, MSCRM, SharePoint and tagged , , , . Bookmark the permalink.

22 Responses to CRM 2011 Integration with SharePoint: Taking a Deeper Look

  1. Pingback: CRM 2011 Integration with SharePoint: Taking a Deeper Look … | Mastering Sharepoint

  2. That’s a very informative post, you cleared out some doubts I had. Thanks

  3. Great article on a very similar vein, clearly a bit more forward-thinking then me as this dates back to the early days of the 2011 CTP: http://www.develop1.net/public/post/CRM-2011-Document-Management.aspx

  4. Prashant RautPrashant says:

    That was very good article, only missed is security bit, can you please highlight how security works for both, does every user need an access to document library on sharepoint or can i use secure store like feature in CRM?

  5. Hi,
    Great Post! However I am having a question. How is it possible to pass data from CRM to Sharepoint Document library when we press ADD NEW DOCUMENT?

    I am looking for a way to pass Mobile number of my contact to Sharepoint Add New Document page. How is this possible?
    Your help is really appreciated.

    • Unfortunately the ‘Add Document’ logic is hard-coded via the SharePoint List Component so, whilst you will see the list of Metadata fields in Office when adding the new document, you will not be able to insert rules for inserting CRM Fields into the Document Metadata fields automatically.

      However this would be possible via developing a new custom screen to upload the document – in this fashion you could control certain Metadata fields automatically populating from CRM fields.

      To do this you would need to develop a ASP.NET Application which would use the SharePoint Client Object Model to communicate to SharePoint, and then add a ISV.Config button into CRM that opens your new custom screen. Would be a tricky development but is quite do-able with a bit of time and effort, hope that helps.

      (you could also entertain another option to use SharePoint Workflow development to automatically pull details from CRM into a new document whenever a document is added or created within a certain SharePoint location – but imagine this would involve more complex development!)

  6. SIRISHA says:

    Hi,

    Great Post! I am having a question. How to pass CRM Data to sharepoint document library when we press ADD NEW DOCUMENT?

    I am looking for a way to pass Quote information to Sharepoint Add New Document page. How is this possible?

    Your help is really appreciated.

  7. Jandost says:

    I am having a very strange kind of error. I have made a new search page in Sharepoint called VLSearch.aspx (All search results from Sharepoint search are being redirected here). I also have implemented the document library to be accessible from CRM. Everything works perfectly fine; however when I search for documents from CRM, the search dialog box goes to infinite “SEARCHING…”. It never returns any result. I have no problem with any other functionality of Document list (I can easily edit/checkin and etc with files). Only search is showing me this result.

  8. Brian Bewley says:

    Thanks for the great post. One thing that has me puzzled is why there appears to be only one universal “default” document library setting even though you can have multiple sharepoint sites. It does not appear to be possible, for example, to have the nested folders for the Account entity created on one SharePoint site, and the Opportunities folder structure created on a different SharePoint site. What is the point of even having the ability to add multiple SharePoint sites if you can’t seperate by entity. Am I missing something?

    • Hi Brian, CRM 2011 has this idea of a ‘default’ SharePoint Site but I think this is just a way of picking which SharePoint Site a new Document Location will be created in by default. You can declare multiple SharePoint Sites and have these displayed in the Document Locations drop-down within a record, allowing a user to pick which Document Location (and so which SharePoint Site) to view at a time.

      With this system of working, via the standard functionality you would not be able to have Account records storing documents in one SharePoint Site and Opportunity records storing documents in another SharePoint Site – however you could using a custom Plugin which would handle the creation of the SharePoint Document Locations as opposed to the using the standard ‘auto-to-default-site’ logic that ships as the normal CRM 2011 to SharePoint 2010 logic. The follow-up post on this blog gives an idea of how to do this via a single SharePoint Site and could be extended slightly to make different types of entity use different SharePoint Sites: https://crmconsultancy.wordpress.com/2011/10/27/crm-2011-integration-with-sharepoint-custom-document-management/

      Hope that helps, drop me a reply if I can help with using the SharePoint Site/Document Location side of CRM 2011.

  9. Christian Burke says:

    Terrific article. But, I am having a very simple breach of brain function. It seems like all the document management integration between SP and CRM is connected to the account or contact. Fair enough.

    In the Sales or Marketing sections of CRM, there is a Sales Literature document section. In the SP/CRM integration configuration utility, there is a reference to Sales Literature. I have posted a bunch of test files into Sales Literature vie SharePoint Workspace and/or SharePoint directly.

    The problem is that the integration utility being bound to an account or contact does not extend to the root, hence making the Sales Literature section use the connector. So, in CRM the Sales Literature section is blank.

    Is this a breach of my brain function or am I correct that anything outside an account or contact does not get the benefit of the SP/CRM integration?

    If I’m just being an idiot, can someone please explain?

    Much appreciated (in advance).

    • This might be a little late to be of use – but you can activate the standard CRM 2011/SP 2010 Integration for the Sales Literature entity. This acts outside of an Account or Contact to give you the following:

      (1) A new Document Library titled ‘Sales Literature’ will be created in your instance of SharePoint.
      (2) For each new piece of Sales Literature you create in CRM, a new Folder will be created in this Document Library to store the physical Document/PDF for the piece of Sales Literature.
      (3) The ability to view the folder of documents and upload/create new documents from the Sales Literature record in CRM

      This is effectively the same functionality that CRM 2011 offers for integrating CRM and SharePoint for other entities but can be used to store documents associated to a Sales Literature record – certainly is not perfect for all Sales Teams or Help Desks (how do we automatically email out the Sales Literature document to a client or track it’s usage for example) but gives a base for connecting the actual Sales Literature document to the record in CRM.

      As with all the SharePoint Integration with CRM 2011, this ability to create SP Folders for CRM Sales Literature records is open to development to expand this base functionality – options to develop a more specific ‘Upload Sales Literature’ or ‘Email Sales Literature’ could be added via bespoke development. Hope that gives some idea of how this works for Sales Literature and sorry for the slow reply!

  10. Fabien says:

    Very good article ! There’s one subject on which I cannot find documentation : is it possible to add new items in the “Actions” menu ? On the SharePoint side, I added a custom action on the list item menu and it does not appear on the CRM side. Do you know how I can customize the Actions menu ?
    Thanks for your answer,
    Fabien

  11. Pingback: CRM 2011 integration with SharePoint 2010 | SharePoint and CRM Revealed

  12. Ed Hanna says:

    Excellent Post, but I have an issue that is puzzling me and I maybe over thinking it but hope you could shed some light on this for me or at least point me in the right direction. I’m much more of a CRM Guy and not that familiar with SharePoint, but we have a SharePoint guy that is not that familiar with CRM(in lies the dilemma).

    How do we configure Sharepoint/CRM(both online) to work together around the 5000 item limitation if we have 10,000 accounts and we can’t trust that if we create multiple folders under each account that the user will not overload the default folder location. The suggestion solution here is that we should create multiple folder locations\Document Libraries per Account and create a few Libraries for each set of accounts like every 500 accounts or accounts per state, but that appears to be an ongoing maintenance nightmare as we have over 150,000 documents. Some have suggested to go to SharePoint on-premise but it’s not clear how that maintenance might change unless we change the 5,000 limit to something like 10,0000 or 20,000 but that appears to have it’s issues as well.

    If you could shed any light on how most people implement this I greatly appreciate it.

    • Hi there Ed,

      Is difficult to say for certain over email, but from the sounds of your scenario you may be best served by looking to create a Document Library per Account. An individual Document Library in SharePoint can hold a very large number of documents, and Microsoft prefer the Document Library/Metadata Approach rather than a folder-driven approach. (think you may have already seen this, but the following link could be helpful: http://technet.microsoft.com/en-us/library/cc262787.aspx)

      My next step in breaking down your scenario would be to try and divide your Accounts into different SharePoint Sites, so for example:

      – say you had 20,000 Accounts, all of whom needed document areas
      – if you had 10,000 Accounts who were Suppliers then I would have 1 SharePoint Site specifically for Suppliers hosting the 10,000 Document Libraries
      – if the other 10,000 Accounts were Clients, then I would have another SharePoint Site specifically for Clients hosting the other 10,000 Document Libraries

      If you had a mix of Account Types, this could then lead to a hierarchy of Sites that divide your volume of documents into a structure or governance that avoids hitting performance limits.

      Parent Site – Site by Account Type – Document Library per Account – Metadata for each Document

      At a glance, hope that might be some help.

      Kind Regards, Paul.

  13. Gil Zamora says:

    As such integration of SharePoint and CRM together will really ease the job of people upto some extent. This in turn makes it very easy to setup document management in CRM as well as user can create, upload, download, modify to the documents in SharePoint which was not possible before.

  14. Pingback: How does CRM 2011 and SharePoint integration work? | Dynamics CRM Guru

  15. Thanks for the most detailed deconstruction of the integration to date. We have been tinkering a ton with the location stuff and have been pretty successful. The next challenge we have is that we are trying to put the iFrame that appears when you navigate to documents on another form. We cannot find out how they create/call the UI component for the SharePoint list part. Any ideas of where to look?

  16. Pingback: Dynamics CRM & SharePoint Integration Overview - Microsoft Dynamics CRM Community

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s