Much has been written over the past two days on the Salesforce.com | Google partnership, and as the dust is settling down, it’s time for me to share my first impressions as a user of this pretty cool mashup. Yesterday, Marc Benioff asked me if it made Salesforce.com Office 2.0 worthy, and my reply was a resounding “Yes”. In pure Salesforce.com style, reality does not fully match the marketing hype surrounding the announcement, but this first release is real, works, and is the very best Office 2.0 integration I have seen in a long time. So let’s take a closer look.

What Salesforce.com and Google released last Monday is a collection of lightweight mashups between the Salesforce.com platform and Google Apps. 5 have been developed by Salesforce.com, 1 by Salesforce Labs, and 7 by partners, 4 of which come from Appirio, 2 from Astadia, and one from Sxip Identity. In this first article, I will focus on the ones coming directly from Salesforce.com. Future articles might cover the other ones in more details, even though I tend to prefer native Salesforce.com applications for anything core to the platform.

The most important component is the integration with Google Docs. This mashup adds an “Add Google Doc” button next to the “New Note”, “Attach File”, and “View All” buttons that you can add to most objects. This new button lets one create a new Document, Spreadsheet, or Presentation directly from Salesforce.com, as well as link to an existing one. When creating a new document — be it a Document, Spreadsheet, or Presentation — a window pops up and displays the familiar Google Apps editor. Some people might have preferred an embedded frame though, and I expect this option to become available in the future. When linking to an existing document, the user is asked to enter both the document’s name and URL, which quite frankly is a little bit disappointing (I have created a similar mashup on my own months ago), and creates unnecessary steps in one’s workflow. Instead, I would have liked to see a new window pop up that would allow me to browse through my set of existing documents, then select the one to be linked to. This would be a lot easier to use, a lot faster, and a lot safer (no meta-data duplication).

Another problem with the mashup is that documents created with Google Docs cannot be used directly with EchoSign, while Jason Lemkin (EchoSign’s CEO) assured me that it was supposed to work out of the box. Apparently, EchoSign and Salesforce.com are diligently working to resolve the issue. When they do, this will demonstrate the full power of mashups, where 1 + 1 + 1 equals a lot more than 3.

Yet another limitation is the lack of support for document merge, and this is where I would expect a lot of engineering work to be put down the road. Ideally, one should be able to develop document templates using Google Docs, and to merge them with Salesforce.com records (Contacts for example) in order to do things like sending invoices or managing direct mailing campaigns. Currently, such a functionality is offered by Conga Merge on the AppExchange, but requires the use of Microsoft Office, which is not exactly Office 2.0 compliant. Request to Google: please make sure that the Google Apps API supports this integration scenario as soon as possible. Note to Salesforce.com: you really, really need this feature if you want to credibly backup the claim that Salesforce.com + Google can best the Microsoft CRM + Microsoft Office combination.

The second most important component is the integration with Gmail. A couple of weeks ago, I presented a very simple integration scenario allowing one to display all emails exhanged over Gmail with a contact stored in Salesforce.com. What Salesforce.com did is the reverse scenario, which allows one to send an email through Gmail, and get the email recorded as an activity into Salesforce.com. This scenario is supported by the use of a user-specific email address managed by Salesforce.com and added to the list of BCC recipients. What I find interesting with this mashup is that it was implemented in a Gmail-agnostic fashion through was is called “Email to Salesforce”, allowing other mashups to be developed the same way. Also, when combined with the newly-released “Email Services” using Apex classes that implement the Messaging.InboundEmailHandler interface, it should support the development of very cool email-driven workflow scenarios. I have yet to make it work for a real-world application, but it’s definitely one of the most interesting recent developments of the platform. For the Gmail integration to work, just make sure to uncheck the “Advanced Email Security Settings” option that is found in the “Email to Salesforce” administration panel. Many thanks to my friend Philippe (aka Supa-Coola-French-Dude) for helping me figure this out!

When using both integration components (the one from Salesforce.com and my widget), one gets pretty much everything one really needs to get the two work in harmony. My only complaint might be that the Gmail logo that is displayed next to the Gmail link is way too visible. In fact, it’s grabbing one’s attention so much that I’m considering installing Grease Monkey just to get rid of it, even though such a move would break one of the most sacred rules for Office 2.0 (no browser extensions).

The other three components developed by Salesforce.com are a Google Docs Tab, which is mainly using an iFrame to show Google Apps within Salesforce.com, a Google Talk sidebar component, which I will not use for I consider Instant Messaging to be way too disruptive on a daily basis, and a Gmail to Salesforce Browser Button for Firefox, which I cannot use for it would break yet another rule for Office 2.0. So, when you look at it this way, what was released is not a lot more than lightweight mashups that could have been developed by pretty much anyone. But this realization should not underplay the significance of the partnership, for the following reasons:

1. A relationship has been established, and more should come out of it.
2. The selection of an Office 2.0 partner makes it easier to build new mashups.
3. The partnership made single sign on work, which is a major usability improvement.
4. The integration was available, for free, on the date it was announced.
5. Salesforce.com prominently featured partner solutions.

This last point is quite important actually. Appirio, Astadia, and Sxip Identity are trailblazers when it comes to making Office 2.0 really work for organizations trying to use Salesforce.com as a platform rather than just a CRM tool, and for Salesforce.com to support them so prominently directly within the application itself (in the Google Apps Settings panel) is no small endorsement. Among the components offered by these premium partners, the two that I like the most are Appirio Search for Google Docs and Appirio Sync for Google Calendar. Nevertheless, they both have limitations that might prevent their widespread adoption.

Regarding Appirio Search for Google Docs, the main problem comes from the multiplication of places where documents can be stored into Salesforce.com. As of today, I can think of four main places: old-school document attachments to objects using the standard “Attach File” button, documents stored into Salesforce.com Content (formerly known as Koral), documents stored into Google Docs, and documents stored into Amazon S3 using Appirio Cloud Storage for salesforce.com, the later being a low cost alternative to Salesforce.com’s own document management application (Content). This situation creates many problems, from confusing users, to making it harder for documents to be shared with others, to making it close to impossible to search through one’s document database. In such a context, my recommendations are the following:

1. Provide a free entry-level version of Salesforce.com Content.
2. Merge the “Attach File” button into Salesforce.com Content.
3. Reduce pricing for additional gigabytes on Salesforce.com Content by 10x.

Regarding Appirio Sync for Google Calendar, the main need (I believe) is not so much synchronization with another calendaring application, but synchronization with one’s mobile device (Apple iPhone in my case), and Google Calendar is not of much help there. For this, I expect the upcoming integration with Apple iTunes to be the way to go, and it will ship sometime in June. Also, one important thing to consider is that Salesforce.com’s calendar becomes truly useful when events can be linked to other objects, such as Opportunities or Projects (a custom object one can easily create). But what this means is that integration with a mobile device will work only with a custom application, either built natively like the one for Apple iTunes, or served through a mobile web browser like the one I built recently. Otherwise, when synchronizing Salesforce.com’s calendar with a third-party calendaring application, such as Google Calendar or Apple iCal, a lot of the useful meta-data gets simply lost.

Another integration Salesforce.com could have made with Google Calendar is for the publishing of free/busy calendars, like the one I released yesterday. All it took is less than a hundred lines of PHP code, and I already saved a fair amount of time trying to get meetings scheduled just after two days of using it. Once this is done, the next step will be to provide some integration with a good meeting scheduling service, and the most promising I have seen so far is Eric Ly’s Presdo. Once it supports the consumption of ICAL feeds and provides a REST-like API, I will build a simple mashup for it.

Then, there are many powerful integration scenarios that can be envisioned between Salesforce.com and Google Spreadsheets. The most obvious one is the export of reports to Google Spreadsheets (currently, only .csv and .xls formats are supported). Another interesting one would be the use of the Google Docs form gadget to allow new instances of standard and custom objects managed by Salesforce.com to be created from any public web page, without having to write any custom code for it. Yet another would be the use of Google Spreadsheets’ chart builder to create custom charts for Salesforce.com Dashboards (charts in Salesforce.com are utterly ugly). And I could go on and on… While supporting document merge with Google Docs should be the very first step, the next ten ones should be related to Google Spreadsheets, for Salesforce.com is mostly about structured data (so far), and a spreadsheet is the most appropriate metaphor for dealing with it (as most power users of Microsoft Excel will tell you).

Finally, some integration scenarios going beyond Google Apps should be considered as well. The first that comes to mind is integration with the Google App Engine, for which I received an invitation today (thank you Bill and Laurent). The rationale for it is the following: while APEX is natively bound to the Salesforce.com platform, which makes for high performance and a fair level of security, it’s a proprietary language that very few developers will want to learn (it has an addressable market of about a million end-users so far, which is not a lot compared to Microsoft Office’s 500 millions users), and for which very few libraries will ever be released. It also creates a level of locking into the Salesforce.com platform that many developers and independent software vendors will never be fully comfortable with. Using the Google App Engine, which is implemented around the standard Python programming language, would be a good way to edge one’s bets, and leverage a massive amount of good quality code already available. All it will take is a good binding to the Salesforce.com platform, and I doubt that it will take very long to get (release 0.93 of this API is already available).

So, here we are, Salesforce.com and Google made a great first step together, and I expect many more to be made in the future. Congratulations to their respective teams for this great piece of work! Most importantly, the direction has been set, and it’s really up to us mashup developers to show what can be done with Office 2.0, and build our dream extreme productivity setups with these really cool applications.

This is just too much fun…