I have worked with a large amount of clients in my career and one aspect of Eloqua integration that a lot of companies struggle with is Closed Loop Reporting (CLR).
This is crucial for organisations who want to see which campaigns are generating the most Return on Investment (ROI).
The company in this case study clientX is no exception. It was highlighted to me that their CRM integration was set up and configured quite a while ago, and despite having some very technical Eloqua users they required some additional assistance in getting their CLR functioning.
This article outlines what was investigated, conclusions drawn & what components were changed or built to get it functioning.
This aspect of Eloqua is detailed and explained in multiple Luminary courses: most notably the B2B: System Integration course & the B2B: Closed-Loop Reporting course as well as in the supplementary Eloqua 10: Closed-Loop Reporting Overview.
Warning: Eloqua/CRM integration is a complex area and changes to the existing setup in a production instance should be carefully considered and only changed if you understand the implications of the changes. Failure to do this can adversely affect an already functioning CRM integration.
If you do not feel comfortable making changes here, raise a support request through My Oracle Support so that one of Oracle’s Support personnel can assist you.
- Audit the existing CRM integration.
- Build new components or fix existing ones so that the revenue fields within Eloqua campaigns automatically pull data from the CRM.
I tested to see if after campaigns were created, whether they were populating with the CRM Campaign ID.
I created a dummy campaign in Eloqua & checked the ‘sync with CRM’ checkbox in advanced settings. I saved it and obeyed the ‘get a coffee’ rule.
What I observed is that the equivalent campaign in the CRM was being created and a CRM campaign ID was being pulled back into Eloqua correctly. I could see this in the advanced settings.
Result: It verified that the Eloqua user within the CRM was valid and working, permitting campaigns to be created & thereafter retrieving the CRM ID.
The get a coffee rule.
I could see that the synchronisation did appear to be working, at least in part.
I built a new retrieve Campaigns Autosync + External call by choosing ‘create new Data Source with External call’ from the Create Data sources menu. (I modeled the mapping, filter & other settings on some already existing External calls.)
We tested the External call
Result: No data was pulled through.
I thought that it might be a filter issue and maybe there was a problem with the last updated date criteria in the filter.
Result: No data was pulled through.
As I knew that Eloqua was populating with at least the CRM ID, I tested how far this was working and if the mapping was correct. I added test data into the cost fields on a test campaign & then Tested the Update Campaign External call.
By choosing the Eloqua campaign and then pressing ‘Prepare for test’ it shows you the differing values between the two systems. Once you execute the test Eloqua will show you the modified vales in SFDC (if applicable).
Result: - The values in The CRM updated successfully. This told me that the field mapping was set up correctly and that we were seeing the data flowing from Eloqua into the CRM, but not back.
I decided to revisit the filter analysis on the already existing Get Campaigns Autosync. This revealed that the campaigns were being uniquely matched on the SFDC campaign ID field – NOT the External Campaign ID field as it should have been.
It was also using the 18 character CRM ID, rather than 15 character CRM ID.
I corrected these points and asked ClientX to update the financials in one of the Dummy Campaigns within the CRM to test.
Result: Still no updates into Eloqua.
I set the success AND failure notifications to come to me.
What I discovered from that email is that the autosync was running successfully but excluding my test record every time with a reason of ‘Rejected Records Missing Required Fields’ – this allowed me to start removing the mapped fields one by one until it did finally successfully run & gave me an updated=true in the autosync report.
Result: The autosync report showed that the CRM was now updating Eloqua.
Reviewing the view upload details report Showed the successful mapping of fields after the successful autosynch.Looking in the Campaign fields in the Eloqua Campaign showed the values were pulled from the CRM Successfully.
ClientX was pleased.
They could now get their Sales teams to start completing campaign financials which will loop back into Eloqua allowing reporting on the costs and revenue earned across all their campaigns.
What could I have done differently?
Next time I think I would set up the responses for both success & failures from the outset, - that feedback was instrumental in establishing the last error & resolving it. This coupled with the view Upload report from the autosync might have alleviated some of the back & forth testing & confusion that I had been through.
So what tips can this experience offer the Eloqua users at large who might be having issues with CLR?
- Are you observing the ‘Get a coffee rule’? This will verify if your CRM is receiving the request to create campaigns & sending back the CRM campaign ID.
- Check your External call filter.
- Are you filtering using the Eloqua User ID? – You should be.
- Are you filtering using last modified date? – try removing that.
- In your Autosynch Field mapping, are you uniquely matching on the External CRM ID?
- Is your mapping correct? You can check this by comparing to working External calls or viewing the ‘View Upload’ report from any autosync that runs successfully.
- Are you synchronising on 18 or 15 Character CRM IDs? All objects of the same type should utilise the same ID type, if 18 character fails, try using the 15 character one.
- Set up notifications to come to you upon sync successes and failures, as this will allow you to troubleshoot much more effectively.
Going further - some useful Topliners posts on Closed Loop Reporting: