Eloqua “recently” (okay, months ago) decided to “encourage” (force) clients to move away from their native integration with Salesforce to the new Eloqua Salesforce integration app. They did this by announcing that, as of February 2021, the native integration would “still work”, but support would no longer be able to help with any issues.
If you’re a marketing ops pro who hadn’t already taken the leap, this news was likely accompanied by a weird mix of excitement and dread. And, If you’re like me and have been working with Eloqua clients for 10+ years, you likely had a…shall we say, interesting relationship with their integration engine.
A relationship that was kind of like your one grandparent. You know which one I mean…the surly one. You know that at one point, Eloqua was the creme of the crop, the one all their frenemies aspired to be like. There was pride in being part of the Eloqua integration crew.
But now, just like your Grandpa Joe, folks who meet the Eloqua integration engine for the first time are a little…confused. Sure, there’s wisdom there, mixed with multiple external calls and auto syncs that give you endless customization, but honestly, it’s not very pretty. Let’s be real: you kind of just tolerate it to be able to enjoy Eloqua’s other snazzy features. (I’m not saying you just tolerate Grandpa Joe. It just takes a certain person to “get” him. We <3 you Grandpa).
This is my long-winded way of saying: the integration engine needed an upgrade, and I was really excited to dive in with my first Eloqua client. In honor of Grandpa Joe, I’m going to share a few (short) sentences on what I liked about the legacy integration, just for context.
The legacy Eloqua integration (a.k.a, Grandpa Joe)
I implemented my first Eloqua instance way back in 2011. It was a replacement for Marketo, which at that time was a baby MAP having a lot of system issues. So we made the plunge to Eloqua. At first, the concept of external calls being both a data push and a data pull was super confusing. And the Program builder steps seemed like they were designed by developers, for other developers. Not for marketers.
However, I quickly adapted and it clicked. The way the external calls and Program builder worked together let me customize pretty much any process. And when you’re working at an organization that explodes from four inside sales people to 120 in less than two years, you need to adapt quickly. Eloqua was GREAT for that.
But it had its downsides: pulling data from Salesforce wasn’t immediate, or quick. And pushing data also took a while. But we decided it was worth the lag to get the customization. Before I start sounding like Grandpa Joe lamenting the “good ol’ days”, let’s get to the good parts of the new integration app.
The new Eloqua Salesforce integration app – The good
Better UI
The first plus that comes to mind is the updated look and feel. FINALLY, it looks like Eloqua started investing in some real UI design. Bravo, Eloqua! It’s much easier to navigate and doesn’t feel intimidating.
Faster integration
In the old days, I’m sure I wasn’t the only marketing ops person fending off complaints from the sales team that leads weren’t in their Salesforce queues immediately. With the new app, those integration delays have been eliminated. The pull from Salesforce is more or less real-time, while the push to Salesforce is also much quicker (though some of that depends on how complicated your processing program is).
Customization
Eloqua was smart, and kept a lot of the beauty of its original integration – meaning you can still customize the majority of your records and pull any custom information back from Salesforce.
Simplification
The way the new application pushes data to and pulls data from Salesforce is more in line with how we all expect an API-based platform to work. Meaning, they’ve replaced “external calls”, “internal events” and “auto syncs” with “actions” & “imports” (plus a few others).
That makes thinking through your integration easier on your brain (and we like to be nice to our brains; there’s a lot of valuable information up there…like which of your sales reps has been slacking on cleaning up his leads. We see you, Brad.)
Now, let’s put on our surly Grandpa hats and talk about the bad stuff.
The new Eloqua Salesforce integration app – The bad
Migration
Actually migrating is a big problem. You basically have to start over from scratch, while somehow still relying on your MAP to keep your sales and marketing teams running. It’s like working on the engine while you’re still driving the car at full speed. They do have a “migrate” function, but be wary, some of your fields might not migrate over quite right. I’ve found that some of the imports are just easier to rebuild from scratch
Official training & documentation
If I’m wrong here, PLEASE reach out and correct me (seriously – contact me)*, but I had a hard time finding any simple documentation on how to get started and how each of the pieces fit together. They do provide their typical docs.oracle.com nonsense, but those are not super easy to follow. And the path that any links take you is a rabbit hole that’s hard to get out of.
Looking for a video example, perhaps? You’re out of luck. I did not find any video documentation or examples built by Oracle. There are, however, plenty of resources by people who are likely trying to sell you their services.
Import data filters
There was one part of Eloqua’s legacy integration platform that made perfect sense, and that was the process to filter out records you DO NOT want to sync back to Eloqua (for example, leads marked as unqualified in SFDC). You would just pick a parameter, operator and criteria in an easy-to-use filter UI.
They’ve made it worse. Now, you need to use “Salesforce Object Query Language” (SOQL), which isn’t that hard, but is definitely harder than “this field equals this criteria”. And likely you’ll need the help of someone on the SFDC side to pull the HTML name of the field.
Support
I could spend a lot of time ranting about Eloqua support ever since Oracle purchased them. Prior to Oracle, I would have told you Eloqua support was top-notch. There were tickets, and phone numbers and very helpful people on the other end of that easy-to-use process. But that hasn’t been the case now for a few years.
It gets even worse when we’re talking about a new piece of their platform. Here is a real scenario: I used their “migrate” function to pull my client’s auto syncs over to imports. However, I kept getting an error that didn’t have any details to it. It just kept saying, “too many failures”.
My client has about ten auto syncs, and I was getting this error on EVERY SINGLE ONE. And for each one, it was the same response: try setting them up from scratch. So much for that “migrate” workflow!
All of this is really to say, while there are some definite benefits to the new Eloqua Salesforce integration app, it is not going to be an easy or smooth road. My best and most honest advice is just to hire someone who has done it before, because really, who has time to submit fifteen support tickets a week?
Me. Apparently, I do.
WARNING: Do not, under any circumstance, uninstall the app
It does not work like the on-off switch on your slightly temperamental smartTV!
*As I was sending drafts of this article around for other perspectives, one of my colleagues took me up on my challenge to find better documentation (thanks Tyler!), and he did find an interesting FAQ put out by Oracle.
There are two big ones that he flagged:
The question: If I reinstall or update the App, will I lose configured assets?
The answer: When you update the App, all existing configurations will be preserved. If you reinstall the App, you will need to configure the App from scratch.
Why you should care: This might seem semi-obvious, but if you’ve worked with other apps in the Eloqua app marketplace, you’ll know why this needs to be said. Often, when an app stops working due to authentication issues or because the moon is in retrograde, the advice is to uninstall and reinstall.
This usually isn’t a big deal, since the integration happens based on a user’s credentials. However, before you click that uninstall button, work with Oracle support to make sure you don’t have any other options.
The question: When you configure an import, you cannot specify field-by-field if it should be updated if the new value is not blank. This option is available in SFDC Native Integration, however, not in the new App. Was it overlooked?
The answer: The SFDC App is designed to follow field configuration rules as defined in the core Eloqua, where the default setting is set to “Update if new value is not blank”. Users can modify this setting as needed.
Why you should care: This is a big step backwards for Eloqua – it means you can’t decide update behavior at the field. It’s not clear why they would take that functionality away, other than someone forgot to put it in the specs and now we’re all just going to pretend it’s functional. Too harsh? Maybe. But at MTS, we call it like we see it.
