Deprecated: Assigning the return value of new by reference is deprecated in /home/warped/public_html/sfdc-heretic/wp-content/plugins/codesnippet/codesnippet.php on line 248

Strict Standards: Non-static method GoogleSitemapGenerator::Enable() should not be called statically in /home/warped/public_html/sfdc-heretic/wp-content/plugins/sitemap.php on line 2452
Salesforce Heretic » Salesforce.com Mail Merge, Part III: “Spaulding, this calls for the ole Billy Barule…”

April 21, 2006

Salesforce.com Mail Merge, Part III: “Spaulding, this calls for the ole Billy Barule…”

Filed under: Salesforce.com, Mail Merge — heretic @ 11:30 am

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/warped/public_html/sfdc-heretic/wp-content/plugins/codesnippet/codesnippet.php on line 260

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/warped/public_html/sfdc-heretic/wp-content/plugins/codesnippet/codesnippet.php on line 261

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/warped/public_html/sfdc-heretic/wp-content/plugins/codesnippet/codesnippet.php on line 262

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/warped/public_html/sfdc-heretic/wp-content/plugins/codesnippet/codesnippet.php on line 263

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/warped/public_html/sfdc-heretic/wp-includes/functions-formatting.php on line 76

So, in a quick recap, we’ve already laid down, in general terms anyway, why we’re doing this, and generally how we’re going to do the merge. Now it’s time to get the data.

So if you’re a Salesforce.com customer with access to the API you might think to yourself, “Oh, this is easy… Just query the object I need, wham boom bang, vola!”. Good luck with that.

Lets take a quick look at a Lead object and the merge fields it uses… First up lets look at the person’s name. We’ve got three fields, LEAD_FULLNAME, LEAD_FIRSTNAME, and LEAD_LASTNAME. Ok this one isn’t too bad, the API will give us the first and last names and all we need to do is combine them. Ok, lets make a note of that and keep looking. Next we have the address fields. Ok, so we copy the LEAD_STREET to LEAD_ADDRESS, and create a concatenated version with everything called LEAD_FULLADDRESS. Ok. Starting to get a bit tedious. Oh wait, how do we know what to call these merge fields?

So far the naming convention is pretty simple. All caps, prefix the merge field with the object name, strip spaces, no big deal. A quick function and a call to DescribeSObject later and we’re rolling. But why do we have both LEAD_STREET and LEAD_ADDRESS. I’m not 100% sure but an educated guess: backwards compatibility.

So we continue to walk through our standard fields and get them all lined up to what we expect to see in the merge document for field names. Now lets take care of our custom fields. Custom fields follow almost 0 of the conventions for standard fields. For each custom field, you create two merge fields. The first is based on the custom field label, the second the API name. Oh, and just to throw a wrench in it a bit more, they don’t follow the same convention. So take your custom field with the label “My Custom Field”, and the API name of “Custom_Field__c”. Take your label, strip the spaces, convert to all caps and you get LEAD_MYCUSTOMFIELD. Now take the API name, keep the underscores, strip the “__c” from the end, convert to caps and LEAD_CUSTOM_FIELD is the result. Of course they both get the same data.

So if you haven’t thrown up your hands yet, don’t worry. Yet another special case with the lead object is that in a merge it also populates “fake” contact fields as well. Seemingly the idea is to allow you to use the same basic document to merge with both leads and customers without having to change all the fields in it. Nice idea, but at this point we’re evaluating buying stock in the makers of a good headache relief maker.

Truth is — it’s not nearly as hard as I make it out to be. Ask yourself this question: Do you think the little mail merge app goes and queries the API, does all these translations, and then does the mail merge? Nope. Luckily for us the mail merge applet that SFDC uses is fairly dumb in this regard. It gets all the ready-to-merge fields and data handed to it on a little servlet silver platter. The UI hands it an XML file all ready to go, but where is it?

Lets go get one. Load up any lead (or really any object that allows for mail merges, in the case of custom objects one with activities enabled) and make note of it’s ID (00Q… something in the case of a Lead). Also note what instance you’re on (na1, ssl, emea, jp, test, etc…) and lets look at this URL:

https://{Instance}.salesforce.com/servlet/servlet.SForceMailMerge?id={id}

Of course replace {Instance} with your instance name and {id} with the Id of the object you want to merge, and Vola! You get a nice XML document with all the field names and data ready to go.

So now we’ve got the data, we know, generally, how we’re going to merge it into Word, now we need to actually do it. Part IV will look at generating CSV data using Java and getting it ready to merge into Word and we’ll start actually getting into code.

License

This work is published under a Creative Commons Attribution-ShareAlike 2.5 License.


Strict Standards: Only variables should be assigned by reference in /home/warped/public_html/sfdc-heretic/wp-includes/functions.php on line 590
« Salesforce.com Mail Merge, Part II: “Word made me do it…”  
Strict Standards: Only variables should be assigned by reference in /home/warped/public_html/sfdc-heretic/wp-includes/functions.php on line 590
Salesforce.com and Google OneBox »

No Comments

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.