Perspectives on Salesforce.com

There have been many instances on projects where I have needed/wanted to map a lead field to 2 places. For example, on my most recent project we are using custom address fields. We wanted to do this to have better control over data quality. Using a picklist value for country coupled with Winter 07 Validation Rules, we have the ability to put pretty tight restrictions on the data that gets entered (e.g. forcing a 2 character state/province code when the country = “United States” or “Canada”). This aids in overall reporting, Territory Manager rules once the lead is converted and in Lead Assignment rules.

One of the things you give up when you do this is the ability to map those custom address fields on a Lead to both the Account and Contact like the standard Address fields do.

Pre-Winter 07

In the pre-Winter 07 world, doing this required a user to run an s-control or to have a polling application look for recently converted records and copy the address to the 2nd location. I had been able to use Formula Fields to get painfully close to making creating a 2nd copy of a field and mapping it, but when trying to save a mapping from a formula field on a Lead to a text field, I’d get an error that field sizes didn’t match. Big headache.

With Winter 07

Now that Winter 07 is here, I am able to use Field Update workflow rules to make a second copy of Lead data so that I can map that second copy to my Contact record. To do this:

1. Create a copy of each Lead field you want mapped to a 2nd object
2. Map the copied Lead fields to the Account, Contact or Opportunity fields they should be mapped to
3. Create Workflow Rules on the Lead object that use Field Updates to update these new fields with the values of your original fields
4. Test it out. It should work

Some tips:

• Choose to evaluate your workflow rule “Every time a record is created or edited” so that your rule is always evaluated.
• Use criteria that will always be met like Created Date > 1/1/2000so that the data is always copied to those new fields.
• To avoid confusion for end-users, use Field Level Security to hide those copied fields from view. This way your users won’t see them on report screens and wonder what they are. Even if you hide the field from everyone, workflow can still see it and update it.

Doh!

There is 1 snag. Formula fields (which you need to do the Field Updates) have to use the ISPICKVAL function to get a value from a picklist. If you have a sizable amount of picklist values, you won’t have enough formula space to make this work. I hit that on my Country picklist.

Future

In the future, you should be able to use APEX code to intercept the Convert logic and map those custom lead fields to 2 places.

Better yet is a simpler approach that will make it so you aren’t doing all kinds of workarounds or coding in your configuration. Vote for these Ideas that Salesforce customers have already requested:

• Map Lead fields to more than one object
• The ability to retrieve a picklist value in a formula field

Just echoing the post from the ADN Blog.

• The 8.0 API documentation was updated and posted. (link)
• The AJAX Toolkit will be out of beta with Winter 07 and the documentation was posted (link). Usage of the beta toolkit will still work, but changing to the production toolkit will provide better performance and will allow you to take advantage of new enhancements as they come out.
• Tech Note “What’s New in Apex Web Services API Winter ’07” (link) provides an overview of the API changes and considerations in moving your integrations to the 8.0 API.

If you only care to follow 1 link, the main Documents page on ADN is the place to look.

Tony Stubblebine just posted part 2 of his 3-part series on how to build and distribute applications on Salesforce.com’s AppExchange. The series is being published on the O’Reilly Network. Links have been permanently added to my blog sidebar, but here they are again:

Part 1 of 3 – An Introduction to Salesforce.com’s AppExchange: Tony lays out the basic information that any developer should know to get started. This article provides some context and points to how a developer can get their hands on a free Developer Edition account.

Part 2 of 3 – Using the Salesforce.com API: Tony explains how the Salesforce API works by creating a PERL script that automatically creates Salesforce.com Leads for every comment posted on a blog. This is a well-rounded example because it explains how to use the API and also how it impacts the back-end (inside Salesforce).

Part 3 of 3 – Packaging for Salesforce.com’s AppExchange: Tony continues building the blog-to-lead application by walking through the process of packaging and uploading to the Salesforce AppExchange.

Some good blog posts on APEX.

ZDNet: salesforce.com’s Apex language is not the lock-in attempt it appears to be: Dave Berlind goes through his thought process on APEX. Skeptical at first, more reassured now, with a lot more questions to be answered.

Saas Blogs: Salesforce.com’s Apex: Benioff’s Handcuffs for On Demand: The post itself is an attack on APEX, but through the comments, the tone changes. Interesting read.

And to hear it from the source of APEX, visit http://www.salesforce.com/landing/apex.jsp

Mike at Thoughts on Salesforce.com posted a nice overview of the Salesforce.com URL Structure.

He also references a site I’d never heard of called welldesignedurls.org. Here’s a link to the Salesforce page on that site.