- Triggers decide when a supporter enters a journey (or advances to the next step).
- Conditions decide whether a specific supporter qualifies, and which branch they follow.
How Triggers and Conditions Work Together
A journey always starts with an entry trigger — the event that kicks things off. You can optionally layer entry conditions on top to make sure only the right supporters actually join. Once a supporter is in the journey, you can use:- Logic steps — yes/no branches that check a condition and send the supporter down the matching path.
- Trigger delay steps — pauses that wait for another event to happen before continuing.
- Exit rules — automatic off-ramps that remove a supporter from the journey when a condition is met.
Part 1: Journey Entry Triggers
Every journey starts with one trigger. Pick the trigger that represents the moment you want to reach out.Payment and Donation Triggers
Engagement and Communication Triggers
Peer-to-Peer Triggers
Pledge Triggers
Impact and Portal Triggers
Other Triggers
Tip: Some triggers require extra configuration. For example, Email Engagement Event needs you to specify which message you’re watching in the entry conditions — otherwise the journey won’t know which email to listen for.
Part 2: Journey Entry Settings
Before conditions even get checked, three entry settings control who is eligible to enter.Allow Late Entry
Controls whether supporters can enter the journey if the triggering event already happened before the journey was turned on.- Off — Only supporters whose trigger fires after the journey is live can enter.
- On — Supporters whose trigger fired before the journey launched can still enter retroactively.
One-Time Entry
Prevents the same supporter from going through the journey more than once.- On (default) — A supporter can enter this journey only once, ever. Even if they meet the trigger and conditions again later, they won’t re-enter.
- Off — A supporter can re-enter the journey every time they match.
Daily Limit
Caps the number of journey messages a single supporter can receive in a day (default is 7). This protects supporters from being over-messaged, especially if they qualify for several active journeys at once.Part 3: Conditions — The Rule Engine
Conditions are how you narrow a journey to the right people. They’re used in four places:- Entry conditions — filter who’s allowed to enter based on audience rules or trigger-specific rules.
- Exit conditions — automatically remove supporters from the journey when a rule is met.
- Logic steps — branch the journey into YES / NO paths based on audience rules.
- Trigger delay steps — wait for a specific event (with optional rules) before advancing.
Rule Groups: How AND / OR Works
Conditions are organized into rule groups. You control the logic at two levels:- Inside a group, rules can be combined with
ANDorOR. - Between groups, you can combine with
ANDorOR.
VIP OR are in the Newsletter list)
You can add as many groups as you need.
Part 4: Condition Types
Every condition is one of the field types below. Each type has its own set of comparison operators. A common question: why is there no “is not unknown” comparator? Several field types below listis unknown / has any value as a pair rather than is unknown / is not unknown. That’s intentional, not a gap — has any value already is the negation of is unknown. A field either has no value (is unknown matches) or it has some value (has any value matches); there’s no third state to express with a separate negated comparator, so one was never added.
Text Fields
Used for names, emails, phone numbers, addresses, notes, custom text fields. Operators:- is / is not
- contains / does not contain
- is unknown / has any value
Numeric Fields
Used for things like login count, total payments, engagement scores, session counts, message counts. Operators:- is / is not
- is greater than / is less than
- is unknown / has any value
Currency Fields
Used for total given, total given this year, EMRR (estimated monthly recurring revenue), pledge amounts, donation amounts. Currency fields share the same comparator set as Numeric fields (they’re the same underlying field type, just displayed with currency formatting). Operators:- is / is not
- is greater than / is less than
- is unknown / has any value
Date Fields
Used for created date, first donation date, last donation date, last seen, last message date, recurring plan dates. Operators:- more than / exactly / less than (for relative dates — how many days ago)
- on / before / after / between (for specific dates)
Select (Single Choice) Fields
Used for donor type (individual vs. company), lifecycle stage, recurring plan status, payment status, supporter status. Operators:- is / is not
- is unknown / has any value
Multi-Value Fields (campaigns, designations, tags, etc.)
Used when a supporter can be associated with multiple values at once — multiple campaigns, multiple designations, multiple tags. There’s no single generic “multi-select” type; each multi-value field (Campaigns, Designations, Tags, and similar collection fields) uses the same comparator set as Tag Fields below. Operators:- has / doesn’t have
- has at least one / has none
Boolean Fields
Used for simple yes/no flags like “do not contact,” account enabled, fee coverage preferences. Operators:- is / is not (with values of
true/false)
Tag Fields
Used to filter supporters by the tags applied to them. Operators:- has / doesn’t have
- has at least one / has none
Search-Based Fields (Donor, Campaign, Fund, Communication List, Journey)
These let you pick a specific donor, campaign, fund, communication list, or journey from a search picker. Operators:- is / is not
- is unknown / has any value
Transaction Query
A special condition type for filtering on donation activity. Instead of a single field, it lets you build a mini-query over a supporter’s transactions. Operators:- where / where not
- Amount (or amount range)
- Date (or date range)
- Campaign
- Campaign Event
- Fund
- Donor type
- Payment method
- Payment status
- Is Registration (Yes/No — matches whether the transaction has an associated event registration; useful for excluding event-ticket transactions from a generic payment-based trigger)
Part 5: Journey-Specific Conditions
A few conditions are unique to journeys. These let you build journeys that reference other journeys.
These are especially useful for preventing overlap — for example, “don’t enter this journey if the supporter is currently in our welcome series.”
Part 6: Step-Level Conditions
Once a supporter is inside a journey, two step types use conditions to shape what happens next.Logic Step (YES / NO branch)
A logic step checks audience conditions against the supporter and sends them down one of two paths:- YES path — They match the rules.
- NO path — They don’t match.
Trigger Delay Step
A trigger delay pauses the journey until a specific event occurs. It uses the same event list as entry triggers, and supports the same condition filters. Use trigger delays when the next step should depend on something the supporter does — for example, “wait for them to open the email” or “wait until their next donation.” The supporter waits indefinitely at this step until the trigger fires (or they exit via exit rules).Part 7: Exit Rules
Exit rules automatically remove a supporter from a journey mid-flow when a condition is met. Turn on Enable Exit Rules on the journey, then configure one or both:- Exit by audience — Exit when a supporter no longer matches certain audience conditions (e.g., they unsubscribed, got a specific tag, or stopped giving).
- Exit by event — Exit when a specific event happens (e.g., they made a new donation, so they no longer need the lapsed-donor series).