Skip navigation

How often does your lead generation team waste cycles identifying and qualifying leads that are actually just net new contacts that have entered your Eloqua Database? Wouldn’t it be great if you could identify those net new customer contacts and skip the whole lead stage altogether? How much would your account reps appreciate their new customers not getting included in prospect marketing communications and jumping right into customer nurturing?


Let me walk you through how we combined Salesforce formulas, and workflows with Eloqua’s match and update rules to skip create a process that allows Eloqua contacts who have a work email to skip the lead process and be created as a contact.


First off, this whole process relies on the company’s corporate email domain, so you need to create a Salesforce account and Eloqua company field to store that Email domain for example and add that to your account layouts.


Now add the fields to your scheduled auto syncs to push that value into Eloqua.


What if you aren’t sure what your shat your accounts email domain is, well if that is case we can make an educated guess. Most companies have an email domain that is very similar to their website so for situations where you aren’t sure what that value is we used a combination of formula field and workflows to populate the Domain field with a stripped out version of their website.


We created a second field called Domain2 which was a formula field with the formula MID(Website, FIND('www.', Website, 1)+4, (LEN(Website) - FIND('www.', Website, 1)+4)). This formula converts to which you can use to match against company email domains.


Next we used a workflow that ran every time an account was edited and had both the website field populated, and the domain field blank. Each time this workflow is triggered, it takes the domain 2 value and adds it to domain for syncing to Eloqua. Now you have a best guess match until you find out what the real domain is if it happens to be different.


Next we move to Eloqua. Once your synchs have run, you should have the domain field you created on your company record populated. You will then need to create the following:

1 A match rule to match contact domains with company domains

2 A match rule handler set to update Contact SFDC AcciuntID with the value in the Company AccountID field

3 A new Create Contact Internal Event and External call if not already created

4 New program steps to run the evaluations


First the match rule, go to you contacts tab and select data tools > match rules. Create a new match rule that matches the contacts email domain to the Company’s email domain field as seen below.

Match Rule.png

Now add an exclusion criteria and select the Company domain field is not equal to blank to ignore any companies without a domain.


As always save your work.


Next add a Handler set that affects the members in Program Builder Step or Group from which the Rule is run and performs a field update a field with field values from matched records.


This is what you will use in your program builder step to evaluate if the contact has a domain that matches the email domain of a company already in your database and give that companies SFDC account id to the Eloqua contact. This will allow you to create a SFDC contact and identify which account it should belong to.


P.S. if it turns out your accounts use multiple email formats, this will also need to be repeated with a new field and match/update for each version of the email domains they use, but only if you are feeling extra fancy.


Next you need the components that will actual do that creation. If you don’t already have the internal events and external calls setup, you’ll need to create them. First you need a new internal event. Go to Settings > Setup > Integration > Outbound > Internal Events > Contact > Custom Contact Events and then of course Create new Custom Event. Man that must be the world’s longest click-stream. Once you do that, you will need to create the external call as well.

Event Mapping.png

Create your new external call using the external call wizard accessible from the carrot beside the name in your new event on the left hand side.


Complete your call selecting create for your action, contact for your entity and SFDC Contact ID to store SFDC Entity ID.


Map all your necessary fields, I recommend matching your update contact call for guidance if you aren’t sure what to map.


Then perform your testing as you would any new SFDC Push.


Now that you have the ability to match contacts to accounts, and the ability to create those contacts directly in the SFDC account, you need to have the program that uses these new assets and control. We decided to use our CRM update program so that it will check any new Eloqua contact about to go over to Salesforce. We built out the checks to run after first making sure that there isn’t already a contact or lead ID on the Eloqua contact. Once the contact fails the “has lead id” decision rule, we put them right into the match accounts rule. The match rule is set to run against companies and match members of the accounts group. Then run the domain match rule and handler set as shown below.


Then we add a decision rule to check if the contact has had their account ID populated, if yes, create the contact in Salesforce if no, create a lead as normal.


Now you should be able to skip the whole lead process if needed for contacts you can already match to existing clients.


Now I know this doesn’t work if the contact uses personal emails, or makes a mistake with entering their email, but will greatly reduce the number of contacts that will need to be manually checked by your inside team for new contacts at existing accounts.

The nice folks at Gigya tried to make this as easy as possible for me; once I'd created a couple of CDOs, some contact fields and sent them over the Eloqua names, they started to send the data across and my marketing guys are all ready to start sending emails to these users.


My first integration is complete

Filter Blog

By date: By tag: