Oracle Eloqua 19B Release Overview

We're halfway through Q2, which means that it's time for another Eloqua update. The 19B release will be pushed to Eloqua customers over the next week, but don't expect any major new features. After a succession of blockbuster new capabilities, this update is a little on the light side, focusing on foundational work and UI tweaks. There are definitely talking points though, with the controlled availability release of Send Time Optimisation being the most high profile.

Oracle's customer communication in the run-up to the release has been focused on the impending retirement of legacy functionality rather than the release of anything new. Oracle will be retiring the classic non-responsive email and landing page design editors after the next release in August, and have sent out multiple communications asking customers to upgrade existing assets built using these tools. This week marks the end of the line for new assets built using these features - as the ability to create emails and landing pages using the legacy editors is being removed. Existing assets can be edited for another three months, before being made read-only in the next release.

Landing Page Enhancements

Fortunately, the new editors are easy to use, if a little inflexible. Landing Pages created in the new editor can be a lot a more sophisticated after this release though, as a UI option to add custom JavaScript has been added to the editor, opening up a much more extensive range of front-end experiences for audiences. A UI option to change the browser title of a landing page has been added to the toolbox – until now it was only customisable through the page meta tag options. The ability to edit the default font for forms has been added back in too. This was an option in the old landing page editor, that was mysteriously absent from the new editor until now.

Perhaps the most welcome change is a small but exceptionally useful tweak to the page redirect options. Eloqua has had a UI option to redirect landing pages to a different page for well over a decade. This was most commonly used for form confirmation pages, where users could set the page to redirect to the website or a different landing page after a few seconds. It also could be used to redirect retired landing pages to updated versions. As of this release, the page redirect feature now works on deactivated landing pages too. This means that when a landing page is unpublished using the deactivate page toggle, users can specify where visitors who hit the retired page should be redirected to. Previously, they saw an error message or were directed to the default page for the microsite, neither of which was a great experience.

Form Enhancements

The responsive form editor also gets some updates in this release. The primary enhancement is the addition of Progressive Profiling, which means that the new form editor incorporates all the features of the old editor just three months after release. As such, Oracle have now announced the timeline for the deprecation of the old form editor, and it's an aggressive one. The classic form layout editor will be going away as of the 20B release this time next year.  All new forms will use the responsive form editor as of the 19C release. Meanwhile, after this release saving a copy of a form created in the classic editor will convert it to the new editor. There is no way to convert a form to the new editor without saving a copy of it.

This is a very aggressive timeline for a feature whose deprecation will have potentially uncertain impacts on customers. The classic email and landing page editor were rarely used due to their inherent limitations so removing them only affected a small proportion of users, but forms are used by all Eloqua customers and not just in Eloqua. There are a lot of forms out there on websites, that will not be editable in Eloqua after May next year. This has major implications for web teams and some third party integrations, many of which use forms to post data to Eloqua as a workaround to avoid using the API. Fortunately, the retirement of the old form editor only affects the ability to edit form fields and layouts. It will still be possible to edit form processing steps on forms created using the old editor, which does significantly reduce the impact.

Oracle are advising Eloqua customers to re-create all existing forms in the new editor. This seems excessive. I would definitely recommend running an audit of all active forms to identify which ones are being used on external sites or applications. There is no need to replace them with forms created in the new editor until field or layout updates are required. Be aware though that in future, any changes to the fields on these forms will likely require creating a copy of the form in question with a new form id and form name. Make sure that your procedures for updating forms account for this.

The more pressing concern is that as of this release, it is going to become very difficult to create forms using the classic editor. This may not sound like a big deal, but the HTML Eloqua generates for forms created using the new editor is very different from that generated by the old form editor. This will break any custom styling or custom scripting included in landing page templates as well as on websites. I'm not expecting much sympathy from Oracle on this one though – they will simply advise re-creating the forms and relevant scripting from scratch. If you're not actively using forms created in the new layout editor, make switching to it your top priority.

Fortunately, Oracle are making it much easier to identify the editor type that assets were created in. The email, landing page and form browsers will all be getting an extra Type column in this release, which means that users will be able to immediately identify assets created in the classic editors simply by browsing through the folder tree. Until now the only way to extract this information in bulk has been through the API.

Salesforce Integration

The new Salesforce Integration app reaches general availability. This follows its launch in controlled availability a few months ago. It now matches the features of the existing native Salesforce integration except for a small number of rarely used legacy features. The only notable one is that the list of marketing activities that cause an activity to be logged in Salesforce is a lot more limited than the native integration. The new app only supports logging email related activities such as sends, opens, clicks, subscribes, unsubscribes and bouncebacks. The web visit and form activity types are not currently included in the app. Also, the app requires 18 character Salesforce IDs to be used in Eloqua, which is not the default even if it is best practice.  There is a manual migration required if your existing Salesforce integration uses the shorter case sensitive 15 character ID format. Customers using CLR will need to involve Oracle Support in this migration if they're importing opportunities into Eloqua.

Assuming your Eloqua instance uses the longer Salesforce ID format, there is now an option in the app to migrate your native integration configuration into the Salesforce integration app when you install it from the marketplace. The app can then be run in parallel with the existing integration until you are ready to migrate completely and switch off the old integration. Complex integrations that involve multiple Salesforce instances or custom object integrations are mostly supported by the app but should be extensively tested.

Program Enhancements

A late addition to the last release was Field Level Tracking for program canvases. Eloqua has never had the ability to monitor changes to contact fields and trigger program workflows off the back of field changes. This makes building program feeders difficult and has severely comprised the utility of listeners on program canvases. It is now possible to track data value changes for 10 contacts fields under field settings, and then use changes to those fields through Contact Field Change listeners on program canvases. This doesn't tell you who changed the field or when, but it does allow compliance workflows to be triggered based on updates to opt-in fields or integration workflows to be run following updates to country or lead owner fields. The main downside of this much welcome functionality is that the Contact Field Change listener can only be used 10 times across all programs in an Eloqua instance, so use it sparingly only for essential programs. This is actually an increase from the 3 times that it could be used when made generally available in the 19A release.

Other Changes

There is a new opt-in feature that enables cascade delete on specified custom objects. It is now possible to automatically delete custom object records when the linked contact is deleted. By default, this doesn't happen, and instead, records are left orphaned and unmapped when the contact they're linked to is removed. Eloqua customers can ask support to switch on an option to override this behaviour, on a per CDO basis.  If enabled, linked custom object records are deleted when the contact is deleted. There are valid use cases for the default behaviour and valid use cases for this new behaviour, so make sure to consider what the required setting should be when creating CDOs.

Finally, customer administrators should be aware that Oracle will be automatically installing the RSS, Contact Washing Machine, External Activity & Date Apps from the Oracle Marketplace in all customer instances as of this release. These are all add-ons developed by Oracle themselves as part of their strategy of separating out useful but non-essential functionality as separate apps. Eloqua power users should be aware of these apps, as there is little reason not to use them when the need calls for them, but they do require a small amount of initial configuration. Pre-packaging them with the main platform does defeat the point of splitting them out in marketplace apps though.

The Oracle Eloqua 19B Update is scheduled over two weekends starting May 18th, 2018. Contents of the release are subject to change. Full details, including smaller changes not mentioned in this article such as faster segments and context sensitive editor help, can be found in the official release notes.