Triggers

A trigger (also called an entry step) is the very first step in a journey — it decides when and for whom the journey starts. Every journey needs exactly one, and it's always the first box on the canvas, with lines flowing out from it into the rest of the steps. There are five kinds of triggers, covering the main ways a journey should kick off: something a contact does, a schedule, starting it yourself, an external system telling it to start, or a send to a whole segment at once.

The trigger types

Event trigger — fires when something a contact does happens: they submit a form, open or click an email, get created as a new contact, get updated, a tag gets applied to them, or they register for, attend, miss or cancel a marketing event. You pick which event to listen for, and can narrow it further with conditions (for example, only when a specific form is submitted, or only when a particular field changes to a particular value). Contact updated also has a Fields picker: pick one or more contact fields and the journey only starts when one of those fields actually changed — leave it empty and any change starts it. A contact can't re-trigger the same journey over and over from repeated opens or submissions: see Re-entry limits and self-triggering.
Scheduled — fires at a set time instead of in response to something a contact does. You can point it at a fixed date and time, at a time relative to one of a contact's date fields (like a renewal date or a birthday), or set it to repeat on a recurring schedule.
Manual entry — fires only when you start it yourself, for the segments you choose. Nothing happens automatically; you decide when to enroll contacts.
API entry — fires when an external system sends a request to a dedicated web address set up for this journey. This is meant for connecting other tools or custom integrations your team has built; if you need one set up, ask your dev team.
Broadcast — fires for every contact in one or more chosen segments at once, as part of sending a one-time email or text to that whole audience. You choose the segments, the channel (email or text), the content, and when it should go out. If the journey is linked to a campaign, an email broadcast carries that campaign's tracking parameters and counts toward its metrics, the same as any other email send from the journey.

Using more than one trigger

A journey can have several triggers, and each one starts the journey at itself. So a "First name changed" trigger and an "Email changed" trigger on the same journey each begin at their own node, and each can lead into its own steps before joining a shared path — you don't need a separate journey per event.

Two things to keep in mind:

A contact still only travels the journey once at a time. If someone is already partway through, a second trigger firing for them doesn't start a parallel run. Whether they can come back through later is governed by Allow re-entry in the journey's settings.
Each trigger narrows independently. Two "Contact updated" triggers can watch different fields, and a contact's edit starts the journey at whichever one matches the field that actually changed.

Re-entry limits and self-triggering

A journey can end up triggering itself. A journey that starts on Email opened for any email, and sends an email, would without a guard start again when its own email is opened — and mail privacy features and link scanners open and click every email automatically — send again, and so on for ever. The same goes for a journey that starts on Tag applied and removes and re-applies that tag, for one that starts when a text is replied to and reaches an auto-responder, and for two journeys that keep enrolling a contact into each other.

Four limits stop this. Each one skips the enrolment — no run starts, nothing is sent — and records why:

The journey's own messages and actions never re-start it. When an event was caused by the journey itself — a receipt for an email or text it sent, including its broadcast (sent, delivered, opened, clicked, bounced and the rest), or a tag its own Apply tag step applied — that event can't enrol the contact in the same journey again. Nor can an event caused by a journey the contact was sent on from this one: if journey A enrols someone in B and B's email or tag would start A again, that's skipped too. This applies whether or not Allow re-entry is on. Other journeys' messages still count as normal triggers.
A chain of journeys stops after three hops. When one journey's action (an Enroll in journey step, a tag, a message) starts the contact on another journey, that one's starts them on a third, and so on, three such hops in a row are allowed and the fourth is skipped.
A 30-second cooldown. With Allow re-entry on, a contact who entered the journey less than 30 seconds ago isn't enrolled again yet. There is no daily limit: a contact can re-enter as often as the trigger fires, at most once every 30 seconds.

Text replies are treated differently. A text has no "reply to" link, so a reply can only be assumed to answer the last text the contact was sent. That's never enough to skip it: a reply is never treated as the journey's own doing and doesn't count as a hop in a chain of journeys — it starts the journey as fresh as any other event. Replies — a person's or an auto-responder's — are held to the same cooldown as any other entry when re-entry is on: a second text within 30 seconds of the last entry is skipped. So a keyword journey answers every text a person sends, and an auto-responder bouncing the journey's texts straight back is slowed to one round every 30 seconds.

Which entries the cooldown covers. It applies to entries a journey could cause: event triggers — including events another system posts through the API — and Enroll in journey steps, and a journey started by an integration (a machine token rather than a person signed in). Entries a person or a schedule decides are not limited: a broadcast, a scheduled entry (so an hourly schedule enrols a contact every hour) and a manual entry — the segments it enrols when you publish, or a contact you start on the journey yourself. The cooldown counts every version of the journey. With Allow re-entry off a contact only goes through once anyway, so it doesn't come into it. Test walks you start yourself — dry-run samples and path checks — aren't limited, and don't count toward the cooldown of the live journey either.

Where a skip shows up. A skipped trigger event appears on the journey's Events tab marked Skipped, with the reason — for example "re-entry cooldown — contact entered this journey less than 30 seconds ago" or "loop guard — this journey's own message or action caused the event". An Enroll in journey step that enrolled nobody shows Not enrolled and the reason against that step in the run's details — already in that journey, re-entry off, a loop guard, and so on. See Monitoring and runs.

The canvas warns you first. A journey with Allow re-entry on that sends — a Send step or a Broadcast — and has an Email opened or Email clicked trigger that isn't tied to one particular email, or is tied to an email the journey sends itself, shows a warning in the Problems panel: the journey can re-trigger itself on its own messages. The same warning covers the email sent / delivered and text sent / delivered triggers, which a journey the assistant builds can use. It's only a warning — the journey still publishes, and its own messages are skipped as described above. If you meant to react only to other messages, pick the one email the trigger is about, or turn re-entry off. A text replied (or text received / opt-in) trigger on a sending journey gets its own warning: an auto-responder's replies aren't skipped, only held back by the 30-second cooldown, so add a condition on the reply's text if only some replies should start it.

The "Contact updated" event

Contact updated is the event to reach for when you want a journey to react to a contact's details changing — a lifecycle stage moving to "customer", a city being filled in, an email address being corrected.

Narrowing it down. Left as-is, it starts the journey on any change to the contact, which is almost never what you want. Two settings narrow it:

Fields — pick one or more contact fields, and the journey only starts when at least one of those fields actually changed. Picking several means "any of these", not "all of these". Leave it empty and any change starts the journey.
Conditions — pick a field and a value, and the journey only starts when the change lands on that value. Conditions on this trigger look at the new value, so "Lifecycle stage is customer" means "changed to customer", not "was already customer". Use Fields to say which field, and Conditions to say what it became. Values compare as the field's kind of value — a number field compares as numbers, a yes / no field accepts true or false — the same way an If / Else condition does (see Branching and timing). For in list on a text field, type the values separated by commas — "Boston, Denver, Austin" — and the condition matches when the new value is any one of them. A yes / no field offers just equals / not equals with a True / False value. You pick values the same way as in an If / Else condition: Country is a list of countries (the condition compares the two-letter country code the contact stores, such as GB), a choice field lists its options (several at once for in list), and Timezone suggests time zones as you type. An Owner condition picks from your workspace's users by name — one for equals / not equals, several for in list / not in list — and compares the user, not their name as text. That's why Owner offers only those four operators: "contains" or "starts with" would be looking at a user's internal id, which never matches what you'd type. A journey saved earlier with one of those on Owner shows it as it was saved, and publishing asks you to change it. Conditions on your custom fields work on Contact created as well as Contact updated. (A Contact created trigger with a custom-field condition set up before October 2026 never started anyone; it now works without any change.)

Conditions here read the change, not the whole contact. A trigger's conditions can only look at what the event itself carries. To gate on something else about the person — a tag they hold, a value on another field — put an If/Else step immediately after the trigger; that step can see the full contact. And if what you actually want is "when this tag is applied", that's its own trigger (Tag applied), not a condition on Contact updated. Publishing will refuse a trigger whose conditions are set up the wrong way round and will point at the node to fix.

What counts as an update. The trigger fires for changes made through:

editing a contact by hand in the app
edits the assistant makes for you when you ask it to
a contact filling in one of your web forms
a sync from a connected CRM, whether it comes through one record at a time or as a bulk sync
a spreadsheet import, but only if that import was set to run live — imports are silent by default precisely so a 50,000-row file doesn't enroll everybody at once. See Importing contacts.

What deliberately does not count. A journey's own Update contact step (and its Apply tag step) does not fire this trigger. That's a safety guard, not an oversight: without it a journey that sets a field could re-enroll its own contacts forever, or ping-pong endlessly with a second journey listening for the field it writes.

Contact status isn't offered. You won't find Status in the Fields picker or in the condition fields for this trigger. Archiving a contact is how the app deletes them, and archived contacts can't be enrolled in a journey — so a "when status changes" trigger would look like it was set up correctly and then silently never start anything for anyone. It's left out rather than left broken.

Replaces "Contact field changed." A Contact field changed trigger used to be offered, and older journeys may still be built on it. It has been retired in favour of Contact updated and is no longer in the event list, so you can't pick it on a new journey. If you have an existing journey on it that never seemed to start anyone — that's exactly what was wrong with it, and rebuilding that journey on Contact updated is the fix.

The marketing-event events

Six of the options in the Event type list follow a registrant through a marketing event, so a journey can react to each stage of it:

Event registration — someone registered. This is the trigger behind the confirmation email an event sets up for you, so if you already have one of those, check you're not about to send a second confirmation on the same trigger.
Event registration cancelled — someone gave up their spot.
Promoted off the waitlist — a spot opened and the person who had been waiting longest moved up to registered.
Event attended — they turned up.
Event no-show — they registered and didn't turn up.
Event cancelled — the whole event was called off, which fires for everyone who was signed up rather than for one person.

Scoping it to one event. Picking any of these reveals a Marketing event picker. Leave it empty and the trigger fires for every event, which is what you want for something generic like a thank-you or a "sorry we missed you" follow-up. Pick an event and the journey only starts for that one — the right choice for a journey built around a specific webinar.

Registration means registration, however it happened. Event registration fires no matter how the person signed up: your own web form, the provider's own registration page for a linked webinar, an imported registrant list, someone added by hand, or an API call. This is worth knowing if you were reaching for Form submitted instead — that one only covers a web form you built here, so a journey on it silently misses everyone who registered another way.

"Event ended" is not on this list, deliberately. An event ending happens once, to the event, not once per contact — so there is nobody in particular for a journey to start for. To do something after an event finishes, branch on what each registrant actually did instead: see Event attendance in Branching and timing.

For the whole picture — reminders that re-time themselves when an event moves, and what to do after it — see Marketing events.

Steps

On a new or draft journey's canvas, open the step palette along the side and switch to the Entry category.
Drag the trigger type you want onto the canvas, or click it to drop it in. This becomes the starting point of the journey.
Click the trigger step to open its settings panel.
Fill in the details for that trigger type — for example, which event to listen for and any conditions to narrow it, the date or recurring schedule, which segments to enroll, or the endpoint and content for a broadcast.
Draw a line from the trigger to the next step in your journey to connect it into the rest of the flow.
Your changes save automatically. Publish the journey when you're ready for the trigger to start working for real contacts.

Tips

Event triggers are the most common choice for journeys that should react to something a contact does in the moment, like signing up or opening an email.
Use a scheduled trigger for anything date-driven, such as a reminder ahead of a renewal or an annual check-in.
A broadcast trigger is best for a one-time send to an audience rather than an ongoing, per-contact journey — use manual entry or an event trigger if you want the journey to keep enrolling contacts over time.

FAQ

Q: Can I change a journey's trigger after I've already built the rest of it? A: Yes, you can edit the trigger step's settings at any time on the canvas, the same way you'd edit any other step. Just make sure the rest of the journey still makes sense for the new trigger before you publish.

Q: I edited a contact and my "Contact updated" journey didn't start — why? A: Check three things, in this order. First, the Fields picker: if it lists fields you didn't actually change, the journey correctly stayed put. Second, the source of the edit — a journey's own Update contact step never re-triggers a journey, and a spreadsheet import only counts if it was run live rather than silently. Third, whether the contact is archived: archived contacts are never enrolled in journeys.

Q: What's the difference between manual entry and a broadcast trigger? A: Manual entry starts a journey for the segments you choose, and the journey then runs its normal steps for each contact individually. A broadcast trigger is specifically built for sending a single email or text to an entire segment at once, with the send itself configured on the trigger.