We incorporate forms in many places on our website with multiple options on each one, so to make things more efficient on the production and maintenance side, we use one global hidden Marketo form in the background, with several hidden custom fields to capture specific information about what instance of the form they came from and what combo of things they are requesting as part of the form submission
For example, we have a form where someone can sign up for our email newsletter, and there's also a checkbox option to request our print catalog. We have another instance of this same form where someone can request a PDF with the same option to request a catalog.
We want to trigger different campaigns based on which instance of the form they came from and the different options they select within (for example, if they don't request a catalog, they do not need to be passed to our catalog fulfillment team. If they do, I want to deliver an email alert to the team.). But to be able to tell this, it requires looking at a combination of our custom fields. My question is, can I use multiple form fields as constraints in a single Smart List filter?
I tried "Fills Out Form" trigger, but there aren't constraints for form fields.
I tried "Data Value Changes" trigger with Source=Web form fillout, but I can only look at one attribute at a time, and I need to use multiple attributes. As I understand it, using two triggers is an "OR" relationship, not "AND."
Help?!!
Can you move this to Products? I’ll answer there, and it will get more visibility. There will be a Move link in your view.
Moved! Thank you, Sanford!
OK, thanks for moving it.
My first question is Why can’t you use a trigger on Filled Out Form, plus an ALL set of filters, including each of the fields?
That would be the most common approach. I’m not saying there aren’t exceptions where this wouldn’t be appropriate, leading to befuddling results. Buy why aren’t you trying this, exactly?
I've actually been doing this as a workaround for some time now, but wondering if there's some functionality I'm missing that would be more fool-proof. The data in the filters could already exist on the lead record due to a previous form fill, so I can't be 100% sure that my combination of trigger + filter(s) are actually part of the same form submission. I did create a smart campaign to clear out one of my custom fields each night, but that solution doesn't fit every business case.
There is something you can do that's more foolproof: package the entirety of a form data payload in a Textarea field. Then that payload can be processed, as a unit, by a webhook. I have a blog post coming out dedicated to this exact concept.
However, as a quicker fix, why not have these rules applied in JavaScript on the client side? (Note the above solution requires including JS on the client side, too, though it would be a universal snippet.)
In other words, include a global JS block that checks for known combos and adds hidden DateTime fields (100x better than Booleans!) when a known combo is matched. Then whenever there's a Data Value Changes for one of those fields you know somebody qualified.
Interesting! So I would first create a different DateTime field for each possible combo?
Our Javascript resources are a bit limited so in the meantime, would you still recommend your original suggestion to look at Fills Out Form trigger + ALL set of filters (for current data, not lookbacks)?
I'll be on the lookout for your webhook post. Thanks for the input!
So I would first create a different DateTime field for each possible combo?
Not necessarily: if you didn't mind overwriting the field on every form post, you could use a String instead, and have the String contain the current Timestamp (so it can always be detected by Data Value Chages) and the combo(s) they just qualified for.
It wouldn't be historically useful in this case, though, only useful in the trigger. DateTimes can show you the arc of someone's interest(s).
Could I use a Fills Out Form trigger plus a Data Value Changed filter that looks for a change on that field in the past 5 minutes, or something like that? Would that be more accurate?
I would never use an Activity Log lookback to increase accuracy, it's usually a recipe for decreased accuracy!