Form Prefill Identity Mismatch | Community
Skip to main content
Level 2
October 12, 2017
Question

Form Prefill Identity Mismatch

  • October 12, 2017
  • 1 reply
  • 5940 views

I am building a two step communication preferences solution to ensure that the communication preferences loaded are for the correct Marketo identity.   (We have a system where individuals might have multiple identities - email addresses.)

The first step is an email only form with prefill enabled.    When this is submitted, it takes the user to the preferences setting page.  Simple enough.   Then I tested the form.

Test 1 on Windows 10, Firefox 56.0 (64 bit) - but this also happens on MS Edge :

I come to the email only page (http://info.bstock.com/Communication-Preferences-Get-Email.html) and it is prefilled with my last cookied identity - pamtest8@apm.com

I alter the email address from pamtest8 to pamtest80@apm.com and submit the form.

!! Here is the issue:

The preferences page comes up with a mix of my new email address - pamtest80 and values prefilled from my pamtest8 cookied identity.   When I look at the page source for the page, the prefill variable shows the values for the new identity (all of the fields are pretty much empty).

Where is the form getting the original pamtest8 values that are populated there when the prefill variable isn't showing them there?

More importantly, how can I stop this from happening?   The whole purpose of the two form solution is getting the right identity in place in the cookie so that the preferences form will fill accurately.

One more thing to know:

For the email only form, I have some custom javascript code that takes a encrypted URL parameter, decrypts it, and uses the value to fill the email address field.   It is set up so that if there is a cookie, it will overwrite the email address from the cookie.  However, in this situation, the code in the javascript that does this should not be executing (no URL parameter).

Any and all wisdom are welcome.

1 reply

SanfordWhiteman
Level 10
October 12, 2017

The cause of this behavior is clear, but unfortunately a solution isn't.

The reason you see mixed data at first is that the cookie is not associated in real-time. (There's never a guarantee that a re/association will be complete by the very next HTTP request.)

As a result, you see the existing association's fields for everything that wasn't on the first form. Only the email address was on the first form, and it is immediately available because it's keyed on the aliId (which can be thought of as a form payload cache).

If you refresh the page after a second or so, the association will be complete (although it's still not guaranteed, a couple seconds of delay will cover most cases).

The only way to ensure you never see mixed values is if you strip off the aliId (you can do this in the onSuccess on the first form) and then poll the second page every second and refresh if the PreFill values don't match the new email (which you can pass in the URL).

Also, your URL-based form fill should be changed to use the forms API setValues() method. Setting element values directly is not guaranteed to work, and the object model has its own accessors for that reason.

Level 2
October 13, 2017

Sanford,

   I was hoping you would help me get to the bottom of this.  I figured you would know exactly what this was about (because of your blog and other posts on the community). Thanks so very much for your thorough comments and the extra tips.

    I inherited the javascript for the URL-based form fill and made some changes, but didn't catch that it would be better if I should used the setValues() method.  That may explain the issues I noticed when I overrode the cookie value with the parameter value in the original code.   I solved for that by using the form.whenReady.  I will go and make that update along with the extra onSuccess code to remove the alild and add the parameters I'll need for the polling.

    Will try to put all of what you suggested together in a package and give it a try.  (We were playing around with triggering a page refresh, but the polling option is a more correct solution because one can never count on the timing.

    You rock!  (And if you didn't know about it yet, you have a very solid fan base out here.)

Thanks.

-Pam

SanfordWhiteman
Level 10
October 13, 2017

Thanks for the appreciation! You should be good to go with the polling. With a little extra code, you can simulate a spinner (increment a counter in the URL on each refresh and then print the equivalent number of ••••s or something like that).