Data from dynamically added hidden field on form 2.0 not saved.

[Franky_Ruyssch2]

I am adding a hidden field to a global form like:

form.addHiddenFields({"ContentName" : "SLA MultiPress: Inside leaksource surveillance"});

Working fine on MultiPress ILS | Dataline Solutions

Now, I also have a database field "ContentName".

I was expecting this field to be updated with the content from the hidden field above, but no data is written for this field on form submit. Because there is no link between them?

Can someone help me here?

[Alexander_Lamb1]

Hi Franky,

If returning user:

Did the end user(email recipient) receive this email from Marketo?

Does your website have the munchkin <script> global, on every page?

Both have to be yes or it will not generate from out-of-box Marketo.

If new user:

Verify that Marketo <form> is sending the values to the database you can do this through MIT code lab GitHub and Google Tag Manager.

If blank:

Check your script that populates the hidden field for Marketo <form>

or

Change your Marketo <form> Hidden Field in Design Studio with:

Behavior > Form Pre-fill {Enabled} > Autofill {edit}

Change fields Get Value from and Parameter Name

Troubleshoot again with Marketo <form> listener from MIT or on Marketo Database.

[SanfordWhiteman]

Verify that Marketo <form> is sending the values to the database you can do this through MIT code lab GitHub and Google Tag Manager.

You don'r need any 3rd-party code to see the data posted from Marketo forms.

All modern browsers have a Network tab in their F12 Tools, and viewing the post to /save2 explicitly shows all fields.  On the Marketo side, the Activity Log Detail will reflect the same data, even including form fields that do not exist in Marketo and thus can't be saved permanently to the lead.

Needlessly introducing GTM into the Munchkin/Forms 2.0 ecosystem is not recommended. 

[SanfordWhiteman]

As noted above, if you open your browser's F12 Developer Tools and look at the Network tab, you can watch the POST to the Marketo /save2 endpoint go by including your hidden field.

For example, here's the traffic capture in Chrome showing the ContentName field is posted successfully with the form:

Be aware, though, though that you should be using your LP domain, not the generic app-lon07.marketo.com, if your LP domain supports SSL (if it doesn't support SSL, you should add SSL to your Marketo subscription). Otherwise, as in fact happens on my primary desktop, the form post can be blocked by anti-tracking privacy plugins/features. (Of course you don't want to over-worry about such end-user choices, but there's a good way to take this particular worry out of the way.)

With regard to the particular field you're adding, make sure that ContentName is the SOAP name of the field: SOAP names are also used as form field names. Go to Admin » Field Management » Export Field Name and export the field list, then look in the SOAP column.

[Alexander_Lamb1]

With GTM:

You can intercept the data and its handlers, for example: on success with the Marketo Listener in GTM. This makes it easier to verify without having to log into Marketo for successful form fills. It also helps the developer diagnose what variable, in Franky's case a page title, without posting the data to Marketo.

Use-case:

This would be beneficial to large databases whose technical debt and workarounds cause headaches for "live" tests and who cannot afford Marketo's sandbox environments.

Example: with GTM and Marketo form listener

GTM: Set trigger to populate data layer for on submit or on sucess handler from Marketo.

GTM: Preview Mode

Go to page with Marketo <form>

F12: Network tab and select offlineGTM: Fill out form, verify results

With just using F12, you cannot use the Marketo <form> triggers to diagnose the problem, if its with the Marketo handlers or your code.

But if you are a senior developer and built the mechanisms yourself, F12 might just be fine for you.

[SanfordWhiteman]

Sounds like you're merely adding to the listener stack (which has a discrete stack limit you need to respect btw) not debugging the Forms 2.0 event handling process itself.

That another whenReady listener fires in proper stack order has nothing to do with the operation of the listener you're actually trying to inspect (except of course that if your new listener throws an error, the whole stack is broken!). It's trivial to introduce a breakpoint (debugger;) directly into the event listener you're trying to inspect... if indeed you need to do any of this.

But all of this is very far outside the current need.  Checking if a field has been programmatically added to the form with addHiddenFields() at form load is as easy as right-clicking and using the browser's inspect feature to check right in the HTML. Or, if you're paranoid about the Forms API picking up the value (as opposed to the <input> merely being in the DOM) you can run

MktoForns2.whenReady(function(form){
  console.log(form.getId(),form.getValues());
});

from the F12 Console.

Since the field and value are added earlier in the whenReady listener stack, that's all you need to do to see that it's completely on the form and populated correctly before the form is otherwise filled in.

Watching the data the browser tried to POST to /save2 confirms that what you wanted went on the wire, and also tells you if there was an HTTP-level rejection (mistakes in the forms library config can cause CORS errors at this stage) or plugin-level rejection (Ghostery et al. will reject at this stage as well).  You could also abort the onSubmit before putting data on the wire, but after any submit-time additions are done, but that's off-topic for this simple case.

Finally, looking in the lead's Activity Log Detail for the Filled Out Form gives proof that the value is being transferred internally from the form data queue. Questions like "Why is my field on the form but not ending up on the lead?" invariably involve the Activity Log Detail, because the ActLog is the critical gap between the HTTP POST data and the Lead Database. If the field is in the Detail but is not on the lead, it either was mapped incorrectly (not using the SOAP field name) or is blocking field updates.

Although offline testing is part of a proper QA process, custom form code can't go live without true form posts. So an instance must be ready for such traffic (an email address @ the standard placeholder domain email.invalid is trivially identified as a test lead).

But if you are a senior developer and built the mechanisms yourself, F12 might just be fine for you.

The F12 Developer Tools are not for senior developers. They're for anyone writing, or merely copy-and-pasting, client-side code.

[Franky_Ruyssch2]

Hi,

I have checked the SOAP name, and it is spelled contentName, starting with a lower case. Could that be the issue?

[SanfordWhiteman · Accepted solution]

Of course.