Have you tried adding "Select your Province" just before the Canadian states in your master? I've found that anything that is in my master list will show up when I then specify visibility rules.
Sadly this does not fix the problem.
Why not just use "Select State/Province" ?
This is a global form. I am only using province as an example. This is what it would need to look like if I did this suggestion.
"Select Your State/Province/Region/Canton/Emirate/Country"
I do not think that is very professional.
I am confused why this is even an issue. Am I the first person who has used Marketo that needs this functionality? Is this truly an issue with Marketo??????
How about this: leave the Select field as is and change the field name to State or Province so it looks like this:
I'm thinking this is why they put in the ability to change the field name and it still seems professional to me AND it is personalized/localized to that region which really shows you bumped the lamp .
Hope this solves your problem.
I would agree with you as well. Unfortunately the way our forms are designed we remove the field labels. All identifying info is located in the field not next to it.I am thinking Marketo designed it this way, which is unfortunate.
This is a bug and I have been trying to find a solution. Inline text gets erased somehow when there are visibility rules. I cant even set the text with jQuery.
Did you ever find a workaround?
Update - this is working for my simple need:
I configured visibility rules to default to show state field and make it hide if any country is selected besides US
the first option has to be "state:" so it shows up
you could add a listener and switch which option has the selected="selected" attribute based on which country, but at that point you might as well just write your own visibility logic.
timeout is because I am embedding the marketo form
1 of 2 people found this helpful
Hmm, you should never use timeouts to (attempt to) predict call order in an asynchronous environment. It's bad programming practice and destined to fail.
Forms 2.0 includes a robust event API that's designed to eliminate the "likely call order" antipattern and race conditions. If you want to do something after an embedded form is ready, just do it in an onReady listener (the 4th argument to MktoForms2.loadForm). The form element is guaranteed to be in the DOM at the time it is called.
P.S. No reason to use jQuery to set the selected index: the Forms 2.0 method form.setValues() exists for this purpose.
By the way, while there are many ways to skin this cat, one simple way is to add all your states/provinces/cantons to the same list, prefixing each with the country name:
This list becomes the template from which you draw or discard elements. Working with SELECTs is much easier when you maintain an out-of-band template element like this.
Then use some boilerplate to populate the live SELECT from the template as needed: CodePen - MktoForms2 :: Dependent Country-State/Province
Thank you for your comments. I've moved most of my external altercations to the forms API, works like a charm.
As for the overall issue here... I think that having to prefix values is bad UX. There needs to simply be the option in the visibility rules to select the default for each rule. Although your solution you used in that pen^ works well and I will probably end up mimicking, its ~30 lines of js that should be built in and I would hate to have to update every time my company decides to move into another territory.
You don't have to prefix values. Heck, you could use an intuitively-named JS object or array of objects, or whatever data structure you want. And you could even fetch the list from your server via Ajax so the list can be stored separately from the form....
Anyway, I agree that having more robust (or at least bug-free!) built-in business rules would be good, but my experience with form builders is that I always want to do something the form builder doesn't do natively: no matter how much it offers, it somehow doesn't fit my I-don't-think-it's-crazy use case or preferred UX (on the client side). That's why I'm glad that the Forms 2.0 API exists because you really can hook in unlimited logic but you don't have to sync your own back end with Mkto.