We tested the new update, dubbed Oracle Release 486, and we’re breaking it down for you. Marketing Automation professionals using Eloqua know this update is coming and everyone is wondering what the impact will be. Luckily, the release already hit Simantel’s instance this weekend, so we performed a test of our own.
And just like many, we have forms with varying levels of validation. While testing, we noticed that it’s hitting pods three and six. (There are two more releases coming, according to Oracle. See the chart below to find out when it will hit your pod.)
In order to better explain the impact of 486, we have bucketed this into three groups. Here’s a quick look:
1. Client Side Validation
These are forms where all validation lives on the client side. This could be a landing page/form being read by an API or a form that has been integrated with your website. Our own contact us form and our test form fall into this category.
For our testing, we created a form that did not require business phone number. The validation on the website said “sure, you can submit without a phone number”. But, on the Eloqua side, we required the phone number in the form processor validation.
Before the release: The form allowed submission with no phone number.
After the release: We got a default error message enforcing the Eloqua requirement.
The fix: In order to have the client side validation function as we wanted it to, we simply had to go into the form processor and uncheck the Eloqua validation box saying “this field is required”. Once we did that, the client side validation worked as designed with no phone number required.
2. Server Side Validation Coded on Eloqua Landing Page
We also have forms that live on an Eloqua domain, where we’ve coded some validation into the landing page. There were similar findings with this form.
Before the release: The form validation was governed by our coded validation on the Eloqua landing page.
After the release: We got a default error message enforcing the Eloqua requirement.
The fix: To have the coded landing page validation function, we simply had to go into the form processor and uncheck the Eloqua validation box saying “this field is required”. Once we did that, the landing page validation worked as designed.
3. Server Side Validation Through the WYSIWYG in Eloqua
We rarely use this type of validation, but know that many do. So, we tested it and everything worked beautifully!
We’re also going to lump in blind forms here, because there is generally no client side validation. To keep your blind forms working, make sure that for each field, there are no validation boxes checked in the form processor. If the form field processor has validation selected then you will receive an error.
Before the release: The form validation was governed by Eloqua validation within the processor.
After the release: The form validation was governed by Eloqua validation within the processor.
The fix: No updates needed, unless you want to create a pretty new Validation Failure Page.
What Simantel Clients Need to Know
If you’re a Simantel client, we’ve already discussed how this will impact you and we have a proactive plan in place. If we’re not working with you yet, feel free to leave a comment or tweet us @simantel. We’ll connect you with one of our Oracle certified professionals to answer your questions.
Learn more about our Marketing Automation capabilities and some of our recent work.
