Whether you are working in an established instance of Oracle Eloqua and preparing to integrate with a CRM for the first time, or your busily implementing Oracle Eloqua and integrating simultaneously, there are many decisions ahead of you – and making the correct ones help ensure your integration meets the needs of both marketing and sales.
In this blog post we’ll focus on some of the key considerations and pitfalls to be aware of as you plan for your integration journey. For clarity, when I refer to “integration” in this blog, I’m referring to integrations with Oracle Eloqua and a CRM that Oracle Eloqua natively integrates with via the integration panel. A list of those CRMs can be found here at Oracle’s Help Desk.
Use Cases and Relevant Fields
Your CRM likely contains a wealth of information, making it overwhelming to figure out what data needs to be brought into Oracle Eloqua. Generally speaking, information needed for segmentation, personalization, scoring, routing and reporting are the fields to focus on. One of the most important and often overlooked steps, however, is documenting all of the marketing and sales use cases that the Oracle Eloqua to CRM integration needs to support.
As a first step, work with relevant team members to document the different ways you’ll use the data. A simple example: “Marketing needs to personalize the To and From name of emails based on a client’s account manager using signature rules.” This indicates it is important to have information in Eloqua that both identifies current clients as well as who their account managers are.
From simple to more complex, having a clear understanding of your use cases will help to solidify what information to integrate.
Data Model
Once we begin to understand which fields we need to bring in from CRM and how they will be used, we also need to understand how this data is stored and associated to contacts or leads inside your CRM and the differences in how that can translate into Oracle Eloqua’s data model.
Oracle Eloqua has three primary tables – contacts, accounts, and custom objects. While there is only one contact and account table, you can have multiple custom object tables that support either a one-to-one (one custom object record to one contact or account) or one-to-many (many custom object records to one contact or account) relationships. Oracle Eloqua does not currently support a many-to-many relationship (one contact being associated to multiple accounts or one custom object being associated to multiple contacts).
In order to have relevance for most purposes like segmentation, each custom object record must be mapped back to one contact or one account and they cannot be mapped to both at the same time – meaning it cannot be used as a type of join to link multiple tables together inside Oracle Eloqua.
Depending on your particular CRM, you can set up various auto syncs that will pull data from your CRM into Oracle Eloqua and store it into contacts, accounts, or custom objects. If you are using Salesforce as your CRM, you can pull up to one table deep of related tables in the same sync. As a simple example, you can pull associated account attributes into the contact table at the same time you pull contact data through your Get Contacts auto sync. For all other CRM’s, each auto sync can only pull from one table in CRM at a time. In all cases, auto syncs can only write to one table in Oracle Eloqua at a time. If you need account data on both the contact and account tables in Oracle Eloqua it will take a minimum of two auto syncs to accomplish.
CRM’s support relational tables where a reference object, for example a table of the products you sell and whether they have a subscription license or perpetual license, can be associated back to other objects using values common to each. In this example, my contact may be associated to an opportunity, the opportunity has a code that represents a product, and that code matches the attributes or description of the product in my products table. For my marketing use case, if I need to target contacts based on those associated with an opportunity with a product that has a subscription license, referencing that many tables in CRM back to Oracle Eloqua in a useable way can be tricky.
While this example may be a bit more complex, ultimately, once you have a clear understanding of what data you need and how it will be used, there are a variety of tactics that can be applied to structure the data the way you need it in Oracle Eloqua.
Existing Versus New Instance of Eloqua
Another consideration is whether you are integrating with a brand new instance of Oracle Eloqua, or an existing instance that already has contact and other information stored. In the first case, if the source of your contact data will be your CRM, typically there is little risk in integrating directly into your production instance of Oracle Eloqua. If you pull all the data in and there is an issue, it’s reasonably simple to clear it out and start over again.
By contrast, if you are integrating with an already established instance, best practice is to first thoroughly test the integration in an Oracle Eloqua sandbox to help ensure existing operations and data in Oracle Eloqua are not corrupted. An important note is that Oracle Eloqua sandboxes are one directional, meaning you can replicate your production instance to the sandbox instance, but you can’t push changes from sandbox back down to production like a typical CRM sandbox. For this reason, it’s best practice to build the integration in your production instance, ensure everything is disabled, then replicate to sandbox and test what you built there – otherwise you are not really testing what you just built.
The other consideration that becomes more important when integrating with an existing instance is data priority, particularly if you have already been using a flat file integration via an SFTP. As described in more detail in my last blog post, “What to Look for When Conducting a Review of Your Integration,” data priority helps decide what data “wins” on a field-by-field basis between what was already in Oracle Eloqua and what is coming in via the new CRM integration or other sources. Data priority also come into play when we talk about same-email duplicates in your CRM.
Same Email Duplicates
Except in rare cases, the global key for Oracle Eloqua is email address, and even in cases where this has changed, Oracle Eloqua has a uniqueness constraint whereby no two Oracle Eloqua contacts can have the same email address. This is very different from CRM systems where same-email duplicates are not only possible, but depending on your lead management model, it might be expected and commonplace. Before we get into lead management models, let’s first get an understanding of how same-email duplicates affect Oracle Eloqua.
While customization is possible, typically when auto syncs are pulling from your CRM and writing to Oracle Eloqua, email address is the mapping key. When CRM records with the same email address are imported into Oracle Eloqua at the same time, duplicates are merged into a single, complete record, with the highest ASCII value retained on a field-by-field basis. In ASCII methodology, Z is higher than A, 9 is higher than 1, letters are higher than numbers and lowercase is higher than uppercase. In the example below, the first table shows two different contact records in CRM and the second table shows the resulting record in Oracle Eloqua:
Unless your lead management model specifically requires it, removing and controlling same-email duplicates in your CRM will help with data quality in Oracle Eloqua. Try as you may to enforce dupe blocker and other methods, same email duplicates have a way of sneaking in. For perspective, if a same email duplicate exists in CRM but only one of the two is actively being managed and edited, the auto sync will pull just the modified record. Additionally, setting your Get Contacts data source to have a higher priority than your Get Leads data source helps ensure if you have a same email duplicate on the contact and lead table in CRM, the Contact data will win out in Oracle Eloqua.
Lead Management Model
Another important decision will be around which type of lead management model you are looking to implement. This will be a joint decision between marketing and sales, and is mostly dependent on the way your sales organization is structured and how they receive and manage leads. Do you have an inside sales team ready to qualify leads with a 5 minute SLA? Are you aligned regionally or vertically? If someone responds to two completely different product offers, will the same salesperson contact them or is it handled by different sales reps?
The answers to these questions will help determine which lead management model you need to implement in Oracle Eloqua. The three most common options are described in the image below:
Based on your business’ unique sales structure and needs, the logic for your CRM Update Program (the primary way that Oracle Eloqua updates contacts and creates or updates leads) will need to be built to support your individual sales structure.
Conclusion
While there are many things to consider when getting ready to integrate with Oracle Eloqua, these are a few of my favorite topics to review with clients. What challenges have you faced when trying to integrate and how have you solved them? I’d love to hear from you in the comments below!
