Passing this data into Eloqua is, of course, a very valuable thing for marketing to do. However, there may be instances where the form submit is used for another action and the data needs to be passed forward. For example, the form might be the start of a download of a free trial, and the information is required for configuring the license key. Similarly, the form might be used for searches within the web site, and the data needs to be passed forward to perform the search.
This dual purpose form use can be done easily within Eloqua. There are four main ways that forms can be handled in which the data is provided to both Eloqua and a secondary system:
1) The form can be submitted to Eloqua, the data captured, and then the visitor’s form resubmitted to another URL (such as a trial download or a search page), which then handles the visitor’s experience itself
3) The form can be submitted to the secondary application, and then automatically re-submitted to Eloqua, where the data is captured, and the visitor is presented with a landing page or a PURL page from within Eloqua, to complete their experience
4) The form can be submitted directly to another site, which then re-posts the data, server to server, into Eloqua after handling the visitor’s experience
The first option is the simplest and most commonly used. To do this, simply change the type of the final processing step. Normally, this is a Confirmation Page, but by selecting "Change Type" on the drop-down menu, you can change this to a Resubmit Form step. Configure the step by defining the URL to send the form data to. The identical data that was submitted to Eloqua will be resubmitted to the secondary system, which will complete the web visitor's experience.
The third option relies on being able to configure the secondary system to resubmit the form to Eloqua. This is less common as not every system is configured to be able to resubmit form data. However, if it is, this is a similar approach to the first option, but in the reverse order. In this case, configure the form as normal, but the final step would be presenting the visitor with a landing page to complete his or her experience.
The fourth option is much more technical, but does allow for some interesting options. The form is submitted to the secondary system, and the secondary system handles the visitor’s experience from there. However, at the same time, the visitor’s data is submitted, server-to-server to Eloqua. If you are interested in this option, it's worth a discussion with your customer success manager, as the setup of it will involve your technology team.
A key thing to remember in this fourth configuration option is that the visitor’s website cookie will not be automatically submitted as it is with web forms normally. As the cookie forms the core of the visitor’s profile, this is very important. Without it, you will not be able to associate the visitor on the website with the form submit, which prevents using the data for lead scoring or segmentation. With a quick configuration, however, you can easily configure the web visitor’s cookie to be passed in to Eloqua from the secondary server. This allows the seamless linking of the web visitor with their form data, even though there was no direct submit.
With whichever of these four options you select, you can quickly and easily configure a form to be submitted to both Eloqua and a secondary system without any interruption. The flexibility of approaches gives you the ability to accomplish whatever you need, regardless of current configurations and limitations.