Let’s set the scene: You’ve just joined the team of a long-established Oracle Eloqua client and your new boss has confidently given you ownership of the integrations for your Oracle Eloqua instance. You’ve worked in this area before, but when tasked to review the current integration and look for “areas of opportunity,” your head is spinning with where exactly to begin.
Not to fear – in this blog we’ll take a look at some of the key focus areas to review when conducting an audit of your integrations with Oracle Eloqua.
Identifying the Integration Points
There are numerous ways to integrate with the Oracle Eloqua platform, some of which you may not even be aware. The most common is via the native integration panel that allows for an integration with most of the common CRM’s like Salesforce, MS Dynamics and Oracle OnDemand. Here you can configure and control the CRM integration directly within Oracle Eloqua.
There are also “flat file” or “batch” integrations that can either be identified in the Data Import/Data Export area, or sometimes through an auto sync. In these integrations, files are generated with data from a source system like your Enterprise Data Warehouse (EDW) or Database Marketing Platform (DMP) and placed on an SFTP server. From here, Oracle Eloqua is able to bring the data from these files into the Contact, Account, or Custom Object tables for use in the system.
One of the best features about Oracle Eloqua is the openness of the platform and the ability to extend the functionality of the tool “outside the box.” From custom apps to those your webcasting platform offers, apps are another common source of integration points within your system. These can be identified in the Settings area under Apps and typically use the Bulk API to communicate with Oracle Eloqua. We’ll discuss more about why that matters in the next section: Data Priority.
A less common integration method is through an external ETL (Extract, Transform, Load) tool like Dell Boomi or Informatica. These integrations are often required when the level of data manipulation, or “transformation,” needed between Oracle Eloqua and a system like your EDW is more complex than can be handled via a flat file integration. You can gain some visibility into potential sources of these and other API-based integrations in the Upload History found under Inbound Integration > Reporting. Typically, the Source will be “Bulk API” and the user name will help indicate the primary source of the integration.
Data Priority
Now that we’ve identified our major integration points, where do we begin our review? One of the biggest sources of integration and data challenges lies within the data priority configuration of your Oracle Eloqua instance. Under Inbound Integration > Data Priority Order you can view your current data priority “buckets.” Within those buckets various data sources are added and organized. In addition to standard data sources like Excel manual uploads, SFTP, Bulk API, etc., each time you create a new auto sync and other types of data import scenarios, a new data source will get created.
Every time data is uploaded into Oracle Eloqua whether by auto sync from your CRM or via a manual upload, Oracle Eloqua will check on a field-by-field basis whether the last data source to update that field was of a higher, lower, or equal data priority per your current buckets. Any data source of a lower priority will be ignored and the field will not be updated. As an example, let’s say your manual uploads are set to lowest priority and your instance uses the native integration with your CRM which is most common. A marketer hands you an Excel list with updated information about attendees at their in-person event and you attempt to upload this directly into Eloqua. If any of these contacts already existed and were last updated by your CRM, your Contact would not be updated with the “lower priority” Excel data. In this case, the information would be better updated in CRM and allowed to flow back into Eloqua via the auto sync process.
Data priorities are often bucketed as follows (from highest to lowest priority): Bulk API, CRM Accounts, CRM Contacts, CRM Leads, SFTP and manual uploads. When there is a native integration with a CRM present, the CRM Contact bucket typically contains all contact-related priorities like Get Contacts and Get Deleted Contacts. By adding more than one data source to the same data priority bucket, you are telling Oracle Eloqua that the two sources should be treated as equal to each other, meaning the most recent data will always be updated.
While this data priority order is typical, often times there are specific use cases that require customization to meet business needs. It’s also important to be aware that Bulk API defaults to the highest priority. For webcast apps that write to a Custom Object there are less issues to be concerned with, but if any apps are updating directly to the Contact table to fields shared by native integrations, changes coming from your CRM may not be updating the fields last updated by a Bulk API source.
Ultimately, if you are hearing complaints about data not seeming to update correctly in your Oracle Eloqua system, data priority is the first place to check to find the answers.
Change of Email Address Process
In nearly every instance of Oracle Eloqua, the global system key is email address. Even for the rare cases where the global key in Eloqua was changed (and the valid use cases are very rare to do this), there is still a uniqueness constraint where no two contacts can exist in Oracle Eloqua with the exact same email address. For this and many reasons, it’s very important that you’ve taken a close look at how each of your integration sources is managing the process when an email address is changed.
One option for managing this situation is to use an outside system that generates a form submission which captures the old and new email addresses, posts to an Oracle Eloqua-hosted form, and the form processing step of “change email address” handles the update. For flat file integrations, often a two-step file process is implemented to ensure the email addresses are updated before other data gets imported into Oracle Eloqua. For native integrations with Salesforce, history tracking can be turned on for the Email Address field and auto syncs can be set up to handle the processing of the old and new email addresses. For other CRMs natively integrating with Oracle Eloqua, a similar process can be set up that writes the old email to a field only the Eloqua Integration User can see and can be leveraged to handle the email address updates via a custom auto sync.
There are a number of considerations and factors that influence what makes for the best approach. When it’s a form post process, you’ll want to ensure the change email activity is not showing up as the activity of an actual form submission on the contact’s record that could skew lead scoring and other segmentation. To avoid this, remove the “Update Contacts with Form Data” processing step.
Internal Events
All too often organizations are sending more data over to their CRM than is actually necessary, especially Enterprise organizations with millions of Oracle Eloqua contacts. This starts to matter when CRM’s charge their customers based on the amount of data stored in the CRM itself, not based on a per-contact basis like Oracle Eloqua. One of the biggest sources of this over-sending of data is usually found in the Activity Internal Events.
Activity Internal Events are a set of responses and activities that Oracle Eloqua captures a record of – examples include Email Sends, Form Submissions, and Website Visits. For each type of activity, you can choose which activities to enable and leave disabled, and you can add a number of different external calls that write tasks to your CRM or perform other actions when the enabled activity is captured.
Activity internal events “fire” when the activity is captured in the system (unless put on a set delay), and filters cannot be added to the mapped external calls. What this means is if your lead model is create-only unique where contacts in Oracle Eloqua only exist as a Contact or Lead (not both) in CRM, all external calls “stacked” in the internal event will fire, with the expectation that either the Contact or Lead call version will fail to write to CRM. This is important to note as we get to the final topic below: Failed calls and error review.
Often times organizations will have most of these Activity Internal Events enabled, constantly trying to send tasks and data to your CRM. For large enterprise organizations sending millions of emails and capturing millions of website visits, this can result in a lot of data being written over to CRM, and can result in various processing delays. Check dependencies and usage of this data in your CRM, and unless it’s specifically needed, best practice is to disable the Email Send and Website Visit internal events. If sales needs visibility into these activities, Oracle Eloqua provides various sales enablement tools like Profiler that provide this activity information in an easy-to-use interface directly inside your CRM.
Failed Calls and Error Review
As mentioned above, often times stacked calls in a create-only unique configuration will result in an expected failed call, but in other scenarios a failed call means your data did not write over to CRM and it’s important to understand why. Under the Integration Status Reporting, you can drill into Failed Updates either by External Call or by Error and review the details behind the most common failures and use this as a launching point to dig into why the updates are not being sent from Oracle Eloqua to CRM.
Whether you are just starting to work with Oracle Eloqua integrations or have been working in this space for years, often taking a step back and reviewing some of the primary opportunity areas for enhancement can yield efficiencies in your data management within Oracle Eloqua, and help improve data quality overall.
Where are the first places you look when trying to troubleshoot your integration? I’d like to hear from you, please contact us with questions or comments!
