> ## Documentation Index > Fetch the complete documentation index at: https://docs.wegive.com/llms.txt > Use this file to discover all available pages before exploring further. # Journey Triggers and Conditions > WeGive Help Center article: 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 | Trigger | Fires when | | - | - | | **Payment Success** | A donation is successfully completed. | | **Payment Failure** | A donation attempt fails. | | **Payment Processing** | A bank/ACH payment is still processing. | | **Payment Pending** | A payment is stuck in a pending status. | | **Payment Refunded** | A payment is refunded. | | **Recurring Donation Created** | A supporter sets up a new recurring plan. | | **Recurring Installment Failed #1–#4** | A recurring charge fails. The numbered versions let you build a weekly reminder ladder. | | **Offline Recurring Donation Activated** | A supporter adds a payment method to an imported offline recurring plan. | ### Engagement and Communication Triggers | Trigger | Fires when | | - | - | | **Subscription Status Updated** | A supporter's communication-list subscription preferences change (opt-in, opt-out, etc.). | | **Email Engagement Event** | A message is delivered, opened, clicked, or fails. *Requires you to pick which message in the conditions.* | | **Form Submitted** | A supporter completes and confirms a form. | | **Supporter Tagged** | A supporter is tagged with a specific tag. | ### Peer-to-Peer Triggers | Trigger | Fires when | | - | - | | **Peer-to-Peer Donation Notification** | A donation is made to a P2P fundraising page. | | **Peer-to-Peer Created** | A supporter creates a new P2P fundraiser. | | **Peer-to-Peer Goal Met** | A P2P fundraiser reaches its goal. | ### Pledge Triggers | Trigger | Fires when | | - | - | | **Pledge Created** | A supporter creates a new pledge. | | **Pledge Installment Due (Today)** | A pledge payment is due today. | | **Pledge Installment Due (Tomorrow)** | A pledge payment is due tomorrow. | | **Pledge Installment Due (One Week)** | A pledge payment is due one week out. | | **Pledge Installment Missed** | A supporter misses a scheduled pledge payment. | ### Impact and Portal Triggers | Trigger | Fires when | | - | - | | **Tagged in an Impact Card** | A donor is tagged in an impact number or impact card. | | **Tagged in an Impact Story** | A donor is tagged in an impact story. | | **Donor Profile Created** | Someone creates a donor-portal profile. | ### Other Triggers | Trigger | Fires when | | - | - | | **Event Registration Success** | A supporter successfully registers for an event. | | **Tribute Made** | A tribute donation is made in someone's name. | | **Individual Added to Household** | A supporter is added to a household. | **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. The **Allow Late Entry** toggle only applies to audience-only journeys (no trigger event) — it controls whether supporters who already matched the audience rules before the journey went live get swept in retroactively. Event-triggered journeys aren't affected by this toggle one way or the other: they simply enter a supporter whenever the trigger event fires after the journey is live, regardless of this setting. ### 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. **A common question: why is there no "is not unknown" comparator?** Several field types below list `is 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 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:** * 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 **Filters available inside a transaction query:** * 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. | Condition | What it checks | | - | - | | **Has completed Journey X** | The supporter has finished a specific journey. | | **Is on step X in Journey Y** | The supporter is currently paused on a specific step. | | **Is currently in a Journey** | The supporter is active in any journey right now. | 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.