It’s not uncommon for companies to have more than one Oracle Eloqua instance. How can that be? That seems odd. Actually, we see it more than you would think.
Sometimes, there’s a legitimate business reason for this; an organization has a marketing department that’s divided into teams dedicated to particular products, verticals, or geographies. In order to customize the platform to meet the specific needs of each team, it makes sense to have multiple instances of Oracle Eloqua.
Other times, this happens out of what I call “sheer scale blindness.” Large organizations aren’t always aligned across business units. Their size and complexity means different teams are working independently without always knowing what others in the company are doing. Multiple marketing automation platforms get purchased, and sometimes multiple Oracle Eloqua instances exist within an organization without anyone knowing about it.
Either way, having multiple instances of Oracle Eloqua adds complexity when you want to integrate them with a singular CRM instance. The good news is, it can be done.
To begin, let’s review some integration basics, and then we’ll look at some of the challenges that come with integrating between one CRM and multiple instances of Oracle Eloqua.
As explained in this blog post, discussing integrating multiple CRM instances with one Oracle Eloqua instance, there are generally three ways to move data into or out of Oracle Eloqua:
- Direct Connect – an integration option that is native to the UI (in the Integration area of Oracle Eloqua). This provides an “easy” way to integrate with CRM platforms such as Salesforce.com, Oracle OnDemand and Microsoft Dynamics
- Custom API – an integration built using custom code or an integration middleware tool to connect to the published APIs of Oracle Eloqua and the CRM system
- Push/Pull – file-based imports and exports pushed to an SFTP server and loaded into Oracle Eloqua, pulled into a CRM, or both.
Once you’ve determined the preferred method for moving data between the platforms, there are some unique considerations that specifically apply to integrating a singular CRM with multiple Oracle Eloqua instances.
If the goal is to write data to CRM from Oracle Eloqua (and vice versa), the first consideration pertains to managing Oracle Eloqua IDs.
I’ve seen it often; there are contacts that exist in more than one Oracle Eloqua database with the same email address. Each Oracle Eloqua instance assigns a record a unique (and different from the other instances) Contact ID. In order for the CRM to know which Oracle Eloqua instance to write data to, there needs to be a separate ID field on the CRM record for each Oracle Eloqua instance. This allows CRM to differentiate which Oracle Eloqua instance the record exists in so that CRM knows where to send any data it needs to write to Oracle Eloqua.
In addition to the scenario of having multiple Oracle Eloqua Contacts IDs for one email address, also be aware that Oracle Eloqua uses unique email addresses for Contacts. If your CRM doesn’t have this same constraint (whereby the same email address can exist on more than one record), this can cause problems when bringing CRM data into Oracle Eloqua (or vice versa.)
Which record in your Oracle Eloqua instances trumps all others? On the flip side, which CRM records’ data gets sent to which Oracle Eloqua instance? What data wins? Before beginning this type of integration, it’s imperative to analyze your CRM data and the data between the Oracle Eloqua instances to see to what extent records have duplicate emails.
Another consideration to think about, which is specific only to the custom API integration scenario, has to do with matching up activity from multiple Oracle Eloqua instances back into a single CRM record.
When pulling activity data from Oracle Eloqua using the Bulk API, it’s not currently possible to extract related Contact fields along with the activity data, like the CRM ID for the record. You will need a strategy to match based either on email address or the Eloqua Contact ID specific to each instance. When pulling data using the API, some activity data returns the Eloqua Contact ID and some returns just the email address on the record. In this situation, I recommend getting assistance from someone who has a strong grasp on how the Oracle Eloqua API’s work to avoid creating a huge data mess.
For most native integration scenarios, you don’t normally need to worry about the potential field matching concerns. In native integrations, the activity queue typically matches on CRM ID in order to send a Contact’s activity data to the appropriate CRM record.
After all that, if you’re still thinking of going down the route of integrating multiple Oracle Eloqua instances with one CRM, here are my recommendations:
- Audit your CRM database for duplicate email addresses
Either clean and dedupe those records or design the integration to accommodate duplicates. (Side note: this recommendation applies to any integration). - Identify duplicates across instances.
Assess your Oracle Eloqua instances to identify if there are duplicate records across instances (the same email address exists across one or more databases). Define a solution for CRM to know which Oracle Eloqua instance to send back to, if applicable. - Document
Similar to #1, this recommendation applies regardless to the complexity of the integration. It’s imperative that there is documentation of how objects and fields are mapped, what data trumps what, what triggers are set up to send data to where, etc. - Monitor
Don’t wait for an error notification or your CRM admin to raise their hand. Set up a regular cadence to review and test that your integration is working as expected.
In closing, it’s definitely possible to integrate a single CRM instance to multiple Oracle Eloqua instances (and there are many companies who have already done so). However, it does require some additional considerations to ensure that no wires get crossed. It always helps to have a clear plan in place for what data needs to be sent to each instance, and to document very clearly how the data will be flowing into and out of each instance. Advanced planning will save many headaches down the road, especially as things change within your organization.
I would love to hear feedback from anyone who’s done this type of integration before. Are there other “gotchas” people need to consider? Share your thoughts in the comments section below.
