The Journey That Stalled at the Wait
A bank builds an onboarding journey: accountOpened event → send welcome SMS → wait 3 days → condition (did the customer complete profile setup?) → if yes, send a tips email; if no, send a reminder. In production, a large share of customers never receive the tips email or the reminder - the journey seems to stop after the SMS. Investigation shows: (a) the condition checks a profileSetupComplete attribute, (b) that attribute is updated by a downstream KYC system that writes to the profile, and (c) the wait is configured as a fixed 3-day wait. Customers who complete setup are not moving forward, and customers who don't complete setup are also not moving forward. The SMS sends fine.
1. Given that the SMS sends but nothing after the wait does, where would you focus, and what are the most likely explanations?
Read the worked answer
Since the SMS (before the wait) sends, entry and the first message work. The failure is at or after the wait. Focus there:
- The wait itself. A fixed 3-day wait holds the profile for 3 days. If the journey is being tested or the profile is being removed/merged, or if the journey has an end date/expiry shorter than the wait, profiles exit before resuming. Check journey end conditions and any global timeout.
- Condition evaluation data. The condition reads
profileSetupComplete, written by a downstream KYC system. If that attribute is not actually populated on the profile (wrong field, wrong namespace, sync failure), the condition may evaluate to neither branch cleanly - or error - and the profile stalls. - Profile identity mismatch. If the KYC system writes to a different identity (e.g., a different ID namespace) than the journey uses, the attribute never lands on the journey's profile.
The fact that both branches fail points away from the condition logic and toward something common to both: the wait's exit, the journey's end date, or the attribute never being present.
2. The team wants to switch the fixed wait to a 'wait until' the profile attribute becomes true, with a timeout. Explain how this changes the design and what you must verify.
Read the worked answer
A wait-until-condition (with timeout) changes the journey from time-driven to event/attribute-driven:
- Instead of always waiting 3 days, the profile proceeds as soon as
profileSetupCompletebecomes true, or after a maximum timeout (e.g., 3 days) if it never does. This both speeds up the happy path and guarantees the reminder path fires.
What you must verify:
- The attribute is reliably written to the same profile the journey uses - same identity namespace, correct field. If it isn't, wait-until will simply time out for everyone (same symptom, new cause).
- The attribute actually changes (false→true). A wait-until on an attribute that never updates will always hit timeout.
- Timeout branch is defined and routes to the reminder.
- Test both paths: a profile that completes setup (should exit early) and one that doesn't (should time out and get the reminder).
Principle: a wait that depends on profile state is only as good as the reliability of that state. Verify the data contract before changing the wait type.