1.2 Journey Lifecycle States and Canvas Management
Key Takeaways
A journey is editable in Draft, validated before publication, and read-only while Live; changing a live journey creates a new version.
Publishing a new version closes the preceding version to new entrances while people already inside can complete it.
Stopping a live journey is permanent for that version and removes people still in progress; duplicate it to run again.
A journey can time out after 91 days, so waits must fit inside the journey lifetime.
With reentrance allowed, a person must first exit; the wait defaults to five minutes and can be set up to 90 days.
1.2 Journey Lifecycle States and Canvas Management
A journey moves through an authoring and execution lifecycle. Exam scenarios usually ask whether to edit a draft, publish a valid journey, create a version for changes, or stop execution. The important behavior is what each action permits, not a fixed mnemonic for every badge the interface may display.
Draft, validation, and publication
A new journey is a Draft. Its canvas is editable and may contain entry, orchestration, and action activities. Saving does not prove that the journey can be published. Resolve blocking validation errors such as an unconfigured activity, invalid expression, missing channel configuration, or unavailable dependency.
Publishing makes that version Live. It can accept qualifying entrances, and its definition becomes read-only. This protects in-flight execution from an author changing logic underneath it. If the journey is ineligible for publication, Journey Optimizer reports errors that must be resolved.
Three preproduction methods serve different purposes:
- Simulation uses temporary simulated people for quick design iteration.
- Test mode runs persistent AEP test profiles through a draft and can deliver messages to test addresses.
- Dry run evaluates real production profiles while suppressing communications and profile updates.
These methods do not replace a production version.
Editing a live journey
To change a live journey, create a new version. The new version remains editable while the active version operates. When the new version is published, the prior version is closed to new entrances, while people already in that prior version can finish their paths. New qualifying entrances use the latest live version.
This boundary matters. Do not stop a healthy production journey merely to change a subject line or condition. Create, test, and publish a new version so the transition preserves in-flight profiles.
Referenced items can impose their own publication rules. For example, a changed offer decision used in a journey message requires republishing the journey so the message incorporates the change. A reusable content fragment follows its fragment publication and inheritance behavior. Identify the dependency type rather than assuming every reference updates identically.
Close, finish, and stop
A previous version can be Closed when a newer version is published. It accepts no new entrances but can still contain people completing their paths.
A journey can become Finished according to its execution or end criteria. A scheduled Read Audience journey, for example, may finish its planned run. The product can expose other statuses for operations such as test, dry run, or pause, so an incomplete “five states” list is unreliable.
Stop is a deliberate, permanent action on that version. It stops new entrance and removes people currently progressing through it. A stopped version cannot simply resume. If the business needs the logic again, duplicate it, validate the copy, and publish it. Stop is suitable for a severe defect or compliance incident, not routine editing.
End behavior and the 91-day lifetime
A path ends when it reaches an End activity or has no connected next activity. An explicit End makes intent visible, especially where branches should terminate clearly, but an unconnected terminal branch can end naturally.
Journey Optimizer applies a global 91-day journey timeout. A person still active when that limit is reached leaves the journey. A Wait activity can be configured for no more than 90 days, preserving room for the remaining path. Long-lived programs should use bounded journeys or a supported transfer pattern instead of assuming a profile can remain indefinitely.
Reentrance
Reentrance answers whether the same profile may enter the same journey again. It is separate from whether different people can enter.
- With Allow reentrance off, a person cannot start the journey again.
- With it on, the person still cannot reenter while already active. They must exit first.
- The wait defaults to five minutes and can be configured up to 90 days.
- The control applies across journey versions, preventing a new version from creating a duplicate path for someone still active in the preceding version.
Choose the wait based on purpose. An order-confirmation journey may allow another entry after the earlier order path finishes. Onboarding may disallow reentry. A cart reminder should prevent repeated events from creating excess message pressure.
Publication checklist
- Verify the entry activity and namespace.
- Check every branch for an intended end.
- Confirm waits, caps, time zones, schedules, and the 91-day ceiling.
- Verify channel configuration, consent, suppression, and personalization fallback.
- Test representative profiles, including missing-data and ineligible paths.
- Confirm that audiences, actions, fragments, and decisions are usable.
- Publish, then monitor entrances, exits, actions, errors, and discards.
Tip
If a lifecycle question asks you to preserve people already inside, versioning and closing the prior version is usually safer than stopping it.
A live journey needs a corrected condition while current participants must finish their paths. What should the practitioner do?
Stop the journey and edit it in place.
Delete it and recreate it with the same name.
Leave the error because live journeys can never be changed.
Create and test a new version, then publish it so the prior version closes to new entrances.
What happens when a live journey version is stopped?
It permanently stops that version and removes profiles still progressing through it.
It pauses and can always resume.
It creates a draft automatically without affecting participants.
It only prevents reporting updates.
Which statement about reentrance is correct?
Allowing it lets the same profile start another instance while still active.
A profile can reenter only after exiting, and an enabled wait can be configured up to 90 days.
It is configured only on Email actions.
Publishing a new version bypasses it.
Sections you finish are checked off in the contents.