8

I've observed a new behavior for emails sent from Journeys. In previous releases of Journey Builder, if an email failed to Send to a Contact, then the Contact would just keep on progressing through the Journey.

But in the latest release, I note that Contacts are immediately ejected from the Journey if they are suppressed from sending. For example, if you open the 'Contact Details' for an Email Activity in the Journey, you will see 'Hard Errors', which includes reasons like 'List Detective removed this contact' or 'on suppression list'.

Journey Builder Email Activity Contact Details

The odd thing is that they are actually removed from the Journey. True story. If you search for any of these Contact Keys in the Journey Health UI, you will see that the Contact is immediately ejected from the Journey:

Journey Health

As a result, the Contact will not arrive at any subsequent activities, for example, an SMS Activity, Update Contact, etc. What if you want to send them a message over a different channel (SMS, Push,or WhatsApp) if they don't open the email?

Do you know if there is a method to prevent Contacts being ejected from a Journey if the email is not sent? I can't think one, but I thought I'd ask the question...

Improve this question
3
  • Hey Elliot, I've seen this behaviour and I've been seeing it for quite some time. However, I can recall this happening in our journeys at least 6 months ago (the journeys in question were email-only so never really bothered me). What makes you think it is a recent release change? FYI I'm also curious to know if there is a way to avoid this.
    – Ben
    Jun 24, 2021 at 2:48
  • Hi @Ben, the previous behavior was that Contacts were kept in Journeys if the Email Activity failed to send, but I haven't checked this for some time, so perhaps this isn't a recent change.
    – Eliot Harper
    Jun 25, 2021 at 0:17
  • Fair enough. Not something I have been watching closely. Agree with you though that they should just continue on through the rest of the journey.
    – Ben
    Jun 25, 2021 at 0:58

1 Answer 1

Reset to default
2

Very interesting. I have no solution to the problem of "keeping invalid emails in the journey" (and I would consider this a problem, as it is very shortsighted exception handling and counteracting one of the supposed strengths of the tool) - but some systematic workarounds / implementation patterns:

The message I take out from this - validation has to happen before the journey, and journeys profit from being short. Some things to consider.

  • split journeys by channel wherever possible (I know, the UI and all the product marketing tells you otherwise!). In general I am a proponent of many short journeys instead of few long journeys - and here is a new reason why I think this is a helpful pattern.

  • Make suppression lists part of your standardized selection before injection - it's not real-time, but it should be rather broad in covering this; if someone's on suppression list -> going back to my previous point, directly push such addresses into a dedicated mobile journey instead of the email one.

  • at a project level: make it a habit when migrating data to include list detective checks ( e.g. import into lists).

  • make it a habit to discuss list detective exceptions with the client at project outset when you first check their data, and lift the relevant list detective bans through support

  • make things that prohibit email sendouts part of subscription and email change workflows. Check suppression lists through script or API and perform list detective validation through API (REST address/v1/validateEmail) at the first email touchpoints (e.g. registration). This will mitigate these problems at the source, and at least keep the problematic behavior out of journeys.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .