Channel Orchestration
Part of Lifecycle message rules and exclusions
Handling missing event data in journey entry rules
Treat missing events and properties as unknown, diagnose the source and choose a safe journey-entry fallback.
When a required entry event or property is missing, treat the customer’s state as unknown until another reliable record resolves it. A missing event is not proof the customer did nothing.
Hold entry, use a less specific response or refer the case for review according to what the missing fact would change.
Identify the missing fact
| Problem | What to inspect | Immediate decision |
|---|---|---|
| No event received | Source feed, event timing and customer ID | Avoid a claim that the action did not happen. |
| Event lacks a required property | Payload and tracking definition | Hold a branch that depends on that property. |
| Event belongs to the wrong person or account | Identity and relationship records | Do not transfer the state by assumption. |
| Event arrived late or out of order | Occurrence and processing times | Reassess current state before entry or send. |
A recorded failure can justify troubleshooting; a blank success field cannot. If a task can finish offline or through another account member, specify how that result reaches the entry rule.
State the minimum evidence for entry
Write the rule in plain language: required event, valid outcome, identifier, time window and properties. Name the authoritative system when records disagree. Specify what happens when each field is absent.
Silently treating unknown as false can send a “you have not started” message to someone whose completion feed is delayed.
In a hypothetical setup journey, confirmed account creation may permit a neutral orientation message. Saying the first task remains unfinished requires dependable task-state evidence. If the completion feed is unavailable, hold that reminder or offer help without asserting failure.
Customer.io’s entrance troubleshooting advises checking that the automation is live and checking the trigger and its conditions, including filters. For automations triggered by attributes and/or segments, it also describes a 30-minute period for matching segment filters. It notes that an event won’t trigger an automation if its Timestamp is before you activated the automation, before the person existed, or more than 72 hours before Processed At, unless the automation’s first action is a longer delay.
Profile activity distinguishes an event’s Timestamp from Processed At. Processing after launch alone is not sufficient for every backdated event: Customer.io also documents timestamp conditions that can prevent entry.
Key Thresholds and Conditions
- Event timestamp limit
- Not before automation activation or person’s existence
- Offline completion allowed
- Yes, if specified how result reaches entry rule
Set a recovery rule
Give unresolved records an owner and a review time. If a late event arrives, decide whether the journey is still useful instead of releasing old prompts automatically.
Preserve corrections and reassess current eligibility. Count data holds separately from deliberate exclusions so a fall in entries does not hide a feed problem.
Review histories with no event, a missing property, a late success, an event on another account and a duplicate. For each, record the expected entry or hold and the wording that would be safe.
Compare the configured trigger with the underlying source record. The appropriate fix may be the event feed rather than another message.
