Eloqua Nightmares: My worst ever SFDC integration

Jun 23, 2019

This article isn’t so much an Eloqua technical how to guide.  It is more a how NOT to guide when it comes to integration.  This all comes from a true story which I wanted to share with you.

Before I tell you the golden rule, I am going to give you the back story to it.  Whilst this all happened during an Eloqua implementation I was on; the rule still stands for any platform you are about to test.  Before anyone asks I am not going to tell you who the client was – and if by chance anyone is reading this from the end client in question, please reach out because I would absolutely love to hear your side of the story over a beer sometime.

Also I am going to try something new and add some interactivity to see what you would have done along the way.

Let’s start at the beginning.  I was finishing off an implementation for an end client.  I had been left by myself to complete an integration from Eloqua.  Normally this isn’t a bad thing but being there by myself left me somewhat vulnerable, especially when it comes to working alongside another firm that was doing the SFDC build.  I found that when I got pulled on to a design decision call I got more or less smashed to pieces by the rival firm because they would ambush me on a call with between 10 and 15 people, few of whom were relevant nor has anything to add to the call, more to be educated on how an integration between Eloqua and SFDC works, then regurgitate what I had just told them I needed them to do and then get me to validate to them what I just told them they needed to do.

I actually kicked a senior partner from the opposing firm off a call because I felt they were wasting the call time – that was funny!

Needless to say I wasn’t very happy with the firm in question and I did not appreciate their bully-boy tactics of call ambushing and then re-branding my solution design as theirs.

Towards the end of the call I got patched into an RFP call.  My senior manager has the CIO on the phone from a prospect company.  I got asked a simple question not knowing who was on the call.

“Should we have separate instances from Eloqua for each business unit or should they be on a shared one like we have in SFDC?”

(They had recently gone through a huge project with the competitor firm to migrate all the separate instances on SFDC onto 1 instance of SFDC)

[democracy id=”2″]

I was very firm in what I said,  I said “We should have all business units on the same instance of Eloqua, just like you do in SFDC”.

My reason was because I had recently been pulled onto an emergency job for one of their competitors to debug their integration.  Their competitor had multiple instances of Eloqua (nine) integrated into one instance of SFDC.  I was working with a very talented Eloqua guy in the Netherlands, Bob Balm to debug a huge integration issue where somehow SFDC Contact ID was getting erased.  Bob actually found the problem and somewhere along the build SFDC campaign member ID was overwriting SFDC contact ID, which is what had caused the problem.

Due to this issue I was very firm.  I was asked to validate my position, “Why do you think all business areas should be on one instance of Eloqua”?  I replied with a simple two part answer:

1. If you want a 360’ view of what is happening with a lead or contact and your marketing efforts you need to have one marketing contact, not many so you can make full use of prospect profiler and see how they are engaging with all business units since you all sell the same thing, not just the marketing efforts of one business unit

2. Using multiple instances of Eloqua is just lazy. You need to reconcile your instances and on board with uniformity. This will make also cost a lot less in both resource and maintenance

The CIO liked my answer and so the RFP pitch carried on.  I already had a polar opposite view to the other firm.

I got called in one last time for the RFP pitch and that was that, the project got sold.

As with most implementations I have been on the RFP is more the door opener and the real project planning starts when you get there.  You need to lift the lid and see what is going on.  This is where the nightmare began.

For the first two weeks the team was sent to an office in London where we had to produce slide decks of how we were going to deal with an implementation that needed to go through 8 sandbox environments.

We asked for access Eloqua so we could see what had been set up for the business unit that was about to have to share their instance of Eloqua.

They denied us so I asked for access to a sandbox, we were denied again.  The other firm that was already working with the client on the business area that we were going to onboard the rest of the world on and neither the client nor the firm wanted us to go anywhere near it.

We got the project plan together and agreed to migrate the different countries in waves.  Once agreed we got sent to their main office in another part of the country.

Here is where the fun started…..

My first meeting with the business unit already using Eloqua and the firm that they were using was more or less me being shouted at by them.  How the firm I was working for shouldn’t be here and that we had to get another instance of Eloqua.

After an hour of that (when they had run out of steam) I then asked if they would show me some of the backend programs they had created which they showed me on a screen.

I left the meeting empty handed, no access to anything and unable to continue my work.

I then switched tactic to ask them for documentation.  They replied telling us the documentation was getting updated and would be released.  I still didn’t even have a sandbox login.  They did very reluctantly give me a powerpoint of the Eloqua architecture that simply showed a number of Eloqua programs linked to each other called the backend “daisy-chain”.

Below is a screenshot – less branding of what I was given.  Please take note of the awesome attention to detail, especially the way they labelled what each of these programs did.

Another week passed and I was back home.  I was back home in Germany about to go a festival on pride weekend in Amsterdam.  A couple of beers along the way, boarding the train from Cologne I got patched into another call.  On this call I once again had no idea who was on it.  Not to self – any time I get brought on a call find out who your audience.

I stick by my guns and I would have done nothing differently regardless of the audience.  But you may have so please do vote when you see the upcoming question.

As an FYI, I thought the only people on the call were the senior manager on the project and the head of the rival firm that were already on the instance of Eloqua I was trying to get onto.

On the call were actually were the afore mentioned people, an analyst I had worked with in the past.  The CMO, the CIO, the head of marketing for the business area that was already on the platform and some other senior personalities.

Another thing you need to know is that both the head of the rival firm and the head of marketing for the business area that was already on the platform shared the same name…..

I get patched in the call and it when something like this.

My Manager, “So Greg, explain the issues that you are having.”

Me, “I have been brought onto this project as a developer and I don’t have access to the platform, the sandbox or the documentation.” 

Now… for the next part you need to know I thought that I was talking on a closed call with the head of the rival firm, not the marketing manager from the business area that was on Eloqua already, let’s call her Julie.

I then said.  “Julie, you told me you would have the documentation to me two weeks ago and that you were finalizing it.  When can I have it”?

She replied, “there is no documentation that I can give to you”.

[democracy id=”3″]

I called her a liar and it went along the lines of this.

“So basically you have lied to me for the last two weeks about documentation and I still haven’t got access to anything.  Hang-on, wait a minute, how can you have a live SFDC integration with Eloqua with no documentation.  I don’t believe you, you are a liar”.

She then back tracked and said “yes we do have documentation”.  I then just hammered her.

“You either have documentation or you don’t, either way you have lied to me”.

I then continued, “you have wasted my time as a developer for four weeks.  I don’t have access to anything because you block it at every turn, then you have me waiting round for documentation which you say doesn’t exist and then change your mind because there is no way in hell an organization like this would have an SFDC synch without documentation so one way or another you a lying to me and quite frankly wasted the last four weeks of my life”.

As you can imagine this didn’t go down well….

I got a phone call from the senior manager asking “do you know who was on that call?”  To which I replied I didn’t and that I thought I had been talking to him and Julie from the rival firm.  He then filled me in on the details.

I thought nothing of it until I arrived back in London the following week.  I bumped into the partner on the engagement and this had gone right the way to the top.

The CMO in question asked for me to be removed from the project because I was unprofessional.  The partner from my firm then asked her to clarify.  She said I called one of her staff a liar.  He then went on to say this was very out of character but he had my back.  He then said “if my developer has got this wrong, I will remove him immediately.  If you still want me to, I will remove him, however if a man is going to call someone a liar on a phone call like that, surly you want that person on your team?  The other thing you need to remember about Greg is he didn’t grow up in the corporate world, he grew up in the military, an organization that has very different values and standards”.

I was blown away and very thankful to the partner for having my back.

Once the dust settled, I got given access to the sandbox but no documentation.  As it turned out the SFDC integration had limited documentation, i.e. a second-rate mapping workbook and none of the other eight back end programs had been documented – WOW!

The access to sandbox I had been given was so petty.  Some pathetic, petty individual decided it would be funny to give me access to the sandbox but then rescind access to anything in the platform.  I logged in and this is all I saw.

At this point on another call I asked them why I had such limited access.  They then said I had to ask them specifically for access to each and every part of the platform individually and I couldn’t just ask for customer admin access.  I can’t remember how that got resolved.  I think I escalated it to the manager on the project, who had a word with the partner, who had a word with the CMO who in turn had a word with the business unit on the platform – another wasted week.

Once I got access, I began documenting the back-end stack.  The firm before had stuck eight programs end to end using program builder (program canvas did not exist in Eloqua at this time) which meant that inquiry to MQL sitting a in a lead queue in SFDC took 16 hours, most of the programs were data manipulation, nothing more.

Time for the next vote….

[democracy id=”4″]

I documented the backend and then decided to build my back-end programs in a stack that would only take two hours to process, rather than 16.  I know, I know, still a long time but there were good reason for this.

Everything was going along fine until SFDC integration.  SFDC integration meant I had to put the integration for our business units on the platform.  To speed things up I initially suggested updating the filter on the original transfer values filter to include the three business units we were on-boarding as well as keeping the original business unit integrated.

I went into change board thinking this would be a slam dunk – hell no, the other firm and business unit objected.  The “solution architect” and I use that in the very loosest possible term then had a decision to make.

[democracy id=”5″]

He melted.  I suppose you can’t fault him too badly, both the rival firm and the other business area objected and then decided we should move into a due diligence.

I then fully documented (properly this time) the SFDC integration that the existing business unit has created and simply changed the part in the query for inbound autosynchs by switching out that business units name for the three business units I was on-boarding.

[democracy id=”6″]

Well done those of you that got it.  The solution design got shot to pieces by the other firm and business unit which was strange since it was in fact, their own design with some minor alterations.

I then spent the next six week in bewilderment.  Every Wednesday I would go to the change board with updated solution designs, having been showing Oracle’s own slide decks for the integration to the various personalities that I needed to educate.

Once again blocked to the max with no way forward.

I went to the change board on Wednesday to go for another humiliation and afterwards pulled up the so-called solution architect and told him.  “You need to get that firm and that business unit to cease fire.  This integration is no different to their own so if they are having problems with it then their own integration is wrong.  Also we need to have this integration in UAT in the next two weeks or we cant build an integration due to a change freeze for a few months”.

He dismissed me saying I was wrong and I needed to sort out problems with the solutions design.

I proceeded to yet another Eloqua data model meeting and then I found out what the problem was.  The rival firm had done the mass consolidation of different CRM platforms in the one instance.

Except here is the thing – this is brilliant….  The rival firm had taken the easy, lazy route.  They had not gone through reconciling picklists, changing sales processes, no, no , no.  They and he had decided the best way forward was to build different views, fields, etc, all built on duplicate contacts and leads.  Essentially they had built several different instances of SFDC on one instance of SFDC.  I recognized this behaviour on the previous integration I was on.  It seems the rival firm have a blueprint way of doing things which is easy, gets results fast – so it turned out that their one instance of SFDC was a total farce.

I then asked the very uncomfortable question, “why, why did you build you system like this?”  To which I got no satisfactory reply, only more blockers.

I fly back to Germany on Thursday evening and I am working from home on Friday.  I get patched into a call.

“How soon can we have the integration I have designed in place because the change freeze means if we don’t have one by Monday then this will need to wait a few months”.  This was a very sharp change in tune…..

I replied…  “I will have you your integration fully built ready for testing by Monday”.

The “solution architect” had the cheek to then reach back out to the rival firm and business area to see if this was possible to which I replied….  “watch me.”

I built the integration that afternoon flew back on Sunday night.  This was in one of the lower end environments – they had eight – yep, that’s right, eight.

We ran the tests and everything went well.  We pushed it all the way through and then something new happened.  They decided to release a dress rehearsal instance of SFDC to integrate live into.

When I saw this I was thinking – no way – this is a recipe for disaster.

Anyway.  I built the integration in production Eloqua and pointed it to pre-production SFDC.  I switched on the inbound autosynch for Get leads and suddenly around 300k customer records got overwritten by encrypted data.  That is all fields on the integration that were encrypted (everything accept email address) got overwritten with special characters.

You can imagine an email going out…  Dear %^$£$^&^%, etc, etc, etc.

This was a major problem.  The problem was rectified by the other developer that was on the project with me but by then I had run out of friends.  I only had one friend left at this stage in the end client and none left on my team either really.

I was toast – boom.  No-one spoke to me at all for about seven days, I wasn’t even included in stand-ups and then the senior manager on the project called and said I was off the project but we would work again together some time.  On a side note he is also an ex-military man so a top bloke!

So…..  Here were the three lessons learnt which if done would have meant his whole mess could have been avoided.

1. Always download your entire database – all fields – before you switch on an autosynch for the first time. In a worst case scenario, like this, you can re-upload your database.

2. Don’t integrate a live environment to anything other than a live environment – just don’t

3. If you have to integrate into an environment only integrate the basic synch points and switch the email address to *@client-domain.com

Out of interest….  What is your opinion?  Please use the comments are below.