Journey Triggers and Conditions

Journeys let you send the right message to the right supporter at the right moment — automatically. Every journey is built from two core ingredients:

• 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.

This article is a full reference for every trigger and every condition you can use when building a journey.

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.

Triggers and conditions both support rule groups combined with AND / OR operators, so you can build anything from a simple filter to a complex, multi-layered audience.

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.

Event-triggered journeys automatically allow late entry.

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:

1. Entry conditions — filter who's allowed to enter based on audience rules or trigger-specific rules.

2. Exit conditions — automatically remove supporters from the journey when a rule is met.

3. Logic steps — branch the journey into YES / NO paths based on audience rules.

4. 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 AND or OR.

• Between groups, you can combine with AND or OR.

That means you can build audiences like:

Donors who gave more than $100 this year AND (are tagged 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.

Text Fields

Used for names, emails, phone numbers, addresses, notes, custom text fields.

Operators:

• is / is not

• does contain / does not contain

• starts with / ends with

• has value / has no 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 greater than or equal to

• is less than / is less than or equal to

• has value / has no value

Currency Fields

Used for total given, total given this year, EMRR (estimated monthly recurring revenue), pledge amounts, donation amounts.

Operators:

• is / is not

• is greater than / is greater than or equal to

• is less than / is less than or equal to

• has value / has no value

Amounts are entered and displayed in dollars.

Date Fields

Used for created date, first donation date, last donation date, last seen, last message date, recurring plan dates.

Operators for specific dates:

• before / on / after / between

Operators for relative dates (how many days ago):

• more than / exactly / less than

Plus: has value / has no value

Select (Single Choice) Fields

Used for donor type (individual vs. company), lifecycle stage, recurring plan status, payment status, supporter status.

Operators:

• is / is not

• has value / has no value

Multi-Select Fields

Used when a supporter can have multiple values at once (multiple campaigns, multiple statuses, etc.).

Operators:

• includes / does not include

• has value / has no value

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)

• has value / has no value

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

• has value / has no 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

Filters available inside a transaction query:

• Amount (or amount range)

• Date (or date range)

• Campaign

• Fund

• Donor type

• Payment method

• Payment status

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.

Both paths can lead to different messages, delays, or further logic steps. Use logic steps when you want the same journey to handle different supporter types (e.g., first-time donors vs. repeat donors).

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).

Audience-based exit rules are checked every time the supporter moves through a step, so they take effect as soon as the condition is met.