Revisiting Salesforce.com’s Web-to-Lead Functionality

A salesforce.com staple for many years has been the Web-to-Lead feature, allowing for the capture of Leads from a web site outside an organization’s instance of Salesforce.com. Today, we’ll take a step back and walk through the key aspects of Web-to-Lead, including some tips on how to fully take advantage of this functionality.

The former is critical, while the second really depends on how you have configured your Auto-Response rules. The Default Lead Creator is the individual who will be shown as creating a Lead generated via a Web-to-Lead form. This may affect Assignment Rules, triggers, validation rules, workflow rules, etc., so select wisely. As for the Default Response Template, this is the email template that will be sent if no template is determined based on the configured Auto-Response rules in the Lead > Auto-Response Rules section. It is not required.

3) Generation of HTML

The selection of fields and configuration of Return URL drive the HTML that is generated in the next step of the process. You will be present with an HTML form that can then be used within a web page on a disparate site. It’s important to understand that the HTML that is generated is not stored anywhere; it is generated once and its content is unique to your settings at the time. You can edit the HTML directly, of course; however, if you forgot fields or if something else changed (picklist values), you will need to generate the HTML form again.

One thing you may notice is the difference in how standard and custom fields appear within the HTML form:

• Standard: <label for=”first_name”>First Name</label><input  id=”first_name” maxlength=”40″ name=”first_name” size=”20″ type=”text” /><br>
• Custom: Twitter ID:<input  id=”00N40000002Dj7E” maxlength=”20″ name=”00N40000002Dj7E” size=”20″ type=”text” /><br>

Standard fields use the Field Name, but custom fields use the actual record ID of the field itself.

The HTML that is generated includes all of the details specific to your org to allow a Lead coming through the resulting form to be able to properly route to your SFDC org.

4) Modifying the HTML for your site (inc. styling, hidden fields, picklist values, validations, etc.)

It’s very likely that the HTML you’ve generated will require some modification. Unless you have an extremely basic site with no styling, this will be the case. Let’s walk through some items that are candidates for tweaking:

A) Styling

While we won’t dive into the world of Web design here, It should suffice to say that you will need to ensure that your HTML form renders properly within your site. This may mean the employment of CSS or the identification of font properties within the HTML directly. Either way, you’ll need to see how your form looks and update it accordingly.

B) Hidden fields

This is a simple, but powerful aspect of the Web-to-Lead form. Just like with any HTML form, you can have hidden fields and input values. This is extremely valuable if you want to know the exact source of a Lead. For example, let’s say you have 10 Web-to-Lead forms spread across your website. Without some specific identification within the form itself, it may be impossible to determine the original source of the Lead.

To make a form field hidden, follow this formatting:

• Standard: <input type=hidden name=“fieldName” value=“desiredValue”>
• Custom: <input type=hidden name=“fieldID” value=”desiredValue”>

You will be able to see the populated value in SFDC without revealing that field on your web page.

C) Picklist values

Picklist values ARE automatically generated for you during the process. However, you may want to omit some values or display them in a more user-friendly fashion on your site. Simple. Just edit/remove as needed. For example, the following picklist field HTML can be changed from:

<label for=”industry”>Industry</label><select  id=”industry” name=”industry”>

<option value=””>–None–</option>

<option value=”11-Agriculture”>11-Agriculture</option>

<option value=”22-Utilities”>22-Utilities</option>

<option value=”23-Construction”>23-Construction</option>

</select><br>

to:

<label for=”industry”>Industry</label><select  id=”industry” name=”industry”>

<option value=””>–None–</option>

<option value=”11-Agriculture”>Agriculture</option>

<option value=”22-Utilities”>Utilities</option>

</select><br>

Above, we removed the prepended ID code from the Industry names and eliminated a picklist option altogether.

D) Validations

This is a key and can easily be missed in the process. There are NO  validations that are automatically built into your generated form HTML. Users can enter whatever they would like in your form fields; it’s up to you to restrict and control, as desired. True, SFDC will enforce system-level validations (e.g., a field of type number cannot contain letters), but this will not be visible to the user; the form will silently fail.

Make sure to work with your web team to build in form validations accordingly.

E) Modifications for sandbox testing

A simple change that is oft missed. Change the form action URL to test.salesforce.com as shown below, if using Web-to-Lead in a sandbox:

<form action=”https://test.salesforce.com/servlet/servlet.WebToLead?encoding=UTF-8” method=”POST”>

5) Lookup Fields / Campaigns

One nice feature of Web-to-Lead is the ability to specify a Campaign. The formatting is a bit different than that of other fields, since Campaign is a Lookup. The values will be the ID of the Campaign records. Additionally, you can specify the Campaign Member Status:

<label for=”Campaign_ID”>Campaign</label><select  id=”Campaign_ID” name=”Campaign_ID”>

<option value=””>–None–</option>

<option value=“CampaignID”>Campaign 1</option>

<option value=“CampaignID”>Campaign 2</option>

<option value=“CampaignID”>Campaign 3</option>

<option value=“CampaignID”>Campaign 4</option>

</select><br>

<input type=”hidden”  id=”member_status” name=”member_status” value=”” /><br>

Unfortunately, you cannot follow this same approach for other Lookup fields. This is a feature that would be well received, if ever offered by SFDC.

6) Other considerations

Since failed Web-to-Lead requests don’t show up anywhere, SFDC has intelligently provided a debugging option for administrators. Simply uncomment the two hidden input fields shown below (make sure to set with your email address) and you will receive details of failed Web-to-Lead submissions.

Another consideration for Web-to-Lead is the daily limit of 500 leads. This may or not be a concern for your organization, but it is good to be aware of, either way.

Happy New Year and best of luck with your 2014 Web-to-Lead submissions! Feel free to email me at phil.weinmeister@edlconsulting.com with any comments or questions.

The post Revisiting Salesforce.com’s Web-to-Lead Functionality appeared first on EDL Consulting.