There are several groups that organizations using the Eloqua Marketing Automation Platform may fall into:
- Those that know first-gen Cloud Connectors are being phased out as announced here, and have prepared for it accordingly
- Those that exemplify the reason Oracle pushed the initial discontinuation dates back to October 7, 2016
- Those that ask “What are Cloud Connectors?”
To the first group, I have nothing but kudos – this post is not for you, except as a lighthearted reading over your morning coffee before you dive boldly into the complex machinations of CRM integration, program builder, and CDO services. No, the raison d’être for this advisory post comes from the fact that information moves fast but meaning does not. Seemingly unimportant but-actually-important information can often reside in plain sight and require time to fully absorb into the community of Eloqua Users and Customer Administrators.
The History (skip to the practical advice if you hate history)
Back in 2008, the first client-facing external API for Eloqua was introduced. In fact, several web services based on the SOAP framework were made available over time, each with their own set of generalized use cases. You had the EmailService, which did what you think it did – helped you send emails. There was the CampaignService, which allowed the association of assets to (Eloqua 9) campaigns. Then you had the Service service, which held the important position of being a random bucket of functions with an equally non-descriptive name, and the toolkit pioneering Eloqua API Developers most often used. Lastly, we had the ExternalActionService. It doesn’t quite have the same ring as Cloud Connector, does it?
In essence, the functions it provided to the Eloqua Developer included the ability to poll or query a particular step inside of a Campaign canvas or Program Builder workflow, dictate the status of the member in said workflow step, and control when the member continued onward past the given step to the remainder of the (presumably well-configured) workflow. Wow, that’s a mouthful.
It looked something like this:
Your external server: “Hey Eloqua, do you have any contacts for me?”
Eloqua: “Nope.”
A few minutes later…
Your external server: “Hey Eloqua, do you have any contacts for me?”
Eloqua: “Nah..”
A few minutes later…
Your external server: “Hey Eloqua, what about now?”
Eloqua: “Sure, we have 9 new contacts that entered the step. I’m sending you their contact IDs now.”
Your external server: “That’s great Eloqua! Can you mark them as ‘In Progress’ for me?”
Eloqua: “Done.”
Your external server: “Eloqua, I’ve finished updating the records on my side and triggered some emails to these contacts. Can you now mark them as ‘Complete’ for me?”
Eloqua: “Contact status is now ‘Complete’”
And just like that, the Eloqua User was able to see contacts move through the step and onto the next part of the program or canvas. The User felt confident that something must have happened because Eloqua would otherwise be perfectly content leaving them sitting in that step forever, until the heat death of the Universe. Enter the Cloud Connector.
Fast forward to 2012 and Developers had a shiny new Bulk API to play with. While built with the intent of importing/exporting large volumes of data, the Eloqua Product Team realized they could alleviate some of the Cloud Connector performance issues related to the use of the SOAP API. This was accomplished by permitting the Bulk API to reference a specific Cloud Connector step ID when exporting and importing contacts, while also passing a syncAction to change their status to In Progress and Complete.
Now fast forward again to 2015, and the world is a very different place indeed. SOAP is dead. Bulk API 2.0 is available, and even shinier. The new Unified AppCloud (UAC) Framework is also available to Developers, enabling them to create Cloud Feeders, Cloud Content, Cloud Menus, Cloud Actions and more generally, Cloud Stuff.
The crucial piece of information missing here to all but the most experienced Eloqua API Developers is that Bulk API 1.0 and 2.0 are largely identical in capability when it comes to importing and exporting records of data. However, Bulk API 1.0 is used for those first-gen Cloud Connectors while parts of Bulk API 2.0 are used for the newer UAC framework. It’s well beyond the scope of this post to delve into the differences and new capabilities offered by UAC, but suffice it to say that you get a lot more control at the expense of additional development complexity. As UAC expands further and new versions of Bulk API undergo development, it becomes clear that the end for Bulk API 1.0 is on the horizon. The irony here is that many of the developers that were quicker to rebuilt their apps and leverage the performance advantages of Bulk API 1.0 over SOAP are now doing so again. So where do Cloud Components fit into this story? They don’t, except to say that it’s another legacy tool from the days of SOAP, which was dethroned by the mighty UAC (remember that Cloud Content stuff?).
Welcome Back! (if you skipped the history bit)
Here’s what you need to know:
- Cloud Connectors and Cloud Components will be discontinued from Eloqua starting October 7th. This effectively means you won’t be able to add new ones.
- Cloud Connectors and Cloud Components will be deactivated on December 31st, 2016. This effectively means they will cease to function. The caveat is that Cloud Connectors will be deactivated from use on the Campaign Canvas only. They’ll continue functioning within Program Builder for the time being. Cloud Connectors will be turned into wait steps on this day.
- On December 31st, 2016, Cloud Components, which are typically used on Eloqua Landing Pages will simply be removed. That is to say, the reference to them in the HTML will do nothing, but otherwise the page itself will continue to load.
Where do I get more information?
Read the full article on Oracle Community page
Want to know which Apps have been migrated to the newer standard, and what is being discontinued? Visit this page
Learn more about using the newer Apps
What do I need to do?
Step 1: Contact Eloqua Support, and obtain a full list of Cloud Connectors and Cloud Components being used by your Eloqua instance. If you have multiple Eloqua instances, be sure to mention this.
Step 2: Audit the list internally. Inactive Connectors part of archived Campaigns, and Components part of old/obsolete pages receiving no visits may need no specific action. However, it’s best to check with the experts! (Ahem.)
Step 3: If your organization is using any API driven processes that tie into Campaigns or Program Builder, it’s a good idea to validate whether these are using the outdated standard. If not sure, MarketOne can assist with performing a quick assessment. This is a critical step for more mature organizations that rely heavily on automation, as custom Cloud Connectors which are built by third parties will NOT be visible to the Eloqua Support team.
Step 4: The hard part – find out whether the Connector itself can simply be updated with a newer version, or if this belies a greater opportunity to revisit that old nurture or program flow. Is the Connector part of something worth keeping or something in dire need of refresh? This is where it becomes critical to have an organizational marketing technology roadmap, which is all too often missing from the myriad of process and technical documentation that teams rely upon.
A special note on Cloud Components
The most common Components being used on Eloqua landing pages relate to form pre-population, social/event widgets and progressive profiling. While it may be true that removing a social media button from the page isn’t a showstopper, the removal of an entire form definitely is when it comes to lead gen or nurture strategy. The original progressive profiling Cloud Component that many Eloqua Users grew up with (before the native functionality was introduced to the core application) is entirely responsible for generating the HTML code for the form itself. If progressive profiling is part of your core forms strategy (as it should be), but it’s reliant upon this tool, then you could face a difficult choice between placing basic forms on the page or rebuilding it fully. Even the most basic approach could involve dozens of assets and developer man-hours.
But as we near the end of this lengthy post, it becomes evident that changes like this present challenges, but the recurring theme is they also present significant opportunities to take all that has been gleaned the first time around and improve upon it. Make it better, faster, cooler. Isn’t that exciting?
