Custom Questions on Event Forms

Highlighted

Custom Questions on Event Forms

I'm a fan of burner fields like the ones described in Jeff's article: https://nation.marketo.com/; and also try to keep a minimal amount of universal forms (1 event form, 1 whitepaper/gated asset form, 1 contact us form, etc.) instead of creating a new one for every event or gated asset.

What I haven't been able to resolve though is the need to create a new version of our event form every time we are asked to add a new custom question. For example, for some events, the custom question is if they plan to bring a guest. For other events, it's what's their t-shirt size. It makes it more challenging when we're trying to scale things like just having 1 event program template to clone from and having to remember to swap out the form depending on the custom question needed for that particular event. Plus the added complexity of having to keep track and make changes to multiple forms when there's a universal change needed like new opt-in language. I can't just swap out the field on the form template since there are often live event pages that ask the other custom question.

Has anyone found a good way to avoid creating a new form when you have to add a different custom question?

3 REPLIES 3
Highlighted
Level 10 - Community Moderator

Re: Custom Questions on Event Forms

Are you talking about having the same multi-use field, but with different placeholder text and label? This is easy enough using JS (and the text can be in {{my.}} tokens).

Highlighted

Re: Custom Questions on Event Forms

Sanford Whiteman​ - not sure if that would work if the field types are different. Sometimes I need a boolean T/F field and other times I need a string field for picklist values. I don't know any JS so not sure where it needs to go (on the form or the LP hosting the form??). Do you have an article around this by chance?

Highlighted
Level 10 - Community Moderator

Re: Custom Questions on Event Forms

Yes, it does get complex if the widget types are different for the same underlying database field (though I feel that having one disposable field for each Marketo datatype is a better design, I detest when values can be either boolean-like or number-like or text-like for the same field).