Salesforce.com and POP/IMAP Email Sync - An Update

Recently I wrote about how Salesforce had decided to EOL support for POP/IMAP in it's Outlook Connector. Since that time, I spoke with my Salesforce account rep expressing outrage. If you're reading this, I hope that you have too. I'm still considering writing a similar 'outrage' email that I send to Marc Benioff.

In positive news, community specialist Kristie Garafola has updated the success.saleforce.com page on this issue. She is now asking for input as to what POP/IMAP platforms you are using.

Hi Everyone-  I’ve been speaking with our product team to get more information for you and have a few questions.  Can you see below and let me know your thoughts?

IMAP and POP3 are communication protocols to access email servers. What we need to know to address the request is what are the email servers you are connecting to (through IMAP and POP3) when downloading your email? If it's not an Exchange Server, is it mostly Gmail? What about other email services? Understanding what email servers you’re connecting to and their popularity will help us prioritize our focus beyond Exchange.

For those currently using Apple Mail on Mac to connect to an Exchange server, you may use our Exchange Sync model and get calendar events and contacts syncing. With Exchange Sync, it does not matter whether the user is on a Windows machine or a Mac, and which email application is in use, as long as the back-end email server is Exchange 2010 or 2013.

As for the Salesforce App for Outlook, it will work in OWA on a Mac when using a browser, and eventually on Outlook for Mac when downloading it from Office 365 (i.e. only the newest version).

We can evaluate bringing support for IMAP and POP3 with SFO, or even better, explore the possibility of porting Exchange Sync-type capabilities to sync contacts and calendar events with Gmail. Once I have more information on that, I will post again.

There's more, but I didn't want to grab the whole thing. On the upside, what I take from this is that the outrage is being discussed. I don't think that they're in full-on head-slap mode, but I think that they know that there are a bunch of people who are pissed. At the same time, I'm not sure if it's enough outrage to actually spur action -- or simply one of those "oh yeah, we're listening" followed by nothing.

What I take from Kristie's post is that she's trying to get a grasp on an issue with outrage (Salesforce for Outrage?), but she does not seem particularly versed in the technology of email. Her post reads sort of like somebody who stepped into a quagmire of crap, then discussed the issue with the product team and they responded with something like "fine. which way should we through the rope to pull you out..." followed by more frantic sinking.

There are really a couple of issues here:
First and foremost: Salesforce.com's solution for handling email integration and syncing SUCKS! For years, they have provided support for Outlook integration (early on, it was seemed like it was important to them, but the first step down the FAIL path started with Salesforce for Outlook). When they partnered with Google to do Google Apps integration, they could have implemented a Gmail integration at that point -- or shortly thereafter -- but they didn't. As for Mac email support, probably the best tool was always the MailDrop app developed by a guy who thought it would be useful -- but never adopted by Salesforce. And he's quit supporting MailDrop. Bottom line = Email Sync is really an afterthought.

Second: Kristie's post gets a little muddled in dealing with the difference between clients and server sorts of issues. Put simply, the client is the thing that lives on your computer, the server is the email system that lives in a data center or in the cloud somewhere. It's the place that collects your email when you're not connected.

Connect for Salesforce was client-side add-on. It was designed so that a Sales guy could install it on their system and sync their emails to Salesforce. MailDrop and most other email sync tools are client-side add-ons. A server-side sync tool would require that your IT team install something on their overall email system. Most IT teams hate doing this because the software (e.g. Exchange) that runs email is finicky and a bit of a pain in the ass to run. Between SPAM, hacking and other mysterious issues, the server side of email is sort of like the Devil's Triangle of IT -- beautiful when the weather is nice, but subject to spontaneous bouts bad.

Salesforce for Outlook claimed to be a server-side sync tool, but the reality was that, while there were server-side permissions, it is still a client-side add-on. In it's early days, essentially what Salesforce for Outlook would do is sit on your system and, when you flagged something to sync to Salesforce, use the same basic approach as Email to Salesforce (where you simply BCC your email to Salesforce). That's why it worked with POP and IMAP even though it wasn't "supported".

This confusion between client-side and server-side makes sorting through solutions and planning an updated roadmap even more challenging. While Exchange is popular, we use Google Apps and Gmail, but there are others beyond that. From open source solutions to old systems or perhaps even for IT teams that just don't want to use Microsoft or Google, the back-end of email could be in place for a variety of reasons. For users on these systems, POP/IMAP typically provides the bridge to the client. Imagining a server side component to fit this landscape is like trying to imagine a single tire that fits every car. 

Back on the client side, there are wide array of options as well. On the PC side, one of the things that made Outlook such an attractive option for a Salesforce sync client is that Microsoft bundled it with their Office suite, so virtually everyone using the Office suite could potentially be supported. Are there other email clients? Sure, but building for Outlook probably touched the broadest user base.

Meanwhile, in the Mac world, there are different options. For a long time, people in the business world took the approach that the Mac didn't exist. Over the years, that landscape has been shifting significantly. While it might have been "tolerable" for Salesforce to ignore the Mac back in 2005, the times have changed. On the Mac platform, the Apple Email client is probably the default standard, but there are many email client options out there. For Apple users in the Microsoft realm, Microsoft used to sell their client as "Entourage" because it wasn't exactly compatible with the Outlook/Exchange environment. In recent years, they changed the label to Outlook, even though the Mac and PC versions are sometimes not equivalent. Historically, most Mac users connect to their email system using POP/IMAP, because most server side email systems don't support a proprietary Mac connection.

Google's Gmail lives in it's own special category. The server side of Gmail is managed by Google and the native email client is actually a web browser. Most business users would access Gmail through Google Apps which provides some administration tools and potential extensions or plug-ins. Google also develops extensions for Gmail; some are supported in Google Apps, some are not. Many users also connect to server-side Gmail through POP/IMAP and run other clients like Outlook, the Apple email client and others. It's probably also worth noting that the Outlook-Exhange interaction is so important to some businesses that Google actually built an Exchange-protocol support for Gmail in order to streamline sales of Google Apps to businesses. In other words, you could be in a business, connecting to Gmail through Outlook where your Outlook thinks it's communicating to an Exchange server even though it's talking to Gmail. This is part of what makes the SFO-Exchange server validation so frustrating for some end-users -- Gmail can pretend to be Exchange enough to satisfy Outlook, but not enough to satisfy the new SFO.

My Ideal Salesforce Email Sync Roadmap
If I were defining the product roadmap for email sync in Salesforce.com, here's what I would do. First, I would eliminate the Exchange Server validation in Salesforce for Outlook. Put simply, if it used to work and now it doesn't, you broke it. POP/IMAP support in Outlook takes care of a huge chunk of legacy systems and users on the PC. I would also make an officially supported sync tool for Mac and the Apple Email client. It's overdue. This should address a broad cross-section of users out there. I would also partner with Google to offer a plug-in or extension for integrated sync from Gmail and Google Apps. An easy extension for syncing to Salesforce from Google Apps would be a big win for many in the SMB market. This initiative would say, once and for all, that Salesforce cares about email sync.

But my roadmap wouldn't stop there. There are some people that want to have a single integrated environment for eveything. If Salesforce added a browser-based email client -- ala the Gmail browser client -- they could pull emails into a window in Salesforce. For many users and administrators, the ability for users to manage their email from within Salesforce would bring a significant bump in adoption. Imagine if Email was a tab.

Anyway, that's how I'd set the table. What I actually expect to happen is some lip service to this issue, promises of future improvements, but no action. When you look across their existing "partner" landscape, there's a lot of money changing hands in email sync. Unlike the old days when platform providers like Microsoft, Apple, Facebook and Twitter saw something that looked like a cool extension of their functionality and, essentially, brought it in house, Salesforce has shown that their strategy over time is, if there is something developed by Salesforce Labs or some cool functionality that is convenient to bake in -- if somebody is willing to pay another $15-however much more per user for that feature, monetize it. If they don't support it and you have to pay an additional cost, oh well. Remember, your success is what's important to them.