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.