Wait-until message condition: has-ever been sent vs is-sent after wait entry
Has-ever can skip on ancient history; is-after-entry only counts sends after Wait entry. Timeline, table, Leadara mapping.
Niloofar Karimi
Product positioning, messaging, and content for product growth—aligned with product and sales.
September 30, 2026 · 5 min read
Also available in فارسی
Has-ever can skip the wait on ancient history; is-after-entry only counts sends that happen after the person arrives in the Wait—so last month’s transactional receipt should not accidentally unblock a follow-up path.
What does a wait-until message condition actually mean?
Picture a Wait until … message sent/delivered step: you want a reminder SMS a day after the “getting started” email goes out—or to open a branch only when that email sends.
Two common readings of “message sent”:
- Has-ever: if that message (or a same-named campaign/template) was ever sent to this person in history, the condition is true now and the Wait may skip immediately.
- Is-after-entry: only sends that occur after the person enters this Wait step count. Last month’s receipt does nothing.
If you use has-ever for a post-order education follow-up, someone who got a purchase receipt last month may skip today’s Wait and receive the education SMS without a fresh email—or reopen a path on a stale signal.
Related: wait until event vs fixed delay, time-capped vs indefinite wait, and event must occur while in delay vs prior counts.
Comparison table
| Dimension | Has-ever | Is-after-entry |
|---|---|---|
| Send from last month | Can satisfy | Ignored |
| Immediate Wait skip | Common if history is positive | Only if a send happens after entry |
| Best for | “If they ever got this education series…” | “Wait until this path’s email sends” |
| Risk | Stale signal opens the path | If Send sits before Wait and never repeats, you can stall |
| Required QA | Profile with old send | Clean profile + profile with old send |
Timeline: order receipt vs education email
| Time | Event | Has-ever on “receipt email” | Is-after-entry on “onboarding education email” |
|---|---|---|---|
| July 1 | Order receipt sent | History positive | — |
| Sept 1 | Enter post-purchase education journey | Wait may skip immediately if keyed off receipt | Waits |
| Sept 1 10:05 | This path’s education email sends | — | Condition true → continue |
| Next day | Education reminder SMS | May go without a fresh email | Goes after the fresh email |
Lesson: for follow-ups that depend on this send, require is-after-entry (or “must occur while in the wait window”)—not has-ever on a receipt template.
Second example: OTP SMS vs promo SMS
If Wait is “any SMS sent” with has-ever, yesterday’s OTP may satisfy the condition. Scope the condition to that path’s message/template, preferably after-entry.
Why teams get confused
- UI says “message sent” without a time scope;
- template name matches an old campaign and has-ever sees all history;
- Send is placed before Wait so after-entry never sees a new fire—step order matters;
- mixing this with behavioral “event must occur while in delay.”
Truthful Leadara mapping
With Leadara journeys, events, and email/SMS:
- design wait-until on send/engagement-related events carefully;
- write in the brief: “historical send is enough vs only sends after Wait entry”;
- for post-purchase education, do not let stale receipt signals open the follow-up;
- combine with time-capped waits so a wrong has-ever neither infinite-stalls nor false-skips forever.
If a competitor exposes literal has-ever / is toggles and Leadara does not use those labels, document the practical pattern with scoped events and Send→Wait ordering—do not claim a one-to-one switch.
Leadara AI Chat is an internal assistant. Live Chat is human support.
When has-ever vs after-entry
| Scenario | Prefer |
|---|---|
| Follow-up only after this path’s email | Is-after-entry |
| Branch “already saw this series” | Has-ever (on purpose) |
| Months-old transactional receipt | Has-ever is dangerous |
| Send before Wait in the same path | Fix order; after-entry needs a send after entry |
| Engine docs unclear | Mandate both QA profiles |
Practical steps
- One brief line: “Wait for message X = after entry / has-ever.”
- Define X as a specific template/campaign—not “any email.”
- Step order: enter → (optional delay) → Send X → Wait until X after entry → Send Y.
- QA: profile with old X; clean profile; profile that gets X after entry.
- Read immediate Wait-skip logs after launch.
- Log quiet hours separately so they are not blamed for condition skips.
- If has-ever is intentional, label the path “historical on purpose.”
Common mistakes
- defaulting to has-ever without reading docs;
- conditioning on “any message” instead of that template;
- placing Send after Wait while expecting after-entry without a send;
- ignoring high-order-frequency profiles with heavy transactional history.
FAQ
Why did my contact skip the wait for “email sent”?
Likely has-ever matched an old send, or step order made the condition already true.
Does wait-until message condition count historical sends?
Depends on scope: has-ever yes; is-after-entry no. Lock it in the brief.
When should I use has-ever vs is-sent after entry?
Path-dependent follow-up → after-entry. “Already seen” branch → intentional has-ever.
What if the email was sent before they reached the Wait?
For after-entry that usually does not count unless it sends again. Fix Send/Wait order.
Is this the same as “event must occur while in delay”?
Cousin idea; that article is more about behavioral events, this one about message-send scope.
Does Leadara Live Chat explain this?
Live Chat is human support. Wait design is your team’s job; AI Chat is internal only.
What about a time cap?
If after-entry never becomes true, use a time-capped Wait for a fallback path.
Success metric?
Near-zero skips caused by stale receipts, and reminder SMS only after this path’s fresh email.
Next step
Open one post-purchase journey with a message Wait. Build two profiles: old receipt vs clean. See whether the Wait skips. Lock has-ever vs after-entry in the brief and fix Send order.
