Skip navigation

Do It

1 Post authored by: Markku Alikoski

In a recent project we had to build a vast amount of webinar registration, whitepaper download and contact us forms in 19 different languages. The total amount of forms was 418, meaning that the expected outcome or action of each form was unique. For example a gated download form had to deliver a link to a number of individual PDF documents (one per form) or perform different actions like webinar registrations depending where the form was called from. Obviously the forms had to be pre-populated. If a prospect fills a form to download document A, we should not ask him/her to key in all the data again when document B is requested etc.


Since building 418 forms is a formidable task even by using the new, fantastic form management tool in Eloqua 10, we thought there must be a better way.

On the form field level there were only two different types of forms:

  • a small gated download form with just basic contact information fields
  • a more complex contact us and webinar registration form with additional fields


We ended up building 38 unique forms, one of each form type for each language (19+19). We thought we could have even reduced this to only 2 by parameterizing the languages, but we felt that this would lead to an overly complex form. Handling the languages separately made for example the form validation part easier, since we could use Eloqua’s own validation system.


Each form sat on its own minimal, language dependent Eloqua landing page and had one adjacent thank you landing page. The forms were called on client’s corporate website using a JavaScript method to remove unnecessary browser bars and to center the form on top of the page it was called from. We had preferred opening the forms as beautiful shadowbox overlays, but in this case it was not possible due to limitations of the corporate web CMS used.


Without going too much into details, this is what we did and how we will instruct our employees to do in the future:


Tip #1: 

Plan well ahead and map the differences and similarities between all your forms. Build one form of each type first as readyas possible and test it properly. Set up validation and all processing
steps needed. Once everything works and is approved by the client, then save the form as a template and use it to create language versions by modifying field labels and validation error messages.


Tip #2:

Use query string parameters and JavaScript to extend the form functionality. This enables you to have just one form for multiple purposes.
Let’s say the URL ofthe gated download form on Eloqua is
When called in context of downloading document A, the URL becomes

Use JavaScript to grab this parameter value on the form page and add it to the end of a hidden field “thankYouPageURL” value (already containing a default value “”) to carry it over to the next page. This will tell the thank you page what to do.
Create a processing step “Redirect to Web Page” determined by this form field.
On thank you page, grab the value again and serve the appropriate document using JavaScript. 


Tip #3:
Always store your custom JavaScripts into files located on an external web server, not inline on Eloqua landing pages or in the Eloqua Component Library File Storage. Just make a reference to your scripts on the Eloqua landing pages. There are multiple benefits:

  • Making system-wide changes to your scripts is much easier when the files are stored in single location.
  • Script editing is more convenient using a professional code editor with code highlighting and FTP capabilities (UltraEdit is my favorite).
  • Soon you will have a modular, thoroughly tested generic Eloqua JavaScript library (think Swiss army knife) of your most timesaving functions. Starting a new project with a new client will be faster.


Tip #4:

Using a JavaScript Framework like jQuery or Prototype improves cross-browser compatibility and shortens development and testing times.


Tip #5:

Use hidden fields to record the action type performed. In this case we used “Lead Source Original” and “Lead Source Most Recent”. LSO is written to corresponding contact field only if the field is previously empty. LSMR is always updated. In this case we grabbed the form action parameters (see Tip #2) with JavaScript and populated the hidden fields accordingly. This allowed us to identify where the conversion originated, i.e. what initially made the prospect to give his/her contact details. In general you should always include LSO and LSMR on all forms. There are multiple uses, normally lead sources relate to inbound marketing channels (Adwords, banners, email etc.), but you can use them as you like.


Tip #6:

Use custom data objects to store all form data. There are multiple benefits:

  • You don’t need to consume contact or account table fields for data that really doesn’t belong there
  • Custom data objects can be used for profiling
  • All form activity data is stored in one location and can be exported easily (without going into each form individually and taking the “View Submission Data” option.

Note: If you want to capture multiple actions per user instead of updating a single data row, leave “Select the Key Field” undefined.
If you set the email address as the key, only one record per user will be created.


Tip #7:

Do not embed the Eloqua forms inside iFrames on client’s corporate website. Even if it works most of the time, you should not because:

  • Layout issues: If you later need to modify the form page size (add text, add fields), you would have to also change the iFrame size on corporate web CSM  (at every form instance in the worst case).
  • Tracking and pre-population: In most cases both do work, but depending of the user’s browser security settings, the Eloqua cookie may be rejected (as a 3rd party cookie) leading to mismatch in tracking and preventing pre-population.

If you really have to have the form on the actual website, build it there and just integrate it to Eloqua.


Tip #8:

Always add a processing step “Add to Program” to every form, even if you don’t need it for now. Create a one step program in program builder doing nothing and activate it. This enables you to later extend the functionality of all your forms without tweaking each and every form individually. Program builder is very powerful and with it you can implement complex conditional processing that can’t be done using the form processing steps.


Tip #9:
Pre-populate forms for recurring visitors (who visit the site without having the elq parameter in the URL). If I fill a form today to download a whitepaper and return tomorrow to download something else, why would I have to key in my data again? We first tried to implement this using the new Form Population (beta) Cloud Component, which at the time (June 2012) did not work for us. We ended up using Web Data Lookups instead, which worked wonders. Ok, it required a bit JavaScript coding, but was worth it. It’s in our JavaScript library now.


Tip #10:

You can easily integrate the webinar registration functionality to your Eloqua forms using “Post Data to Server” processing step to submit data into Eloqua and to an external webinar system in one pass. To manage this, we studied the webinar system’s (GoToWebinar in this case) registration form HTML and duplicated the fields with proper default values as hidden fields on our Eloqua forms.
The benefits are:

  • One form submits data to two systems, Eloqua and GoToWebinar.
  • You don’t have to add “Send Submitter an Email” processing step to your Eloqua form, since GoToWebinar will send it for you and does it much better (including all webinar details, phone numbers, cancellation and add to calendar links etc.)


This article explains the form setup side of the campaign my colleague Tero Rantaruikka explained in his fine article:

Filter Blog

By date: By tag: