Skip to main content


Oracle Eloqua – Data Tools

Most Eloqua users know about the Data tools available in Eloqua.  However, do you know how they work or what they do?  I’ve discovered, that the answer is often no.  If you are a technical resource for your marketing team you may know this but the general marketing population know they exist but really don’t know what they do, how they work.  I want to bridge that gap by explaining them.  I’ll try to keep it simple, but in some cases, they are pretty involved.

Update Rule

Update rules are data transformation tools that allow known data to be looked at and updated.  Take for instance the Country field. Unless a picklist is used everywhere a value for Country is submitted, it can become very dirty over time. In this case, the Update Rule would look for the field Country and update that field based on a Lookup Table (I’ll explain this one next).  Update Rules also come in handy when trying to do Lead Assignments. It will allow for looking at one field to verify what the value should be, again using a Lookup Table, to make that distinction.  It is data manipulation at its best.  These are mostly used in Program Builder or can be used in the new Program Canvas.

Lookup Table

Lookup Tables make Update Rules more useful.  It is taking a list of values and making a correlation to a relative list of values.  This functionality, like the examples above allow for the Update Rule to look at the ‘bad’ data or field that denotes assignment criteria and update to the appropriate value. In my example above regarding Country, this data tool would look for values such as U.S. or U.S.A and change it to US.  It is a way to standardize values.  Lookup Tables are also used when doing a compare on a Form processing step, this can be used when looking to redirect the contact to a different page based on a submitted value or send a notification to sales regarding a target contact doing an action. It is a list of values that relate to the action you want to have performed.

Validation Rules

These are not often used, however they are a great data transformation tool.  They allow for several different functions to be used when creating the rule.  There are ‘Data type and length’, ‘Field value in Data Set’, ‘Field value required’, and ‘Find / Replace’ functions to choose from, these can be done on Contacts and Companies.  A little definition on each of these functions…

  • Data type and length: This function will take a field value and make sure that it meets the character limit. For example, say your lead assignments are based on zip codes, if someone enters in 12345-1234, that will not work, because you don’t take into account for the ‘-1234’.  This will lead to the lead not being assigned, but this validation function would take that ‘-1234’ off the zip code field and have it be only 12345.
  • Field value in Data Set: Allows for validation that a field value matches what is expected.  For instance, Country, you have a specific list of countries that you are looking at and if the value doesn’t match that you want to change the value, or the has record no value you want to default to a value.
  • Field value required: This function will set a default value to a contact field.  Very rarely used, Update Rules can do the same thing based on the criteria it has set in it.
  • Find / Replace: This is probably the most used validation function. It will find a value, and replace it with a different value. A use case for this is if you need to update the Sales person field with the Eloqua user ID (first.last), this function will take the space out and replace it with a period.

Deduplication Rule

You will may hear this referenced as a Match/Dedup Rule. It is matching a data element and then deduping or updating.  There are two types of dedupe rules, (1) on a single table (ex. contact to contact) and (2) a multi-table (ex. contact to company or vice versa).

  • Single Table: looking at a single table inside of Eloqua, either Contacts or Companies. The comparison of the fields and what ‘precision’ is crucial to making the rule function correctly. Precision is how the rule is going to look at the field data, such as starts with, contains, or exact match, and there are a few more to choose from.  Once that is setup, it is creating a Handler Set.  The Handler Set answers the question “What do you want to do with the match?”  Based on how you do the match, either by destination or source, you have several options to update the data.  A few options for updating the data are (remember, this is an E9 callout so it is all legacy naming convention): Add to a contact group, Update a field with field values from matched records, and Add to Step in Program Builder. There are several others as well.  Once you pick the option, then you set the details around that. If you choose ‘Add to a contact group’ (which means adding to a shared list), then it would be selecting that shared list.  If using the ‘Update a field with field values from matched records’ it would be from which contact field do you want to update the record and which field data you want updated to go into.
  • Multi-Table: The difference between this and the single is that you have to choose which data table is going to be the source and destination, so this will allow you to look at the Company table and update the contact record with data that may only be stored on the company table. This comes in handy if you have a CRM that doesn’t allow for data to be grabbed between objects in the ‘get’ data from CRM.  This rule will allow for you to get the data onto the contact, say for personalization.

With either one of these, you can do updates on the matches or the non-matches.

Match Rule

This rule allows you to match data and update contact records.  Some similarities to Deduplication Rules are that you can go across tables, it uses the ability to match a specific expression and has rules around what is updated.  However, in this case, there is no ability to update non-matches.  One real world case is if you need to update contacts with additional details from the CRM Campaign data before sending to CRM.  In this situation, the Campaign data is stored on the Company table, and is used to update further details based on a match to the Campaign ID.

Now, one caveat to these is that if you are on the basic version of Eloqua you may not have access to Data Tools, it is an additional cost to get them.  So if you don’t have them, you may want to consider taking with your Oracle sales rep about them.

The best way to learn about Data Tools is to do a bit of ‘playing around’ with them.  If you have some down time during the holidays take a moment to learn about one or two of them.

Happy data transforming!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Amy Anderson

More from this Author

Follow Us