Re: Will a second form submission stop an email drip from the previous form submission?

Anonymous
Not applicable

Here's the scenario:

Customer fills out form.

Makes a certain choice from the dropdown.

That choice sets off a series of emails.

Before that email flow is finished, same customer fills out the same form, but makes a different choice from the dropdown.

That new choice sets off a separate series of emails.

Does that then stop the first series of emails?

26 REPLIES 26
SanfordWhiteman
Level 10 - Community Moderator

Can you move this to Products as it's Marketo-specific? Move link will be at the right.

Anonymous
Not applicable

Moving it now. Thanks!

SanfordWhiteman
Level 10 - Community Moderator

The answer is no, there's no inherent relationship between these flows. And that's a good thing.

You can create such relationships yourself using the "Remove from Flow" Flow step.

Anonymous
Not applicable

That's what I was hoping to hear.

If a customer expresses interest in one product by choosing it in the drop down, they start getting some emails about that product.

If they then fill out the form again, and express interest in a different product, I want to be sure they start getting the emails for the second product, without stopping the emails from the first product.

But doesn't the second choice overwrite the first in the contact record?

Anonymous
Not applicable

If you are not using a temporary field to store product interest value from the forms, then yes it would. I suggest you use a field like "product interest temp" in the form, and then set up a smart campaign:

IF data value changes in field “product interest temp”

THEN Change data value for “Product interest” = {{lead.Product Interest}} {{lead.Product Interest Temp}}

This way the new value will be added to the old value rather than replace it.

Anonymous
Not applicable

I'm a bit lost in writing this rule.

Am I on the right track here:

Screen Shot 2017-10-05 at 3.44.02 PM.png

Anonymous
Not applicable

Hey Peter -

To echo Sanford, you don't need to do this. As he said, "if a Data Value Changes trigger brings someone into a flow, they don't get booted from the flow if the value changes again later. They're already in the flow."  In other words, say Laura completes form and chooses Product A, I'm guessing this kicks off a smart campaign something like this:

Trigger

Data Value Changes->New Value is: Product A

Flow:

Send Product A EM1

Wait

Send Product A EM2

Wait

Send Product A EM3

etc.

If Laura comes back and fills in the same form again and chooses Product B, presumably that will kick off:

Trigger

Data Value Changes->New Value is: Product B

Flow:

Send Product B EM1

Wait

Send Product B EM2

etc.

The fact that the Data Value was changed to Product B later, has no impact on the chain of events triggered by the selection of Product A.

And where Sanford said "And you can (and probably should) be using list or program membership to permanently record their interest anyway.", you can insert something like this into your flow so that you keep track:

Trigger:

Data Value Changes->Product Interest-New Value=Product A

Flow:

Add to List

Choice 1:

If Product Interest = Product A

Add to List: Interested in Product A

Choice 2:

If Product Interest = Product B
Add to List: Interested in Product B

Send EM1 for Product A

Wait xxx

Send EM2 for Product A

Hope that helps!

- Denise

Anonymous
Not applicable

Denise, thanks again.

You're right about the email flows following the form submissions.

Part of my puzzle is that I don't want to kick off multiple email drips at one time. And I don't want people making more than one product choice on the first form submission.

I think the way to handle this is to use lists, as you've suggested.

I've pushed the customer on checkboxes, and I'll wait and see what they say.

Thanks!

Anonymous
Not applicable

Hi Peter,

Re: Part of my puzzle is that I don't want to kick off multiple email drips at one time.

I thought in an earlier post you had said that you DID want to kick off multiple email drips. Maybe  you mean you don't want them going at the same time. If that's the case, there are a variety of ways that you could accomplish that: - but recommending exactly how to do that would require a lot more detail about your particular setup and goals. At a high level, here are a couple of options:

1) Create separate drip campaigns for each of your 5 products and don't let someone into email drip 2 if they are already in email drip 1 until the have received the last drip 1 email.

2) Create Engagement Programs for each of the products and have them send on alternate weeks

Re: And I don't want people making more than one product choice on the first form submission.

Use radio buttons - or use the drop down without enabling multi-select.

Denise

Anonymous
Not applicable

Thanks Denise. You're correct, I don't want people getting separate email drips at the same time.

I've landed on using the dropdown as the client prefers, and creating lists that capture product specific interest.

That way, a prospect would really have to go out of their way to get into two drip campaigns, in which case I don't mind sending them the additional email.

Thanks again for your help!

Anonymous
Not applicable

This is fantastic information.

Thank you all so much!

Before I start processing the latest suggestions, one quick question:

Would checking the Multiple Selections box on the drop down select field editor solve this problem?

SanfordWhiteman
Level 10 - Community Moderator

Would checking the Multiple Selections box on the drop down select field editor solve this problem?

That would turn the <select> into a <select multiple>. It's a standard HTML widget, but looks different from a single-select <select>. If the client is cool with it then it'll work well.

Anonymous
Not applicable

Thanks yet again, Sanford.

I've decided to keep the dropdown, then create lists to track the product interest, which I have to do anyway to provide product-specific email communications.

SanfordWhiteman
Level 10 - Community Moderator

This step (the way you've started to build it out) won't do what you expect.

If you must maintain a history field, your Smart List triggers on ​Data Value Changes - Last Product Choice (see no reason to call it "temporary," it's simply the last submission).

Then your Flow sets Product Choice History to {{lead.Product Choice History}};{{lead.Last Product Choice}};, simple as that (the surrounding semicolons are purposeful).

But I still feel you're overengineering this.  Remember how many other fields you'd have to manage this way as your instance matures, if this becomes the standard method. Simplicity should be your guide and I don't see the upside here.

Anonymous
Not applicable

Just to be clear, I would switch out the current Product Interest field for a Product Interest Temp field?

Anonymous
Not applicable

Yes, this way you'd be able to store multiple product interest values in "product interest" field, if that's what you want. If you have very few products then you should probably follow Sanford's advice and create several fields, but if you have dozens of product creating a distinct field for each one of them probably would be a management hell, so my proposal would work best.

SanfordWhiteman
Level 10 - Community Moderator

but if you have dozens of product creating a distinct field for each one of them probably would be a management ****, so my proposal would work best.

But you still don't need a formal history field if nothing else is being historically recorded (i.e. you're not adding {{system.datetime}} or other metadata to history entries).

You can have a multi-valued Checkboxes set in that case, which Marketo will automatically manage as a semicolon-delimited field. 

Anonymous
Not applicable

Paul thanks for your comment.

In that case, it would be okay to use a dropdown?

Anonymous
Not applicable

Yep.

SanfordWhiteman
Level 10 - Community Moderator

Sounds like you're needlessly complicating matters by trying to use a single field.  How many products do you actually have?  Is it more than can be reasonably handled by individual Boolean (or, even better, individual DateTime) fields?