Are you choosing the most efficient way for your SharePoint solutions? A look at CRM 4.0 and SharePoint.

Introduction

Now that SharePoint development becomes easier now the tools and MSDN documentation are up to date and available for everyone it seems that everyone is hammering away in SharePoint custom development. There are tons and tons of blogs explaining how to build your own functionality, custom workflows, forms, field controls and event-handlers. Which makes me wonder whether people are also considering other products of Microsoft stack to aid in there product development and reach their business goals. 

It seems that the complexity and extensibility of the SharePoint platform automatically justifies for developer code frenzy and resort to building custom applications or so called application templates on to SharePoint without considering for instance building MS CRM or CRM / WSS / SharePoint integrated solutions.

SharePoint and CRM 4.0

Now with coming CRM 4.0 with its new workflow and entity relationship features it becomes more attractive to build custom solutions in CRM. Especially for the applications that require complex workflows, entity ownership & sharing and relations between entities. What I have seen a lot of developers do with SharePoint is create applications on top of SharePoint and using the lists as an semi-related database. Create an set of event-handlers or workflow activities to set rights or ownership on items and for handling complex logic. Now this is not necessarily a bad way, but maybe it could have been done more efficient when using an product like CRM and integrating it with SharePoint or WSS.

Probably the best way to explain this is by having an example, the service request scenario:

A common requirement for a large intranet is to streamline and manage service requests coming from the users using the Intranet to support the Intranets governance model.

These service requests can vary from “I want to like to request an new project site” and ‘I want to report offensive or erroneous content” to simple ones like “I would like to retrieve a deleted document”.

When one has an large organization to support, the amount of daily service requests can become unmanageable without an proper service request process. Service requests need to be assigned to different people or teams and handled with a lot of user interaction.  In the past I have written elaborate custom functionality, complex workflows and endless forms to overcome this problem in SharePoint while nowadays this sort an similar functionality can easily be created in CRM. 

As an bonus CRM 4.0 provides out of the box functionality to create service requests, cases and find associated knowledge base items to handle the cases accordingly.

The only thing that needs to be written in order to integrate both parts is an web-part to publish the service request and track its status from CRM using CRM’s web-services.

By using this kind of integration you save a lot of development effort as oppose to building all functionality custom.

A couple of other exciting scenarios with CRM and SharePoint integration:

Governed project portal and site lifecycle management	Creating an project in CRM, which triggers the creation of an project site in a governed taxonomy in the SharePoint environment and notifies users that the site has been created. When the project site’s documents are all passed for review, SharePoint triggers an event in CRM which updates the CRM entity that the project is finished and backups the site accordingly.  Because the status of the site is tracked in CRM, the CRM reporting functionality can be used to generate reports. Additionally, the site’s lifecycle policy  can be monitored and endorsed from CRM.
Custom CRM based user authentication	Create an custom authentication provider for SharePoint that uses CRM as its back-end user-store to authenticate users. Providing functionality to manage SharePoint users for, for instance, an extranet, in CRM.
Employee time-off request application	Users can request time off by filling in an form on SharePoint with creates an request in CRM, which can then be handled by an manager accordingly.
Service request and incident management	Users can report incidents by filling in an form on SharePoint with creates entities in CRM with can be handled accordingly. Reporting can be done with SRS or from CRM.

When to choose what?

The most difficult question to answer is when to choose what development strategy when building this kind of business applications. There is no golden rule for as it largely depends on the situation and business need. To make matters worse both products tend to get more overlapping functionality.

For instance, you can store documents in CRM as attachments and without versioning, (of course it still doesn’t match SharePoint) and you can make your SharePoint applications look like CRM based applications such as presented in the “Microsoft 40 application templates” examples.

Apart from the obvious license and performance considerations there are some other facets one might consider.

Are you building an more database based application with complex workflows and relations between entities? Or more of an document or item repository with basic approval workflows? How big is the group of users that will use this application? When this functionality is build in CRM what impact will this have your CRM license model? Is it worth getting extra CRM CALs against building the application completely custom in SharePoint? What for an impact will building hybrid solutions have for your release management?

Probably the best way is to dive into both products and get a feel for them. Here are a couple of pointers to help you consider what development strategy to choose what when developing applications:

CRM only

• When building large complex workflow or process intensive back-end solutions, for a select group of users go for a CRM solution as CRM provides a lot of configuration, workflow flexibility and options like team sharing, user-assignment and queues already out of the box.  
• Furthermore, when you are basically creating an large application in SharePoint where the lists more or less start to look like relational databases an option might be to port it to CRM. Especially, when there is complex functionality like ownership of list-items and elaborate user permissions involved.

SharePoint only

• Document storage based application and collaboration based solutions
• Simple easy to develop workflows
• Applications with simple entity relations and entities with limited changing ownership.
• Large user base (for instance whole parts of the organization) that uses the application.

SharePoint and CRM hybrid applications

• Back-end is a relatively small selective group of users, logic is complex and results into elaborate tracking of tasks and items.
• Front-end need to be accessible by a large amount of users, everyone on the portal needs for instance be able to create new cases and entities in CRM using an created form.
• Monitoring, managing and reporting needs to be done centrally.

Notes on CRM and SharePoint integration

Please note that Microsoft has plans to integrate SharePoint and CRM in its upcoming office release.

Also be sure to understand when writing to the CRM data model in any way such as web-services is only allowed when you have the CRM External Connector license.