Oracle Eloqua can integrate with any number of CRM programs or databases. The nature of the integration depends on the native connections available and a client’s unique needs. We’ve integrated Oracle Eloqua instances with hundreds of CRMs, a process that often calls for custom solutions. Microsoft Dynamics CRM is one of the systems that natively integrates with Oracle Eloqua]. However, it does come with some specific challenges.
There are some terminology differences that make integrating with Microsoft Dynamics CRM more of a challenge.
For example, Entity is the term used to describe a record housing a set of fields and data in MSCRM, such as a Lead, Contact, or Account. This is referred to in most other CRMs as an Object, both refer to the same thing.
You’ll regularly hear the term GUID in discussions around MSCRM. This stands for “globally unique identifier.” This is the same as a record’s ID. The GUID is used to identify records, field values and picklist values.
MSCRM has a unique style of managing picklists. Most users are familiar with the “option value” and “option name” in Oracle Eloqua picklists. Many times, the value and name are the same. In MSCRM, the option name is a human-readable label, and the underlying option value is a GUID – easily readable by the system, not so much by its users. One common example of a picklist field and its MSCRM GUID is Lead Source. You may have a value of “Website” as the picklist option name, but in the database, the option value is “4”. You’ll read more about this below.
As we just discussed, MSCRM picklists are managed differently than those in many other CRMs. If a picklist field is used in the integration between Oracle Eloqua and MSCRM, it’s essential to configure the integration using the option values (GUIDs) rather than the option names (human-readable labels).
For example, if a web form submission includes a value of “Website” in the Lead Source field, and writes that value to the Oracle Eloqua contact record. When the external call runs to create or update that record’s corresponding Lead or Contact in MSCRM, the call will fail. This is because MSCRM is looking for a value of “4” – the underlying option value.
You have three options to avoid this kind of integration problem:
- When creating picklists in Oracle Eloqua, verify that the option values mirror the picklist values in MSCRM.
- Incorporate update rules into your lead flow process to take the human-readable value submitted to a contact field, and translate it to a GUID value that’s usable by MSCRM.
- Leverage Oracle Eloqua Autosynchs to support picklist maintenance. This will ensure that any changes to MSCRM picklist values are reflected in the corresponding Oracle Eloqua picklist. We often use this solution for fields with a wide range of values that change frequently, and directly influence how marketers interact with Oracle Eloqua contacts. One example is the Salesperson field. Rather than manually update Oracle Eloqua records with a new MSCRM user ID every time a sales assignment changes, implement an autosynch to draw the user IDs into Oracle Eloqua on a regular basis and add them to a picklist.
MSCRM’s data structure differs significantly from other popular CRMs, such as Salesforce.com (we’ll discuss more of these differences later). Because of this unique setup, additional information is needed for Oracle Eloqua to write values to “lookup” fields on MSCRM entities. Oracle Eloqua must specify which MSCRM Entity is referenced in the call so that the call is directed properly. To guarantee correct mapping, the Entity name must precede the field data being passed.
Another difference between MSCRM and other systems is its managing of activity data. In many CRMs, Oracle Eloqua activity appears on a lead or contact record as a Marketing Activity. MSCRM doesn’t use this record type; as a result, all Oracle Eloqua activities are created as tasks associated to the lead or contact record.
Oracle Eloqua’s standard autosynch filters allow criteria to be entered with all AND operators, or all OR operators. If there is a need for more sophisticated criteria, many CRMs offer the option to create custom SOQL filters to include AND and OR operators. Unfortunately, custom filters are not available for autosynchs from MSCRM. This limitation means an autosynch might draw in more records than intended. To avoid adding unwanted records to the Oracle Eloqua database, it’s common to create a checkbox on the MSCRM entity flagging whether it should be part of the autosynch.
Also unique to MSCRM is that each autosynch is limited to one entity, where other CRMs allow Oracle Eloqua to utilize related entities for inbound synching (from CRM to Eloqua). For example, when Oracle Eloqua is looking at the Contact Entity, it cannot see any related or connected Entities, such as an Account or Opportunity. To link values from related entities to the Oracle Eloqua contact record, we would establish a matching process with the Account, or create a custom object to store the entity data, and map it with the contact record.
Making the Connection
Sound like too much to handle? There are a lot of moving parts, but with a structured approach, integrating Oracle Eloqua with MSCRM can work wonders for efficiency, data quality, and activity tracking between your marketing and sales teams. If you need help with your upcoming integration we would love to help you. Contact us!