Salesforce just announced an update to AppExchange where they designate apps as “Aloha Apps”.  Aloha Apps are a new “all-you-can-app” category of apps that don’t count against customer org limits (apps/tabs/objects), no matter which salesforce.com edition you’re using.

A number of Arrowpointe applications are in the Aloha category.

• Arrowpointe Maps – map your Salesforce data!
• Auto vCard – Import a record (e.g. lead or contact) into your local address book with 1 click.
• Spam Check – Stop Spam from entering your Salesforce system and wasting your users’ time.

If you install any of the above apps, they will not count towards your app/object/tab limits:

In case you didn’t hear, Auto vCard 2.0 was released.  This is a major improvement to the app, allowing for total flexibilty and configurability in the creation of vCards from Salesforce data.  In fact, you can now create vCards from any object, pass any field through, use International characters and it all runs on the force.com platform!

To learn more…

• Auto vCard 2.0 Announcement
• Auto vCard on AppExchange
• Auto vCard Info on arrowpointe.com
• All Arrowpointe Products

The new Force.com Toolkit for Google Data APIs provides a free and open-source set of tools and services that developers can use to take advantage of Google Data APIs from within Force.com.

The end result for developers is a set of classes, written by Salesforce, that allow you to easily communicate with Google services.  For example, suppose you want to create an entry in Google Calendar, the following code does it.

GoogleData.Calendar cal = service.getCalendarByTitle('MyCalendar');
event newEvent = new Event(
subject = 'Tennis with Beth',
description = 'Meet for a quick lesson.',
ActivityDateTime = system.now(),
DurationInMinutes = 60);

That is actually just 2 lines of code (line #2 was broken into 5 lines for easier reading). The reason you can do this in 2 lines is because of the toolkit.  The toolkit does the “heavy lifting” for you to communicate with Google.

From a developer standpoint, the best thing about this is that, to do this, there is no dependency on changes to the Salesforce platform.  The Google Toolkit was created by the Developer Marketing Team at Salesforce, not the folks building the platform.  Apex Code is already part of the platform. The toolkit uses what Apex Code already offers.  What you get with the toolkit is a set of pre-written Apex classes that do the heavy lifting for you on talking to Google.  Much like the Salesforce Java/PHP/.NET/Ajax/Perl toolkits do the heavy lifting of talking to the SOAP API for you on those programming platforms.

There is no reason that the developer community cannot create similar toolkits.  I am sure Salesforce has some more up their sleeve and did the community a service by building some foundational ones for us to use as working/useful examples.

This is open source at work.  To make an analogy… one thing I love about PHP is that these types of toolkits are prevalent and have made my life much easier. For example, when I wanted to build Auto vCard, I Googled for PHP classes that created files in the vCard spec.  I found many and chose 1.  Similarly with the Web to Lead Spam Check I built.  I chose Akismet as the spam checking service because I was familiar with it and trusted it and I found a PHP5 toolkit that took care of the hard part of communicating with Akismet from PHP.  Same thing with my old Google Maps mashup. There are PHP classes that do the hard part of talking to Google Maps.  Having these classes at my disposal gave me the ability to focus on adding the business value of tying functionality into a Salesforce-related use case.  If these PHP classes didn’t already exist, I never would have created any those apps.

If you are a developer looking to create something similar to what Salesforce did, I suggest you:

• Visit Programmable Web to identify useful services that could be connected to and learn about their APIs
• Build your class(es) (Look at the XMLDom class that’s part of the Google toolkit to handle the complicated XML parsing you might need to do)
• Publish it open source and let the community react/improve it
• Offer up some example code for how the class can be used to help people implement a use case of it.
• Become a star

Some services that I think are ripe for developers to concentrate on (that are very applicable to businesses):

• Google Checkout
• PayPal
• Authorize.net
• Freshbooks
• Google (Apps) Mail
• Google Charts (with tie into Visual Force)
• Blog Services
• UPS
• FedEx
• Google Search
• Facebook
• LinkedIn
• Google Open Social

There are countless others.  Get cracking!

• Main Product Page
• Overview Video
• AppExchange Listing

I have been using Ribbit with Salesforce for ~3 weeks now and have been pleased. More important than anything for me was simply getting my voicemail digitally. Ribbit handles this for me. All I needed to do to activate it was call a special number on my cell, which sent AT&T a command to forward my voicemail to Ribbit (the Ribbit documentation says how to undo this change if you ever need to).

When someone leaves a voicemail, I can get it in a couple of ways:

Email

I opted to have Ribbit notify me of my new voicemails via Email. This way, I get an attachment with the file and can play it right on my Blackberry. The voicemail is also archived in my Google Apps account for reference purposes should I ever need it (even if I am no longer using Ribbit, I can still have that voicemail. It’s just a WAV file.). The downside of moving voicemail to Ribbit is that I no longer have visual notification that I have voicemail on my Blackberry. Getting it emailed to me eliminates the need for me to call in and check it. SMS is another option, but I wouldn’t be getting the file attached that way.

Salesforce

When I log into Salesforce, I see a nice message window on my homepage. All my voicemails are right there. The audio file itself is stored on Ribbit servers, but a record of the call is in a Messages object in Salesforce.com. This has call information as well as a text transcription. From the home page, I am able to tag my messages for easy searching later and I can also associate them to a Salesforce record. When I associate it to a Salesforce record, Ribbit creates an Activity with a link to the message file and a copy of the text transcription.

On the sidebar is a small message window and a dialpad. One of the biggest benefits of Ribbit is that of a “cell phone backup”. When a call comes to my cell and I send it to voicemail, the sidebar softphone rings. I have a chance to answer the call right from the Salesforce UI and talk through my PC. Alternatively, I can let it go through to voicemail. I am able to make outbound calls too, which is nice in the event that I don’t have cell coverage or just want click to call convenience.

Pros

The benefits are all about productivity:

• Digitize your voicemail – You have the data and can do with it what you please.
• Cell Phone Backup – Use the Ribbit softphone in Salesforce and put your cell phone away.
• Link voicemails to your Leads/Contacts – you get a nice record of the call with a text transcription
• Voice to text transcription is above average. It is by no means stellar, but it’s good enough to use as a reference for what the call was about without having to listen to it. Accents and slang tend to mess it up.

Cons

• Cost – If you compare the cost to Salesforce licenses, it ain’t cheap. $25/user/month. If you compare the cost to your cell phone bill and think of the added benefit you get, it starts to make sense. Individual purchasers will likely compare it to their cell phone bill and it’ll make sense for them. Enterprise purchasers will likely compare it to the cost of Salesforce and that will be a harder sell. If you want voice to text transcriptions (which are extremely useful), it’s even more money.  What’s harder to quantify is the productivity benefits you might get out of such an application.  Productivity improvements is an area of cost savings that should further justify the price.
• Can Slow page loads a bit – Even with the flash objects cached in my browser, the experience of loading my home page is slower with Ribbit on there. In my install, I decided to keep the Ribbit components on the homepage only and not have them follow me around Salesforce on the sidebar.  On Lead/Contact detail pages, you have a choice of the Flash component or a Messages related list.  l opted to put the Messages related list on my Lead & Contact for performance reasons and also for consistency sake.
• You give Ribbit your login credentials – In order to have your voicemails there when you login, Ribbit needs to do background processing. This makes sense, but it requires you giving Ribbit a login to your system. Many company’s can’t afford a new license just for Ribbit, so they’ll end of giving them the admin login. I trust Ribbit with the login info, but it’s a risk to hand anyone login credentials. Ribbit doesn’t have much choice, though, if they want to get the data populated and ready for users when they login.  I think this issue could be eliminated if Salesforce allowed for a special user to be created for this purpose that did not take a hit on the customer’s license count. This is how Salesforce does it with their License Manager application. This should be a benefit of being a partner with a certified application.

Ribbit is definitely a nice product and their thinking is beyond just Salesforce.  It’s really a new platform for “voiceware” applications. Salesforce was their first target for a specific application aimed at the Enterprise. I would expect to see more.

You can get a free trial on their AppExchange listing.

Have you tried it? What do you think?

Step 1 is to identify your domain. Your company must have an existing Google Apps business account to do this.

Step 2 is to enable the features you want. This will be your main control panel for managing these settings.

Some observations:

• The Add Google Docs to Salesforce feature is very cool and will be very useful! It adds onto the existing Notes & Attachments related list and lets you create/associate a new Doc, Spreadsheet or Presentation to a record. You can also look for an existing document you have and associate that. I am not sure how it handles access to the document by others. You might have to specifically collaborate with people.

  

  I did not see any Mail Merge capabilities with this feature.

• When you enable the Google Docs tab, it adds the tab onto every application you have rather than asking you. You have to edit each application to remove it. This feature is nothing too special. Just a tab to Google Docs. I don’t see any special development Google did on their end to refer to Salesforce in their UI.
• Enabling Email to Salesforce gives each user a new Email Settings screen where they can edit their personal settings. The idea here is that you BCC a special email address and Apex code will process it and associate the email to your Lead/Contact. I tested it and attachments do not get saved.

  

  Email to Salesforce is not limited to Google Apps. The image Salesforce has includes gMail, Outlook and Yahoo! Mail.

  

• Enabling gMail Buttons & Links adds a gMail link to every email address field. When you click it, a gMail window opens to compose a new email. A special Salesforce email address is BCCed on the message so that it will be processed right into Salesforce for you and associated with the record.

  

  

• Enabling the Google Talk Sidebar Component puts the same Google Talk widget you see in gMail on the Salesforce sidebar. I opted to keep this turned off as I’ll keep using my Trillian client. This feature is not pulling Contact names into gTalk. It’s simply putting your current gTalk contact list on the sidebar. You’d add people the same way as if this integration never existed.
• I didn’t try any of the 3rd party apps. At first glance the Calendar Sync and Report Collaboration sound the most interesting.

What do you think about the new functionality?

Salesforce’s main announcement page is http://www.salesforce.com/googleapps.

The permanent Salesforce product page is http://www.salesforce.com/products/google/apps.

Some of the notable sites are tracking it too. I am sure there will be lots more by morning.:

• Techmeme Discussion
• Techcrunch
• Mashable
• C|Net
• Associated Press

Some highlights:

• I believe this is offered free to all Salesforce users
• Save email right to Salesforce like you can do with the Outlook Connector already. Not sure if it has 100% of this functionality such as Attachment saves.
• Generate Google Docs, Spreadsheets and Presentations right from Salesforce and have them linked to your records. The Google Docs side will allow for strong collaboration and the linkage to Salesforce will ensure that everyone is working off the right document. I was unable to tell via the video if you can do Mail Merge to Google Docs like you can with MS Word.
• Google Chat is embedded in the Salesforce sidebar allowing you to chat with people right from within Salesforce
• Sync your Salesforce & Google Calendar via a 3rd party app
• Export your Reports to Google Spreadsheets with a 3rd party app

Check out the new Google Apps category on AppExchange to see all the 3rd party apps.

The direct URL to the knowledge base is:

http://www.arrowpointe.com/support/kb/

There were a couple of webinars today about the changes. The customer-focused webinar will be available at http://www.salesforce.com/security soon. The partner-focused one will be available in the Partner Portal.

Below is my understanding of what was said and a high-level overview of the main impacts. Please add clarifications in the comments.

API Logins

• If you connect via a Session ID passed from a web link/tab, none of these restrictions apply as the user is explicitly providing you with login access to his/her active session.
• To login with a username and password, the IP address you are logging in from needs to be white-listed.
• Salesforce will pre-populate the org’s whitelist with IPs used in the past 4 months.
• Each end-user can generate an API token to replace their password for API logins.
• API logins using the API token do not require their IP to be whitelisted.
• API tokens do not expire. Only 1 is active at a time. It can be replaced by the user generating a new one. This automatically invalidates the old one.
• API tokens cannot be used to login at https://www.salesforce.com/login.jsp.
• Going forward, the best practice would be for end users to provide their API token to any app/service they use other than the main Salesforce.com login page.

Logging in at https://www.salesforce.com/login.jsp

• Username and password will still be the way to access Salesforce.com from the main login page
• A new feature will be added requiring you to confirm that your computer is valid to login using that username.
• The login page will check if you’ve logged in from that computer before (by looking for a browser cookie)
• If not, the email address on the user record will be sent an email to confirm that you are, in fact, the one trying to login now.
• You will click a link in that email “activating” your computer for login with that username
• Unless you delete the cookie or clear your broswer’s cache, you should be good to go for a while without repeating these steps.
• There are no new IP restrictions affecting logins at the main login page. The profile-based IP restrictions that have been around for a long time are still the way to go there.

If you are a consultant, you may fall victim of the new security measure when you try to login as your client (maybe they couldn’t afford another temporary username just for you). On the call, I was told that you can request a temporary one via the Partner Portal or ask your customer to forward you the email to confirm your PC is okay.

My thoughts

I think it is great to see Salesforce taking a step to tighten up the API, especially. I like to think that my old API Authentication List post had something to do with it, but who knows.

The biggest impact to me will be using client’s logins to get into the system from my PC, but I’ll just have to workaround that one. Security and convenience are generally a trade off and overall I’d rather use/subscribe to a service that is tightened down with my business data. If anyone can handle the inconveniences of logging in, it’s developers since we are used to doing hacks/workarounds in the first place.