Salesforce and Sharepoint Integration Overview and Best Practices

When I saw headlines not long ago about Salesforce and Sharepoint integration, I was ecstatic, and immediately carved out a spot to talk about it here. The possibility of integrating powerful CRM like Salesforce to the largest paid-use cloud/network document cooperation and sharing framework is absolutely fantastic. Imagine the power of distributing reports out of Salesforce across SharePoint, in formats that can, from there, be imported directly into Office or other ODBC-ready document and business software for editing and redistribution for company-wide use. Imagine the convenience of someone from another department who needs a memo or cover document attached to a customer profile on Salesforce so easily transmitting the data right in without needing the CRM people to transfer it manually. Imagine my disappointment. Just a Beta: Classic excitement before reading very far is the culprit here. In the past, there have been many attempts by third party sources to design WPF applications for the Office side, and Salesforce apps on the CRM side, that can both open a tunnel into the SharePoint framework and do this. There hasn’t been much success there, and we’d all resolved ourselves to waiting for Salesforce or Microsoft to step up and make this possible themselves. What were we thinking even expecting this? Microsoft sees Force.com as competition plain and simple. With their own CRM suite, Dynamics CRM, poised to probably give Force.com a run for their money in the coming period, they really stand to gain less from making SharePoint play nice than they do from refraining from giving Salesforce the competitive edge that would provide. But oh boy, this hasn’t stopped Force.com from trying! Currently there does exist a more or less closed beta of an Apex-based SharePoint integration module. However, given it’s an early beta and not easily gotten ahold of, I can’t attest to how well it works from experience. Along with this, if forums are any indication (and they usually are), a lot of people can’t get the early prototype to work. Will Force.com manage to fix this? Almost certainly, but not today or tomorrow. The problem is that, given MS doesn’t really want to befriend the Salesforce people, they’re not making it easy for third party systems (not using their dotnet platform) to talk to their stuff. So, it’s a lot of work to get “unsigned” routines from other sources, even in a VM environment like web, to actually work. A Light in the Tunnel: I want to close with a little bit of good news that may be the unexpected harbinger of future wonderful news. Those intrepid developers on the Salesforce App Exchange have designed a tool which is designed as a general data processing integration module. A skeleton key, if you will. This tool, called Relational Junction, was developed by Sesame Software, more to be an ODBC work around for the stranger database types (PostgreSQL, DB2, and Informix for example). But, this dynamic linkage system can be made to allow limited connectivity with SharePoint. It seems to only be bare bones, and mostly about data and none of the higher document functionalities, though. However, the fact that they have managed to get Apex to talk to Microsoft’s API at all is a huge advance and so, this will undoubtedly become the Salesforce and Sharepoint integration solution that we lack now. I encourage supporting Sesame in their efforts, and making avail of the limited connectivity Relational Junction can already provide. It’s still very useful. Read more about salesforce sharepoint integration for more information.