CRM 2011 and SharePoint 2010 integration

The out of the box integration between CRM 2011 and SharePoint 2010 / 2013 is one of those features that has a lot of potential, but it doesn’t fully deliver. It feels like a feature that is on the checklist of every prospective Dynamics CRM customer and so something minimal was thrown in by Microsoft to satisfy marketing needs.

“Hey look, we have CRM 2011 and SharePoint 2010 integration, out of the box!”

Well yes you do, but it’s a bit limited. The functionality it provides is:

• From the CRM user interface a user can create a folder in a SharePoint document library on demand, on a per record basis.
• SharePoint is iFramed into the CRM user interface in a neat way that simulates the look and feel of CRM 2011. An important part of this is it strips away all the normal page navigation and chrome and just shows the documents in that folder.
• The name of the folder is the name of the record at the point in time of creation – if the record gets renamed, the SharePoint string remains the same. This may be confusing – particularly if your user found the SharePoint based content through a different means, such as Enterprise Search.
• CRM can be configured to have one or more document libraries per record. So in theory you could have two document libraries configured for one entity and provide different security or content types. It would be a clunky user experience though.



Things that I’ve found are commonly requested features in this area of functionality that are not part of the out of the box experience:

• Common (or at least synchronised) security settings
• Use of content types – and possibly different content types per entity type
• Control over what gets created in SharePoint – i.e. using Document Libraries instead of a folder
• Scalability issues – using different Site Collections depending on the number of sites already created
• Control over how the SharePoint location is named – e.g. using a Customer ID for the URL and / or Title.
• Creating the SharePoint location programmatically instead of ‘on-demand’ through a UI interaction. For example, you could be creating a record via a web service call and also want to save content in the associated SharePoint location.



This blog post provides a great walkthrough of how you would go about developing a CRM plugin that takes care of the creation of the SharePoint content. It is a great starting point if you want to customise what happens. In a nutshell it still relies on the SharePoint destination still having the CRM List Component installed so that the UI for SharePoint is styled correctly, but it takes control of the SharePoint creation side of things through a server side event in a CRM Plugin. This means that you can control what, where and when things happen in SharePoint. But you get the benefit of the native display of SharePoint content in the CRM without having to come up with your own SharePoint iFrame friendly view.

I would probably take the SharePoint creation logic out of the Plugin and put it into a callable web service, but you’d still have to call this from the Plugin. Within this web service you could then examine the existing number of folders / libraries / sites you’ve decided to create and determine if your container is reaching it’s limits and you need a new container, and also the web service could potentially be called from other systems.

But if you’re looking to enhance the integration between Dynamics CRM 2011 and SharePoint 2010 / 2013 then that blog post is definitely a great starting point for your development team to get their head around.