Integrating 1 Instance of SFDC to 2 Instances of Eloqua

May 7, 2019

Integrating one instance of SFDC with unique, shared contact and lead objects into two instances of Eloqua.

Scenario: 

We are currently using one instance of SFDC as a sales platform for two different business areas but both business areas have their own instance of Eloqua:

There are certain inherited issues that need be addressed and several business requirements that need to be satisfied:

  • Issue 1. Contacts need to be shared across business units because of the opportunity of cross sell.
  • Ussie 2. Each business unit has its own sales team and their own lead que.  This needs to be maintained.
  • Issue 3. There are duplicate contacts and leads in the system.

Eloqua / SFDC integration acceptance criteria:

  • Contacts and business area specific leads can be viewed by sales team in SFDC.
  • Marketing can only have access to contacts that their business unit owns in Eloqua.
  • Eloqua will not create duplicate leads (or contacts).

 

Executive Summary (Solution Overview)

Salesforce is going to have two new fields added to both the lead and the contact object.  These will denote business unit ownership.  SFDC contacts will be shared across business unit but each business unit will get their own SFDC lead.

Contacts and leads (business unit specific) are to be unique and a de-duping exercise will take place to reconcile duplicates.  Validation rules will be created in SFDC to prevent SFDC users from being able to create duplicate contacts and leads.

All contacts will be synched across both instances however if a business unit does not have legitimate ownership of an Eloqua contact.  That is they do not have their own business unit flag attached then the Marketing team will not be allowed to market to the contact directly from Eloqua until such time as they become known through filling out a business unit specific form, attending a business unit specific webinar, etc.  This will be achieved through Eloqua contact level security.

Eloqua contact level security will apply a business unit label to Eloqua contacts.  This business unit specific label will also be made accessible from the different business unit user settings.

The overall solution will like this for each business unit.

The following actions will need to happen in order to fulfil the business requirements:

Eloqua updates and changes

  • Create two new checkbox fields on the Eloqua contact which will be used for business ownership
  • The inbound autosych SFDC – Get Contacts will be set to pull in all SFDC Contacts and set their SFDC contact ID
  • The inbound autosynch SFDC – Get Leads will be updated so that it will lonely pull in leads that have the relevant business unit flag set
  • Eloqua contact level security labels will be created for both business units
  • An Eloqua contact level security program will be created to assign business units to all Eloqua contacts
  • Eloqua user permissions will be updated with their respective Eloqua contact level security label so the business unit’s marketing department only have access to their legitimate Eloqua contacts

SFDC updates

  • Deduplication process for contacts will take place
  • Create two new checkbox fields on the SFDC lead which will be used for business ownership
  • Create two new checkbox fields on the SFDC contact which will be used for business ownership
  • Validation rules will be put in place

 

Technical solution

The technical solution will require six changes or updates:

  • SFDC contact object updates
  • SFDC lead object updates
  • Eloqua contact field updates
  • Eloqua contact level security
  • Inbound Integration updates: SFDC – Get Contacts
  • Inbound Integration updates: SFDC – Get Leads, SFDC – Get Converted Leads
  • Outbound Integration update: SFDC – Create Leads, SFDC – Update Leads
  • Outbound Integration update: SFDC – Update Contacts
  • Program builder: SYSTEM_SFDC_SYNCH

 

Business unit ownership

If a contact belongs to a business unit in SFDC then the checkbox will be ticked and these two fields integrated both ways to both instance of Eloqua.  This allow us to utilize contact level security (CLS) in Eloqua in so that marketers only have access to the contacts they can market to. 

By bringing both contacts and leads into Eloqua we will ensure that even if an SFDC contact or lead is not know to a business unit yet we will still have the correct SFDC contact and SFDC lead ID set.  When (if) a contact engages for the first time with a business unit we will stamp them with business unit ownership allowing marketers to have access to them.  This will ensure that the unique SFDC lead or contact ID is already set so we do not create duplicate leads or facilitate duplicate contacts in SFDC. 

SFDC contact object updates

The SFDC contact object will have two checkboxes added to it:

Field name

Type

Value (if checked)

Business unit 1

Checkbox

TRUE

Business unit 2

Checkbox

TRUE

 

These fields will both be checkboxes and if checked the value will be TRUE.  The fields will be read only for SFDC users

 

SFDC lead object updates

The SFDC lead object will have two checkboxes added to it:

Field name

Type

Value (if checked)

Business unit 1

Checkbox

TRUE

Business unit 2

Checkbox

TRUE

 

These fields will both be checkboxes and if checked the value will be TRUE.  These fields will be read only for SFDC users.

 

Eloqua contact field updates

The Eloqua contact record will have three new fields added to it:

Field name

Type

Value (if checked)

Business unit 1

Checkbox

TRUE

Business unit 2

Checkbox

TRUE

Lead status

Picklist

Open

Lead status

When marketing from a business unit generate a lead, the appropriate lead status will get set so it will get picked up by the correct lead queue using rules in SFDC.  When a marketing lead is getting pushed through to SFDC from Eloqua we will set the lead status to open.  This will happen just after the out bound integration point for associate lead with campaign.  Once this has been set an update rule will remove the lead status so we do not erroneously set the lead status as open thus pushing them into a call queue for no reason.

Both create and update lead will be set in Eloqua to trigger autoassign rules.  Autoassign rules in SFDC will place leads into the appropriate lead queue based on business unit ownership and lead status.

Eloqua contact level security

Eloqua will have contact level security set up.  Contact level security allows you to use labels to manage access to contacts in the Eloqua database.  We will only allow marketers to have access in Eloqua to the contacts that their business area owns.

Contact Level Security (Eloqua)

Contact security labels

We will need to create a security label category in Eloqua and then assign two labels, one for each business unit.

Contact security category

Contact security label 1

Contact security label 2

Business Unit

Business unit 1

Business unit 2

 

Contact level security program

A contact level security program will need to be created in Eloqua.  This is the program which will assign the correct contact   The contact level security program will have 7 steps.

Contact level security program steps:

Contact level security step

Step Action

100. Start

Listener:

Contact Creation, Contact Field Updated

11. Clear all Labels

Clear all labels

BU = 1?

Contacts whose “BU: 1” field equals “TRUE”

120. Stamp 1

Add Label “1”

BU = 2

Contacts whose “BU: 2” field equals “TRUE”

130. Stamp 2

Add Label “2”

999. End CLS

Wait: 0.1 Hours

 

 

Inbound Integration updates: SFDC – Get Contacts

Contact level security program entrance from SFDC (SFDC -> ELQ)

Contacts will automatically get pushed through the contact level security program when they have been updated or created in SFDC when they picked up by the inbound integration autosynch SFDC – Get Contacts.  Once they have gone through Eloqua contact level security program they will have the correct security labels assigned.  If the contact is legitimately owned by a business unit then they will be made available to marketing.

The integration will need to have the following new fields mapped:

SFDC field

Eloqua field

Business unit 1

Business unit 1

Business unit 2

Business unit 2

If a contact is not owned by a business unit we will still have the contact ID stored in Eloqua so if and when a contact becomes legitimately owned then we will be able to stamp that contact ownership and push it, plus any other information over to the SFDC contact in the outbound integration point SFDC – Update Leads.

Inbound Integration updates: SFDC – Get Leads, SFDC – Get Converted Leads

The inbound integration will only import SFDC leads that are owned by the business unit.  When they get imported they will get sent through the Eloqua contact washing machine in exactly the same manner that SFDC contacts were.  Just like with SFDC contacts they will then be made available to marketers in Eloqua.

The only update that will need to take place is updating the filter on the transfer values within Eloqua to ensure that we are only pulling in SFDC leads that are owned by the business.

The filter details for the transfer values on:

SFDC – Get Leads:

SFDC lead fields

Operator

Expression

Last Modified Date

Great than or Equal to

Last Successful Upload

Email

Equals

*@*

Converted

Equals

False

Business unit 1

Equals

TRUE

N.B. The filter type is set to AND

 

SFDC – Get Leads:

Transfer values:

SFDC lead fields

Operator

Expression

Last Modified Date

Great than or Equal to

Last Successful Upload

Email

Equals

*@*

Converted

Equals

False

Business unit 1

Equals

TRUE

N.B. The filter type is set to AND

Field mapping:

SFDC lead field

Eloqua field

Business Unit 1

Business Unit 1

SFDC – Get Converted Leads:

Transfer values:

SFDC lead fields

Operator

Expression

Last Modified Date

Great than or Equal to

Last Successful Upload

Email

Equals

*@*

Converted

Equals

TRUE

Business unit 1

Equals

TRUE

N.B. The filter type is set to AND

Field mapping:

SFDC lead field

Eloqua field

N/A

N/A

Outbound Integration update: SFDC – Create Leads, SFDC – Update Leads

The outbound integration points for updating and creating SFDC leads will be changed so as to map the outbound field with contact ownership.  We will also map the field for lead status and set it to open.  This way SFDC auto-assign rules can kick in and push contacts into the correct lead que.

Eloqua field

SFDC lead field

Value

Business unit 1

Business unit 1

TRUE

Lead status

Lead status

Open

Outbound Integration update: SFDC – Update Contacts

The outbound integration points for updating contacts will be changed so as to map the outbound field with contact ownership.  We will also map the field for lead status and set it to open.  This way SFDC auto-assign rules can kick in and push contacts into the correct lead que.

Eloqua field

SFDC contact field

Value

Business unit 1

Business unit 1

TRUE

Program builder: SYSTEM_SFDC_SYNCH

The outbound integration program will need to be changed so that it accommodates point of interest unique.  The outbound program will be updated to accommodate having individual leads and shared contacts.

Program workflow:

SFDC integration program steps

Program Step

Description

100. Start

No Action: Pass Through

Is Contact Owned by Business Unit?

Contact Field Comparison: Business Unit X is equal to TRUE

Has SFDC ContactID?

Contact Field Comparison: SFDC Contact ID is equal to ?*

110. Update Contact in SFDC

Run Integration Event: SFDC – Update Contact

Has SFDC CampaignID?

Contact Field Comparison: Last SFDC Campaign ID is equal to ?*

120. Update Campaign in Contact

Run Integration Event: SFDC – Associate Contact with Campaign

130. Start Lead Path

No Action: Pass Through

Has SFDC LeadID?

Contact Field Comparison: SFDC Lead ID is equal to ?*

140. Update Lead in SFDC

Run Integration Event: SFDC – Update Lead

Has SFDC CampaignID?

Contact Field Comparison: Last SFDC Campaign ID is equal to ?*

150. Update Campaign in Lead

Run Integration Event: SFDC – Associate Lead with Campaign

160. Remove from Contact Group

Remove Contacts from Contact Group: SYSTEM CRM Errors – No Last Name or Company

Blank Last Name of Company?

Contact is in Contact Filter: SYSTEM – CRM Error

Has Campaign ID?

Contact Field Comparison: Last SFDC Campaign ID is equal to ?*

180. Create Lead with Campaign Association

Run Integration Event: SFDC – Create Lead and Associate with Campaign

190. Create Lead with NO Campaign Association

Run Integration Event: SFDC – Create Lead

Lead Created?

Contact Field Comparison: SFDC Lead ID is equal to ?*

999. End Program

Remove from Program

 

shares