Apr 13, 2018 7:21 AM - edited Apr 13, 2018 7:24 AM
I've successfully created prepopulated forms with the help of this tutorial:
However, I have a couple of questions / issues regarding the technical things related to prepopulated forms:
I have a dropdown field with the following options (label - internal value):
My dropdown - my_dropdown
Option 1 - opt_1
Option 2 - opt_2
Option 3 - opt_3
I specify a URL to a prepopulated form with a parameter:
The contact receiving the email with a link to the form has the 'Option 1 (opt_1)' saved in HubSpot. My problem is that the loading of an URL parameter value only works with the label, not the internal value.
THIS WORKS: 'my_dropdown=Option 1' (The label is always loaded to the URL parameter.)
DOESN'T WORK: 'my_dropdown=opt_1' (I assumed the internal value would be used!)
There are several problems related to this such as:
Apr 18, 2018 1:31 PM - edited Apr 18, 2018 1:35 PM
Did my post help answer your query?
Help the Community by marking it as SOLVED
Q: Prepopulated forms and technical issues
Short A: Additional Information
Longer A: Not certain I completely understand.
Since HS field labels sometimes contain undesirable characters we've only ever used the internal value in query parameters.
Example page: https://abbreviated-url (opens in new tab)
Notice query parameters are internal values. (see image)
Result (see image)
The obvious difference here is that we're using a multi-checkbox HS field. Haven't tested dropdown fields, but would hope (expect) the same predictable results.
Hope that adds to the disucssion.
Apr 19, 2018 2:18 AM - edited Apr 19, 2018 2:21 AM
Hi MFJLabs and thanks for replying.
Unfortunately, your example doesn't apply to dropdowns. 😞
For instance, I have the following parameters set in one link:
And this what HubSpot loads into the parameters:
The internal value set for hs_persona dropdown field option 'Opiskelija' (student in Finnish) is persona_5.
This works only as long as the label used on the form matches whatever value is stored in the contact data.
Apr 19, 2018 4:33 AM - edited Apr 19, 2018 4:40 AM
Tested my example on a separate page with dropdowns. Works fine. The issue isn't the form or the query strings when passed using internal values.
The issue (you describe) is related to the query strings created using personalization tokens in email as described in the 'Create dynamic query strings with personalization tokens' section of the HubSpot KB article you reference above.
Seems like this shouldn't work the way we see it working. I would think that the personalization tokens would pull the internal values; however, as you said (and I confirmed), personalization tokens in email pull the label values instead. (not good)
Would like to hear the HubSpot support response to this behavior and how to correct it.
Anyone at HubSpot chime in please --
Apr 27, 2018 5:29 AM - edited Apr 27, 2018 5:29 AM
My name is Tom and I'm a member of the forms product team here in HubSpot. Thanks for bringing this to our attention!
I can see the same when testing this out on my end that the dropdown selects render the label through a personalization token as opposed to a the internal value.
I just wanted to let you's know I've raised this issue with our engineers and we're going to dig further into this to see if this is something that is required for our dropdowns or if this is an issue within our system.
I'll be sure to get back to you on this thread as soon as I have any more information on this.
Thanks again for bring this up! Let me know if there's anything else on this I can help with.
Apr 27, 2018 5:57 AM
Please also consider that while @tommifin originally reported this issue with dropdowns, it may also apply to the use of tokens in emails for other field types as well. Just my opinion, but it would seem like something we'd want to solve for all field types as opposed to solving for some.
Appreciate the effort.
Please tag @MFJLabs if you'd like me to respond.
May 8, 2018 5:33 AM
Thanks @Tom ...
Can't imagine it will be easy to remedy this functionality without breaking numerous linking solutions that currently use the value-based implementation.
Will be waiting with baited breath. haha
May 8, 2018 9:00 AM
We've just updated our forms to accept both values and labels for fields going forward so either can now be used.
I just tested the tokens out on an email within my portal and both dropdown and checkbox fields came through as their label values within the url.
Hope this helps!
May 8, 2018 9:28 AM - edited May 9, 2018 12:59 AM
Tom, "updated our forms"?? What exactly does that mean?
The issue is with the personalization tokens used in email pulling LABELS instead of internal values (for both dropdowns and multicheck boxes). (see image from today's test)
May 8, 2018 9:44 AM
Hey @MFrankJohnson from our tests we could see the form was expecting an internal value for dropdowns within forms and the personalization tokens were passing this appropriately.
We added acceptance for both value and label into the forms backend and when testing out a sting such as:
In my own portal and sending through an email, I'm being brought to: mydomain.com?dropdowntest=Label1&checkbox_test=Label1
With Label1 being the labels for the dropdown and checkbox fields and value1 being the values set for them.
May 9, 2018 1:07 AM
I was addressing the added dimension of the issue whereby we are unable to dynamically build URL parameters within HubSpot emails by using personalization tokens because those tokens use labels (which are clunky) instead of internal values over which developers typically have tighter controls.
This is particularly problematic when trying to dynamically pass parameters (via URL) to a page/system outside of HubSpot.
No worries. Appreciate the follow-up.
Apr 27, 2018 6:12 AM
I absolutely aggree with you, we should be consistent across all property types.
My testing seems to point to it only happening for dropdown selects, a multicheckbox for example appears to pull in the value.
If you spot anything else please me know though!
Nov 6, 2018 2:25 AM
I'm getting back to this case. It seems this bug still hasn't been fixed.
I've also found out that the same issue applies to radio select boxes.
This bug makes contact data updating very prone to user errors. We have these kinds of emails going to contacts for instance related to events and registrations.
Nov 9, 2018 6:13 AM
@tommifin What exactly are you seeing the issue with?
Checking a radio select box on my end, I can see this populate with both the label and the internal value selected. For example:
Both choose the second option with the internal value being "option_2" and the label being "two".
Do you have an example of what exactly you're seeing issues with?
Nov 13, 2018 2:44 AM
This is a bit complex case, I guess. I'll try to elaborate.
The problem is that the system doesn't pull the internal value of the field when trying to populate a field through an email link.
I was able to reproduce the issue with radio select with the following:
marketing_permission contact property setup
What is saved on a contact I used for testing:
How the field is presented on a form (in Finnish).
The system saves the label as the value of the field(?). The label used varies depending on the case and language used (you can specify the labels of each option on each form separately anyways). If the label value used in the URL parameter doesn't match the label options used on the form nor the internal value, which happens in my example, nothing is populated on the field.
Example, URL parameter in the email link generated by the system.
marketing_permission=Yes (label value saved for the contact)
=> Nothing is found on the form.
If the system would use the internal value of the option, the link would work, and language used on the labels wouldn't be an issue:
marketing_permission=yes (internal value)
Here's a quick example link:
I hope this helps! 🙂
Nov 13, 2018 5:00 AM
@tommifin We should detect both the label and the internal value for these, this was added in the update we made on our original discussion.
In the case of your example link, these values are all case sensitive. It looks like the internal value for your property is "yes" whereas your link had "Yes" as the value, which is invalid due to the first character being upper case.
Correctly populates the second radio select field for me.