×

Become a part of the TegCircle!

The TegCircle isn’t just an email list. Emails are most often a one-way communication. Circles are different. Circles are interactive

Tegrita is committed to knowledge-sharing, making authentic connections, and contributing to the digital marketing community.

As a part of the TegCircle you’ll enjoy:
  • exclusive access to select online events
  • a library of proven practice templates, tools and resources
  • inclusion in industry research, discussions and other opportunities to knowledge share
  • being part of our community of awesome Modern Marketers!

How to Convert Contact Data into Custom Object Data in Oracle Eloqua

By August 14, 2019Proven Practices
How to Convert Contact Data into Custom Object Data in Oracle Eloqua

One of the many benefits of Oracle Eloqua is that the answer to “Can I…” is most often “Yes!”. 

Recently, I ran into a problem I’d never encountered before. We were tracking music genre selections based on clicks in emails and on landing pages as individual checkboxes in several CDOs. However, our client already had data at the contact level, stored as literal text values. For example, a contact could have, “Music Genre: CLA” on their contact, but we’d need that translated into, “Classical: on” in the CDOs. We needed the data in the CDOs to drive a special nurture process, which meant all contact data needed to be pre-populated into the CDOs to start. Not only that, this would not be a one-time update of values from contact to CDOs, but an ongoing process as new Contacts entered the database.

The Problem: How do we backfill the CDO checkboxes with the data stored in the Oracle Eloqua contact field? 

The Solution: I created an automated process using what we are referring to as a “meta form submit” to take the music genre value stored in the contact field and check the related checkbox in the CDO. For example, if the genre listed on the contact is “CLA” the checkbox in the CDO for “Classical” is checked. 

One potential solution to this problem was to use the form submit app and have conditional logic to do the translations. The form submit cloud app is a powerful utility app but, in this situation, it wasn’t ideal because there would be far too many conditions and the form would require constant updating whenever a new value was added to the Contact/CDO.

As a part of the broader solution, I was already populating the CDO checkboxes using blind form submits in emails being sent to Contacts. These responses would drive the decisions being made in the nurture process. A blind form submit, if you’ve never used them, is “a special URL that includes pre-defined responses for a form. When a contact clicks the link, the form responses are submitted to Eloqua. For the contact, it’s a seamless experience—they don’t even know they’re submitting a form (which is why it’s called a blind form)” So, if a contact could click a link in an email, could Eloqua do the same thing? Yes, as it turned out, it could! Here’s it is the solution:

Step 1: Create an Eloqua Form to Collect the Required Values

For this use case, I took a code name for a genre on the Contact record and used it to populate a checkbox and genre picklist in a CDO. First, I created a form to collect the values.

 Note: CLA and COU correlate with genre values on the contact we needed to check off in the CDO. We were also tracking the full name of the genre.

Step 2: Create Custom Data Object (CDO)

The CDO field configuration. There could be any number of genre checkboxes. 

Step 3: Build Program Canvas

Once I had the form and CDO in place, it was a matter automating the process to copy the values from the contact field to the CDO. To achieve, this, I built a Program Canvas. The program leveraged both the Contact Washing Machine (CWM) and Form Submit apps.

Note: I have steps to route errors. This is a great practice to get in the habit of doing.

Step 4: Construct a blind form submit URL

Using the Compose Action of the CWM app, I constructed a blind form submit URL. The Eloqua Site ID (elqSiteID) is the unique identifier for your Oracle Eloqua database; I obfuscated the Site ID in this example. Because the form submission is not from an actual contact, I included elqCookieWrite=0. elqCookieWrite=0 prevents Eloqua from trying to associate a cookie visitor ID to a contact, since there is no cookie in this case, we don’t need Eloqua to do the association. I also created a new large text contact field to temporarily store the blind form submit URL. The form name in this URL corresponds to the form HTML name of the form created in step one.

The URL is just like any other blind form submit, except that we are using the CWM Compose step to merge in fields from the contact as both the name of the form checkbox field and the value of the genre text field.

Step 5: Create a form

Next up was the all-important step of “clicking” the blind form submit. You may be wondering, “Jesse, how is someone going to click the link if there is no email!?”. The answer is “They don’t have to!”. One of the least seldom used features of Eloqua forms is the processing step, “Post Data to Server”. That step allows us to trigger the form submit.

To “click” the blind form submit, I created a simple form:

Note: I’m allowing URLs and there are no length restrictions!

Then, I added the necessary details to the Program Canvas:

This step takes the URL we built in the CWM and submits it through the simple form. It’s like the contact clicking on the link! 

Once activated, this process effectively builds a dynamically generated blind form submit URL and then executes it for each contact that flows through the canvas. This is essentially the same URL that would go into an email sent to a contact, but that we submit instead of the contact. Thus, converting the genre chosen on the contact and checking the related checkbox within the CDO.

To recap, the steps are as follows:

  1. Create or use an existing form that populates CDO checkboxes
  2. Create or use an existing CDO that is collecting checkbox values
  3. Create blind form submit link (that references the form the contact would submit) and save to a large text field on the contact using the Contact Washing Machine App Compose step
  4. Submit the value stored in the new contact field through a Form Submit App step and execute it by using the Post Data to Server processing step in a simple form built for that purpose
  5. The URL that is created submits the original contact form as though the contact had clicked the link themselves
  6. The checkbox fields in the CDO are updated based on what is stored on the contact

How Can This Solution Help You?

Although you may not have a need to specifically track music genre preferences based on the genre value on the contact, there are other scenarios where a similar data conversion is valuable. If you run into a situation where you cannot directly move a value from the contact to a CDO because the values are expressed differently, this solution may be a good starting point.

The following two tabs change content below.

Jesse Nobbe

former Sr. Technology Lead at Tegrita
Jesse is a Former Sr. Technology Lead at Tegrita. He helps design, build, and maintain robust Rev Tech solutions. In his free time he likes to power lift and dabble in piano.