Journey Orchestration
Core mental model
A journey is an event-driven state machine. The entry event (unitary event, audience qualification, or a segment-based read audience) starts a profile's path; orchestration events (business events) can re-route an in-flight profile; reactions respond to message feedback (sent, delivered, opened, clicked, bounced, failed). Understand conditions (branch on profile attributes, events, or expressions), wait activities (duration or time-based, plus wait-for-event with a timeout), actions (channel sends, custom actions), and jump/end activities.
Concepts candidates must know
- Journey properties: read audience vs qualification; re-entrancy and allow re-entry settings; test mode and timeout/error handling.
- Execution model: profiles advance asynchronously; a wait holds the profile in the journey's runtime store, not in a queue you can inspect per-profile.
- Data source / field group mapping to the journey schema; custom actions use an external data source and a request/response payload.
- Journey limits: max number of live journeys, max activities per journey, and throughput governed by profile ingestion and channel capacity.
Traps
- Confusing audience qualification (profile enters when it qualifies) with a read audience (batch entry at scheduled read). Questions often hinge on whether a profile that qualifies after journey publication will enter - with qualification, yes; with a read audience, only at the next read.
- Assuming an orchestration event can start a journey - it cannot; it only affects profiles already in the journey.
- Forgetting that re-entry must be explicitly enabled and that a profile can only be in one instance per journey unless re-entry is on.
Rule of thumb
If the scenario says "profile should enter as soon as it qualifies," choose audience qualification; if it says "process the segment on a schedule," choose read audience. Always check re-entry before reasoning about duplicate sends.