Integrating 1 Salesforce instance with 2 Eloqua instances

Scenario: one Salesforce org, two Eloqua instances

In this scenario a single Salesforce instance is used as the sales platform for two different business areas. Each business area has its own Eloqua instance. Sales wants shared visibility of contacts and cross sell potential. Marketing wants clean ownership and safe access.

Click to open in lightbox

Inherited issues

• Issue 1. Contacts need to be shared across business units because there is cross sell opportunity.
• Issue 2. Each business unit has its own sales team and its own lead queue. That separation must be preserved.
• Issue 3. There are duplicate contacts and leads already in the system.

Integration acceptance criteria

• Contacts and business area specific leads can be viewed by the right sales teams in Salesforce.
• Marketing can only access contacts that their business unit legitimately owns in Eloqua.
• Eloqua will not create duplicate leads or facilitate duplicate contacts in Salesforce.

Executive summary: solution overview

The pattern is simple. Salesforce owns the master contact and lead objects. Business unit ownership is modelled as explicit flags. Eloqua uses those flags together with contact level security to control what each marketing team can see and update.

Click to open in lightbox

At a high level:

• Salesforce gains two new ownership fields on both the Lead and Contact objects. These denote business unit ownership.
• Contacts in Salesforce are shared across business units. Each business unit has its own leads and lead queues.
• A deduplication exercise cleans up existing duplicates and validation rules prevent new ones.
• All Salesforce contacts are synced to both Eloqua instances. Leads are synced only to the relevant Eloqua instance for that business unit.
• Contact level security in Eloqua uses ownership flags to ensure that each marketing team only sees the contacts they are allowed to market to.
• Inbound and outbound autosynchs pass ownership flags and lead status in a controlled way so that auto assignment rules in Salesforce can place leads into the correct queues.

Business unit ownership model

Business unit ownership is represented as boolean fields on both the Salesforce and Eloqua side. If a contact belongs to Business Unit 1, the BU1 flag is true. The same pattern applies to Business Unit 2.

These fields are synchronised between Salesforce and both Eloqua instances. This allows Eloqua to implement contact level security and lets each marketing team see only the contacts their business unit owns, even when the underlying Salesforce contact is shared.

Salesforce design

Eloqua design

Eloqua contact field updates

The Eloqua contact record gains three important fields to match the ownership model and control lead routing.

Field name	Type	Value if checked / example
Business Unit 1	Checkbox	TRUE
Business Unit 2	Checkbox	TRUE
Lead Status	Picklist	Open

When marketing in a business unit generates a lead, the correct Lead Status is set so Salesforce auto assignment rules can push that lead into the right queue. After the lead is processed, an Eloqua update rule clears the Lead Status so that you do not accidentally push contacts into a call queue later without intent.

Click to open in lightbox

Eloqua Contact Level Security (CLS)

Contact level security in Eloqua allows you to use labels to control access to contacts. In this design it ensures that marketing from Business Unit 1 only sees contacts that BU1 legitimately owns, and the same for Business Unit 2.

Click to open in lightbox

Contact security labels

Create a contact security category in Eloqua with one label per business unit.

Contact security category	Label
Business Unit	Business Unit 1
Business Unit	Business Unit 2

These labels are then linked to user profiles so that BU1 marketers only see BU1 contacts and BU2 marketers only see BU2 contacts.

Contact level security program in Eloqua

A dedicated CLS program assigns the correct labels based on business unit fields. The program listens for contact creation and field updates then stamps the right label.

Click to open in lightbox

CLS program steps

Inbound integration: SFDC to Eloqua

SFDC - Get Contacts

The inbound autosynch SFDC - Get Contacts brings all Salesforce contacts into Eloqua and sets the Salesforce Contact ID. This ensures that even if a contact is not yet owned by a business unit you still have the correct IDs ready when they do engage.

Click to open in lightbox

Map the ownership fields so they are always in sync.

Salesforce Contact field	Eloqua Contact field
Business Unit 1	Business Unit 1
Business Unit 2	Business Unit 2

SFDC - Get Leads and SFDC - Get Converted Leads

Leads should only flow into an Eloqua instance if they belong to that business unit. The inbound integrations for leads are filtered accordingly.

Click to open in lightbox

SFDC - Get Leads transfer values

SFDC Lead field	Operator	Expression
Last Modified Date	Greater than or equal to	Last Successful Upload
Email	Equals	*@*
Converted	Equals	False
Business Unit 1	Equals	TRUE

Filter type: AND

SFDC - Get Converted Leads transfer values

SFDC Lead field	Operator	Expression
Last Modified Date	Greater than or equal to	Last Successful Upload
Email	Equals	*@*
Converted	Equals	TRUE
Business Unit 1	Equals	TRUE

Filter type: AND

Mapping for the inbound lead ownership flags mirrors the contacts mapping.

Outbound integration: Eloqua to SFDC

SFDC - Create Leads and SFDC - Update Leads

The outbound integration for leads must pass back ownership and lead status so that Salesforce rules can route leads into the correct queues.

Eloqua field	Salesforce Lead field	Value
Business Unit 1	Business Unit 1	TRUE
Lead Status	Lead Status	Open

Click to open in lightbox

Both Create Lead and Update Lead in Eloqua should be configured to trigger Salesforce auto assignment rules. Auto assignment rules in Salesforce then place leads in the correct queue for each business unit based on ownership and status.

SFDC - Update Contacts

The outbound integration to update contacts sends ownership information back to Salesforce so Contact records remain aligned with the reality in Eloqua.

Eloqua field	Salesforce Contact field	Value
Business Unit 1	Business Unit 1	TRUE

Click to open in lightbox

Program Builder: SYSTEM_SFDC_SYNCH

The outbound program SYSTEM_SFDC_SYNCH orchestrates when to update contacts, create or update leads and associate records with campaigns. It respects business unit ownership and avoids creating duplicates.

Click to open in lightbox

Program steps at a glance

Governance, risks and testing

Testing checklist

• Prepare a small set of test contacts and leads per business unit with known ownership and clear test labels.
• Verify that SFDC - Get Contacts and SFDC - Get Leads bring in the right subset of records into each Eloqua instance.
• Confirm that the CLS program assigns the correct labels in Eloqua and hides non owned contacts from each BU marketer.
• Trigger outbound flows and validate that Update Contact, Create Lead and Update Lead apply the correct ownership flags and lead status in Salesforce.
• Check auto assignment rules in Salesforce to ensure leads land in the correct queues for each business unit.
• Review a handful of records all the way from form submission or campaign activity in Eloqua through to lead queue in Salesforce.

Conclusion

Integrating one Salesforce instance with two Eloqua instances is very achievable as long as ownership and governance come first. With clear business unit flags, contact level security and well defined autosynch rules, both marketing teams can run fast without creating duplicates or violating data ownership.

The pattern in this article gives you a blueprint. You will still need to tune it to your objects, queues and processes, but the core idea remains the same. One truth in Salesforce, controlled views in Eloqua.