You did the right thing: you reduced 100s of unmaintainable forms to a handful of global forms. You use native Visibility Rules to show/hide fields based on user input.
Then your boss throws a curveball: “Can we show different fields if we already know somebody’s segment(s)?”
Uh-oh. Segmentations aren’t available as form fields. Makes sense, since they're system-managed and a person can never change their own segment. But the fact they're not available in Form Editor means you can't use them in VRs.
You can of course make the entire form element dynamic. But then you're back to cloning forms, recreating your maintainability nightmare.
But fret not, it’s easy to use segments in Visibility Rules. There’s just a little bit of back-end prep and front-end JS.
Create a front-end field
Create a new field as shown below. With my clients, I refer to such fields by their “pseudotype”: they’re form visibility manager fields[1] and we create one or two in every instance. In the Marketo database, its datatype is simply string, but to convey its special use we use the pseudotype.
You’ll use that field to trigger Visibility Rules, adding it to your form as Hidden w/Pre-Fill off:
Now, let’s figure out how to set Form Visibility Manager A to the person’s segment. You can run with native VRs from there.
Add two mktoText elements to the template
Add these elements right before the closing <body> tag:
<div class="mktoText" id="exportedMarketoFields" mktoName="Exported Marketo Fields"></div>
<div class="mktoText" id="formBehaviorsJS" mktoName="Form Behaviors JS"></div>
Exported Marketo Fields holds the main magic. You’ll make it dynamic in LP editor.
Form Behaviors JS is static. And if you already have a container for page-level forms JS (you should have one on every template, IMO!) just append the JS code to that one.
Segment and populate Exported Marketo Fields
In LP Editor, right-click and make Exported Marketo Fields dynamic. In this example, we’re segmenting by the segmentation called Channel, which has three named segments plus the default segment.
For each segment, open the HTML Source Editor and use a variation of the following code, with the segmentation as the <option label> and the segment name as the <option> text:
<datalist class="mktoFields">
<option label="Lead.Channel">Default</option>
</datalist>
That is, for the segment “Individual Investor”, use:
<datalist class="mktoFields">
<option label="Lead.Channel">Individual Investor</option>
</datalist>
For the segment “RIA”, use:
<datalist class="mktoFields">
<option label="Lead.Channel">RIA</option>
</datalist>
And so on.
Populate Form Behaviors JS
Next, add a bit of Forms 2.0 JS to read the value from the matching <option> and write it to the hidden form field:
<script>
document.addEventListener("DOMContentLoaded", function(e){
MktoForms2.whenReady(function(readyForm){
readyForm.setValues({
formVisibilityManagerA: document.querySelector(`datalist.mktoFields [label="Lead.Channel" i]`)?.value;
});
});
});
</script>(I’ll share a general helper function getExportedMktoTokens in an upcoming post, but you can use this targeted code for now.)
And that’s it, now you’re ready to use Visibility Rules based on Form Visibility Manager A!
Wait. Are you just not gonna talk about the <datalist>?
Definitely gonna talk about it!😀 But in a separate post. For now, just understand you must “export” {{lead.tokens}} and {{company.tokens}} like I did above to safely use them in JavaScript, because they are encoded for an HTML text context, not for a JS string context.
In other words, never do let string = "{{Lead.String Field}}". That can lead to fatal JS errors. You may not see them in casual testing, but your leads will feel the pain.
Notes
[1] Pseudotypes also include history fields, multivalued fields, and proxy fields. All have basic types under the hood, but a functional layer on top makes them special.
.png)
