I have a journey which looks at SFDC data and and has a wait activity based upon an attribute date/time field. The wait activity is 'wait until 3 days before trial end date'. A customer can have multiple records that meet the criteria e.g. Journey is for a trial period, and a customer can have more than one trial.

It appears that the Wait by Attribute activity is being ignored whenever the same customer re-enters with a previous trial and trial end date. E.g. I did a trial that ended on 1/1/2021. I signed-up for another trial that ends 12/31/2021. I immediately get the email for the ending date 3 days prior (should be 12/28/2021), I'm assuming because it finds my old record and thinks the date has already happened.

Has anyone run into this issue before? I'm assuming it's because how the contact data model is setup. Any troubleshooting ideas? I looked at the documentation on Attribute-Based wait activities but didn't find it helpful.

1 Answer 1


This is a very typical Journey Builder / Attribute issue.

You have a 1:n relationship, one "person" can have many "trial date" records.

Journey Builder has just one way to deal with 1:n relationships, it applies a "at least one record matches the criteria" logic. That looks exactly what it's doing in your case, as you rightly interpreted. "at least one date is 3 days before trial end date" evaluates to true.

You want a 1:1 relationship, for which you can think of this: one "person" has probably only one UNPROCESSED "trial date" record at a time.

So I would introduce a logging mechanism: every combination of user and trial date that has passed the journey once is upserted into a log data extension where (let's keep it simple) they get a field "processed" set to "true".

Now you can check if people / date combinations have passed before and exclude them.

Make that a part of an SQL preprocessing logic (SELECT only subscriber & date combinations that are not in the log with "processed" != "true" next to them - in other words: ignore all entries that have already been through the journey), which I would recommend over using decision splits.

now journey builder will only contain people & unprocessed trial events, and hence should wait correctly without interference from already processed data.

You must log in to answer this question.

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