I came across two CRM/SharePoint integration projects this year which unfortunately couldn’t be implemented using the out of the box integration components. In this post I am going to provide a quick guide on how to implement a custom solution, along with two scenarios.

Mapping CRM Entities to SharePoint Containers

The first thing we need to consider is what kind of container will each CRM entity point to; Site Collection, Site, Library, Folder, Document Set? Moreover, how will containers for related entities going to be provisioned (e.g. subfolder in another folder)?

“Talking” to SharePoint

There are a couple of techniques you can get SharePoint to provision those containers for you. Here are a couple of examples:

  • WebDAV: Commands over HTTP Protocol. This will allow you to create and delete folders in addition to upload documents and set metadata. The protocol is quite straight forward but a bit difficult to implement. The nice thing about it is that you don’t need to deploy anything to your SharePoint farm/site and you only need to point it to the target document library URL.
  • FrontPage RPC: Everyone dreads the name FrontPage but this is a protocol similar to WebDAV with an added complexion. Once again it is an HTTP based protocol and it needs pointing to the SharePoint Web URL, to a _vti_bin file. There are quite a few libraries out there that can provide this functionality and you can read a bit more about the protocol if you search for “FrontPage RPC” in my blog. There are no server-side dependencies for this functionality and it can be used to create sites, document libraries and folders, in addition to upload documents.
  • Out of the box Web Services: The web services are a nice alternative, my only concern is the need for the document library IDs etc. which increases the amount of known data needed from SharePoint.
  • Custom Web Service: You can always implement a custom service to provision the containers.

End User experience in CRM

Provisioning Document Locations

In both implementations so far, CRM 2011 was extended by adding a ribbon button on each entity that would create the document location with the help of some JavaScript and one of the endpoints mentioned above. An alternative would be to create the document location automatically in a plug-in or workflow to automate it.

Displaying Document Locations

  CRM 2011 provides a special record type: “Document Location” that is related to an entity and has a URL value. If a Document Location record is associated to the currently open record, the “Documents” link under “Related” on the left hand navigation will display the URL in an iFrame.

  Suppose you are too precious of your SharePoint site design and you would like to give the user a full window, you can always hide the link and add another ribbon button to open the URL in a new window.

Two Unique Implementation Examples

The first project consisted of one CRM organisation and two separate site collections. The obvious problem with the out of the box integration is the fact that it can only work with one document library and site.  In this scenario, a ribbon button was added to each entity which upon clicking would and establish all (relevant) relationships and ensure the parents had a folder created before it provisioned one. Moreover, the user is prompted to select one of the two sites where they would like to create the document area.

The solution included a JavaScript based WebDAV client that could create folders and locate existing ones. There are a couple of JavaScript based WebDAV clients out there but they felt either over engineered or too expensive and that is why I decided to create a basic one with support for MKCOL and PROPFIND methods only. There are a couple of issues with this implementation as you will need to make sure both CRM and SharePoint sites are in the Local Intranet Zone in order to avoid the IE XSS filter and allow for windows credential reuse in case you are not using an SSO (UAG will fix it).

The URLs to the two document libraries were stored in custom settings records as the out of the box configuration only allows for one URL which would like to validate before storing it by trying to contact the deployed SharePoint integration component. ODATA was used to retrieve the custom settings record values.

The second project was for our own Extranet where we provision a site for each logical entity in our IA; Partner Sites containing Customer sites that contain all projects relevant to that customer. Each site type has its own site definition and groups (such as consultants group).

Site creation in this example is based on a long running operation that takes two parameters; the CRM entity ID and CRM entity logical name. The long running operation page is displayed as a popup when a user presses the “Create Site” button on the CRM entity ribbon. The code then establishes what kind of record it is, what the hierarchy is and provisions the relevant sites. Communication with CRM is established via the Organisation service directly from within the long running operation.

Moreover, the consultants group membership is linked to the associated team in the CRM entity. Adding or removing people from the record ensures the changes are reflected on the site security. This was achieved using a CRM plugin and a custom web service.

In the extranet example I decided to store the site’s ID instead of the URL. This was to prevent issues where the site has been moved or renamed. When a user presses a second ribbon button “(“Open Site”) they are pointed to an HTTP Handler that converts the Web ID to the full URL and redirects the browser to that location.

All the above custom solutions should still apply to SharePoint 2013 although I have to admit I haven’t tested those yet.