Purpose: This document is a structured reference for what Journeys can do. Use it to understand what's available, what's not, and how to think through building a Journey for your specific goal — before you start building.
What is a Journey
A Journey is an automated, multi-step workflow that moves a person through a sequence of communications. Journeys are always tied to a person's record and execute logic on a per-person basis.
Entry: How a person enters a Journey
A person enters a Journey when they meet the defined entry condition. Entry types determine what starts the Journey for that person.
List membership entry (segment-based)
- Triggered when a person enters a defined distribution list
- Useful for attribute-driven flows (e.g., plan changed, date is today, location updated)
- When configuring this trigger, users choose whether to enroll only new members going forward or both current and new members.
On a schedule entry (scheduled/batch)
- A defined audience is enrolled at a set time or on a recurring schedule
- Useful for campaigns, digests, or periodic nudges tied to a date
Enroll recipients entry (manual)
- A person is manually added to a Journey by a team member
- Typically used drip campaigns or multi-communication series that are ran until an explicit date
- There's no dynamic enrollment — Workshop captures the audience at the time the journey starts.
Steps: What can happen inside a Journey
Steps are the individual actions and logic blocks that make up a Journey. They execute in sequence for each person, based on the path they follow.
Action steps
Send Email
- Sends a specific email to the person
- Supports dynamic content using person properties and event data
- Must be an automated email; can be created via a template
Timing steps
Wait until a specific time of day (Condition)
- Pauses the Journey until a specific condition is met – time of day
- If someone is enrolled after the scheduled time of day has already passed, there are two configurable options: wait until the following day at that time, or move to the next step immediately.
Wait for a set amount of time (Fixed Duration)
- Pauses the Journey for a set amount of time before proceeding to the next step
- E.g., wait 3 days, wait 2 hours
Wait until a calendar date (Condition or Date)
- Pauses the Journey until a specific date/time is reached
- This wait step is only available with the Enroll recipients entry
Wait until a specific day of the week (Condition)
- Pauses the Journey until a specific condition is met or a date/time is reached
- E.g., wait until the Monday after entry
Logic / Branching Steps
Conditional Split (If/Else)
- Divides the Journey into two or more paths based on a condition at the time the step is evaluated
- Conditions can be based on:
- List membership
- Open event – previously in the Journey, the person opened a specific email
- Open conditions in Logic are limited to emails within the same journey.
- Click event – previously in the Journey, the person clicked a specific link in a specific email
- Click conditions in Logic are limited to emails within the same journey.
- Percentage split – randomly divides people entering the step into two groups
- Used for testing message variants, timing, or flow differences
- Can be weighted (e.g., 50/50 or 80/20)
- Percentage split is probabilistic, not quota-based. The distribution is randomized per recipient, not evenly enforced.
- Each branch is independent and can have different subsequent steps
Exit: How a person leaves a Journey
A person exits a Journey when one of the following occurs:
- Completes the Journey: Reaches the end of their path with no further steps
- Exit condition met: A defined condition is evaluated mid-Journey and triggers early exit
- Global suppression: Person meets an account-level suppression rule (e.g., person has been deactivated as no longer a current member of their directory)
- Manual removal: A team member removes the person from the Journey
Data Available Inside a Journey
The following data types can be used in conditions, content personalization, and logic throughout a Journey:
- Person properties: Any attribute stored on the person record (e.g., name, custom fields)
- Event properties: Properties attached to any event used in an Action or Logic step
- List membership: Whether a person is currently in a given distribution list
- Journey metadata: When the person entered the Journey, which path they took, how long they've been in a step
Constraints and Limits
- A person cannot be re-enrolled in a Journey that they were just enrolled within the past 12 hours
- Automatic lists are not available on all Workshop plans therefore, you must verify if available on your customer account.
- Whether a Journey requires publishing permissions depends on the account's configuration. On accounts where user permissions are enabled, only users with publishing permissions can schedule or start a Journey. On accounts where permissions are not enabled, any user can create and publish a Journey without restriction.
- Recipients on the Do Not Enroll list are excluded from the Journey, but timing determines the outcome. If a person is added to the Do Not Enroll list before the enroll list is processed, they will not enter the Journey. If they are added to the enroll list first, they will be enrolled — even if they are later added to the Do Not Enroll list. Order of operations matters when both lists are configured.
What Journeys Cannot Do
Being explicit about limitations helps Cici avoid suggesting impossible configurations.
- Journeys are linear. They cannot branch on conditions such as actions taken in the Journey or lists.
- Journeys cannot send messages on behalf of a specific team member (e.g., a manager's email address)
- Journeys cannot read or write data to external systems directly
- Journeys do not support looping (a person cannot return to an earlier step within the same Journey run)
- Journeys cannot be triggered by changes to computed properties in real time [if applicable]
- Active journeys cannot be edited. Once a journey is live, it's locked. To make changes, you must clone it, edit the clone, and delete the original. This is a significant constraint users often run into and Cici should know it.