Forms: Mixing Visibility Rules with Progressive Profiling

[Anonymous]

Hey Team,

To accommodate the broad audience that we sell/communicate to, I've had to build a form that starts with the initial set of fields:

- name

- email

- prospect type

Based on their type, the form then "branches" out to 7 different paths to collect the information that is unique to each type.

The remaining fields were built in the following hierarchy. I "mapped" 14 progressive fields to the 7 different prospect types using visibility rules.

Tier 1 - Required Field

Tier 2 - Progressive Profiling

Tier 2a - Visibility Rules Enabled for Prospect Types

     - Type 1 = Fields 1-7

     - Type 2 = Fields 8-11

     - Type 3 = Fields 8-11

     - Type 4 = Fields 8-12

     - Type 5 = Fields 8-11, 13, 14

     - Type 6 = Fields 8, 9

     - Type 7 = None

I set the number of blank progressive fields to 2, thinking that the progressive function would would "skip" over the fields not applicable to the respective prospect types. However, this is not the case.

For example, if a prospect identified themselves as Type 6, no progressive fields would display. For a Type 2 prospect, no progressive fields would display. Only by increasing the number of blank progressive fields to 14 could I get any fields to show for Type 5. At that point...my form looked horrendous for all users.

Any way to get around this?

[Grégoire_Miche2]

Hi Eric,

Unfortunately, this will not work, at least not without some JS coding.

-Greg

[Anonymous]

Hi Greg,

Thanks for the tip. Would you be able to explain, in general terms, how the JS would control the paths and progressive fields? I could talk to my developer and see if he could help out.

Thanks,

-Eric

[Anonymous]

Hi Eric,

You will have to write javascript which will be able to read the values for each of the 14 fields for that lead. It would also need to have business logic to hide and unhide respective set of fields based on the 'prospect type' field value.

Rajesh Talele

[SanfordWhiteman]

I'll post a demo tomorrow showing how this can be done. 

[Anonymous]

Sweet, looking forward to it Sanford.

[SanfordWhiteman]

Still gonna do this.  Sorry for the delay.

[Anonymous]

Would love to see it too!

[SanfordWhiteman]

Thx for the bump. This demo is done but I forgot to link to it. Will do tonight.

[SanfordWhiteman]

Here's the demo:  MktoForms2 :: VR + PP Advanced

While there's a lot of code, the only part you'd need to modify is the topmost config object:

  var ppOptions = {
   progProAfterField: 'Business_Unit__c',
   progProMaxShown: 2
  }

Here, I'm specifying that the ProgPro fields begin after the field Business_Unit__c (while this info is also part of the form config, we can't read that directly, so we need another hint).

And I'm saying I want to see a max of 2 ProgPro fields, which might also seem redundant since that's also in the form config, but in this case it's not because in the Forms 2.0 Editor we're going to set the "Number of Blank Fields" to the same as the number of ProgPro fields:

There are 4 ProgPro fields defined, and within the editor we've also set the number of blanks to 4.  This is because we're going to control the actual visibility in the browser, so we need to make sure nothing is prematurely hidden.

The first two ProgPro fields also have VRs applied:

The final result is that changes to the non-ProgPro field Business Unit affect which other fields are displayed, simultaneously obeying the ProgPro max rule and the Visibility Rules.

The main trick to the code is the injection of a dynamic CSS stylesheet into the page.  While the stylesheet is simple, its contents depend on the ppOptions config object noted above, so it can't be hard-coded:

.mktoFormRow[data-wrapper-for="Business_Unit__c"] 
~ .mktoFormRow[data-wrapper-for]:not([data-wrapper-for=""]) 
~ .mktoFormRow[data-wrapper-for]:not([data-wrapper-for=""]) 
~ .mktoFormRow[data-wrapper-for]:not([data-wrapper-for=""]) {
  display: none;
}