Perspectives on Salesforce.com

Building upon my previous experience with Web-to-Lead spam checks, I am readying the release of an AppExchange application to perform spam checking against your incoming Salesforce data. Benefits include:

• 100% native Force.com application
• I’ve taken care of licensing a top notch, 3rd party spam checking service
• You can train the service to make it more intelligent
• Web-to-Lead spam checks (make 2 small changes to existing web forms and you are up and running)
• Web-to-Case spam checks (make 2 small changes to existing web forms and you are up and running)
• ** In development ** Support for Web-to-Lead forms using Salesforce for Google AdWords
• Exposed Apex methods allowing developers to incorporate a Spam Check in their Apex code. Perfect for use with Salesforce Sites forms you build.

Before officially releasing it to the public, I want it running in the real world and am looking for people to try it with real, live web forms. Being an active participant will mean a good deal on it when it’s released. Please complete the form below and you’ll be added to the list of those interested. I’ll reach out to you when I am ready to get the beta going (plan on late July / early August).

Update 2009-09-04: Thank you for your interest, but the beta is now closed.

On a recent project, I was migrating a customer from the Contracts object to a Custom Object (Contracts are not supported in Customer Portal for some odd reason).  The Contract Number was being imported to the Name field on the new Custom Object.  To do so, I had to make the Name field a Text field so that we could maintain the value.  We also wanted to keep the formatting of 00000123 for contract #123.

After import, I converted the Name field to an Auto Number and set its mask to be {00000000} and its starting number to be the next one in the sequence.  When you change from a Text to an Auto Number field on the Name field of a Custom Object, the old data is left alone.  Had I imported, “123” into the Name field, Salesforce would not apply the mask.  Thus, I had to import “00000123” on the migrated records.

The issue my client discovered is that you can’t search for “123” in the Sidebar Search to find the Custom Object record that was imported.  It will work for records generated after the field was changed to an Auto Number, but not the converted data.  To find the legacy data, we’d have to tell the users to search for the full value of “00000123”.  Not good.

The resolution was actually pretty simple.  I added a new text field to the object and have a Workflow Rule that copies the Contract Number to it.  On Custom Objects, all text fields are indexed.  Voila!  It was searchable.

In January I posted about how to invoke Apex from a Custom Button using a Visualforce Page.  It has been a popular post and is a topic which is of interest to many developers.  I wanted to draw your attention to another post.  Sam Arjmandi, from Salesforce Source, posted about how to invoke Apex from a button by calling the Apex directly from JavaScript whereby the Apex must be available as a web service.

Both methods work just fine and there is a choice of approach.  Recently, my personal choice for implementing this kind of functionality is to use Sam’s approach and it’s mostly due to the user experience.  Using this approach, the code is called directly and there is no time spent by the browser needing to load a new blank page only to return to the same page.  It works much more seamlessly.  You also get the benefit of having less objects to develop (no VF page) and tie together.  The only real downside (outside of requirement-specific ones) is that Salesforce won’t bark at you if you delete the web service class because it doesn’t know that the web service is tied to JavaScript.  If your Apex Code is a controller for your VF page, Salesforce will protect you from deleting it accidentally.

Auto vCard 2.0 was released in January of this year with major functionality improvements, one of which was it running native on the force.com platform.  The older 1.x versions of Auto vCard used scripts running on Arrowpointe web servers.

The 1.x scripts are being retired.  If you are running a 1.x version of Auto vCard (go to your Setup | View Installed Packages page in Salesforce to check), you should be aware of the following changes taking place.

• Beginning  Tuesday, June 16, 2009, the behavior of the 1.x version will be changed.  Instead of the app automatically giving users the option to open/save the vCard, a link will be available on the popup window to get the vCard file.  Also, a new browser window will open directing them to this page explaining that they are on an older version that is set to expire.  Initially, this new behavior will only occur once every 2 days, but it will be more frequent as the July 31 date approaches.

• Auto vCard 1.x is expiring July 31, 2009.  At that time, anyone on version 1.x will start receiving an error message when creating a vCard.

• You can avoid issues related to either of the above 2 bullet points by upgrading your Auto vCard installation now.

To learn more about version 2.0, you can visit the product page on our website or the AppExchange listing.  Version 2.0 offers a free 60 day, 5 user trial.  After that, it is $1/user/month to subscribe and you can subscribe any number of your Salesforce users to it.  Non-profits can use it for free.

The Summer ‘09 Release is just around the corner.  In fact, NA1 and NA6 are going live tonight.  You can see the schedule at http://status.salesforce.com/trust/status/.  I’ve made a copy of it below.  The first table is in US Pacific time and the second is UTC.

This release is not extremely exciting (unless Sites goes GA), but some of the more exciting features to me are:

• Recurring Tasks
• Automated Campaigns
• Enhanced Declarative Logic for Picklists
• Sites?  The word on the street is that Sites is becoming generally available this release, but I have not seen any official documentation stating that.