Best practice for using if was sent email constraints in Smart Campaign flows | Community
Skip to main content
C
c_stevenson
New Participant
September 28, 2020
Solved

Best practice for using if was sent email constraints in Smart Campaign flows

  • September 28, 2020
  • 2 replies
  • 3219 views

Hi community,

 

I was hoping to find out what the best practices are for using filter choices and wait steps in the flow of smart campaigns. For example, when I am sending an email to customers, changing their program status and then adding them to a static list to ring fence those I have sent to, I have been setting up my smart campaigns as follows:

  1. Send Email "September Newsletter"
  2. Wait 1 minute
  3. "If was sent email September Newsletter" then "change program status to Email > Was Sent Email"
  4. Wait 1 minute
  5. "If was sent email September Newsletter" then "add to the Static List Was Sent September Newsletter Email"

If I am sending to every customer who is run through that flow, is it best practice to use the wait steps and the choices "If was sent email" or should I have it setup as below where there are no wait steps or choices included?

  1. Send Email "September Newsletter"
  2. "Change Program Status to Email > Was Sent Email"
  3. "Add to List Was Sent September Newsletter email"

 

I have been told that unless there is an action that needs time to occur before another flow step can be completed (i.e, the email CTA is to fill out a form and you need to wait 2 days to give them time to fill it out) then adding in wait steps and choices can causing a racing condition.

 

All help is appreciated

Thanks

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by SanfordWhiteman
changing their program status and then adding them to a static list to

Not clear on why you're using a static List in addition to a Program Status change. Both are permanent, and the Program Status gives you richer information.

 

Send Email "September Newsletter"
"Change Program Status to Email > Was Sent Email"

You can change the Status. Not necessarily any to look back in the Activity Log, which is unnecessarily resource-intensive.

 

Now, there is one case this will not cover, and that's when the Send Email step is ignored, for example if the person has Marketing Suspended = true.  But the flipside is that having the Send Email logged doesn't mean the person got the email, anyway; it could have any number of reasons to bounce instead of being delivered.

 

If you did find a concrete need to log only people for whom an email was actually attempted, I would strongly recommend using a batch, not a trigger.

 

 

... then adding in wait steps and choices can causing a racing condition.

It's not that adding Wait steps cause a race condition. It's that Wait stops cannot solve an inherent race condition.

 

There's no amount of of time that is guaranteed to be enough time in all cases, under all loads, for completely unrelated processes to complete. Concepts like "Wait 1m for a webhook to finish" are effectively random and not guaranteed to work. As you say — Waits should be used for deliberate marketing pauses only, not for guesses.

2 replies

Katja_Keesom
Katja_Keesom
Community Manager
September 29, 2020

I tend to use the Program Status as Sanford suggests. In addition, there is something to be said to use the Email is Delivered trigger rather than the Send Email trigger to ensure people who did not receive the email are not included in your member count. You may have a valid use case for using Sent, but it is worth considering which activity works best to achieve your goal both for reporting and for follow-up purposes.

C
c_stevensonAuthor
New Participant
September 29, 2020

Hi Katja,

 

Thank you for your reply. That is a very good point regarding the use of "if email was delivered". We plan to implement this into future campaigns as this is a much better way of more precisely identifying who was sent/delivered the email. Thanks again.

 

Cheers

Caleb

    SanfordWhiteman
    SanfordWhitemanAccepted solution
    New Participant
    September 29, 2020
    changing their program status and then adding them to a static list to

    Not clear on why you're using a static List in addition to a Program Status change. Both are permanent, and the Program Status gives you richer information.

     

    Send Email "September Newsletter"
    "Change Program Status to Email > Was Sent Email"

    You can change the Status. Not necessarily any to look back in the Activity Log, which is unnecessarily resource-intensive.

     

    Now, there is one case this will not cover, and that's when the Send Email step is ignored, for example if the person has Marketing Suspended = true.  But the flipside is that having the Send Email logged doesn't mean the person got the email, anyway; it could have any number of reasons to bounce instead of being delivered.

     

    If you did find a concrete need to log only people for whom an email was actually attempted, I would strongly recommend using a batch, not a trigger.

     

     

    ... then adding in wait steps and choices can causing a racing condition.

    It's not that adding Wait steps cause a race condition. It's that Wait stops cannot solve an inherent race condition.

     

    There's no amount of of time that is guaranteed to be enough time in all cases, under all loads, for completely unrelated processes to complete. Concepts like "Wait 1m for a webhook to finish" are effectively random and not guaranteed to work. As you say — Waits should be used for deliberate marketing pauses only, not for guesses.

    C
    c_stevensonAuthor
    New Participant
    September 29, 2020

    Hi @sanfordwhiteman

     

    Thank you very much for this explanation, that is really helpful. 

     

    So do you think it is better to do the ‘if was delivered email then update status’ in a separate batch campaign rather than in the flow of a campaign or in a trigger based (listener) campaign? 

     

    Cheers

    Caleb

    Terms & ConditionsAccessibility statement

    Loading footer...